Multi-Tenancy Support

[thisisevanfox]

Hello CAP Community,

We operate a multi-tenant CAP application and have currently implemented the creation of NotificationTypes and the sending of notifications via API calls ourselves. To improve maintainability, promote standardization, and eliminate custom code, we now want to switch to the cap-js/notifications plugin. We have noticed that the plugin requires a destination to the notification endpoint for creating NotificationTypes during deployment. This must be in the provider account. This logic is implemented in the getNotificationDestination method in utils.js. Because the destination is always taken from the provider account, we therefore assume that multitenancy is currently not supported.

Are there any plans to make the plugin usable for multi-tenant CAP applications?

I would like to briefly describe how we handle the sending of notifications in our multi-tenant application: When implementing our own solution, we found that NotificationTypes need to be rolled out per tenant. This raised the question of how to automate the rollout of these types to all tenants during deployment. Technically, this means that you need to read the "SAP_Notification" destination from all tenant subaccounts using a tenant-specific JWT token (which can be passed to the getDestination method from @sap-cloud-sdk/connectivity, but is only available at runtime) and then trigger the endpoint for creating/updating accordingly.

How did we solve this? We do not roll out the NotificationTypes directly during deployment but check in a tenant-specific context before each time a notification is send whether the NotificationType referenced in the notification already exists and respond accordingly.

Thank you in advance for your support!

[jasper07]

Are you talking Portal Sites or Workzone Standard?

I think we are kind of in the same boat, when to call the NotificationTypes API to declare the types we want to publish.

As you suggested @sap-cloud-sdk/connectivity should read the subscriber destination first then then fall back to the provider if not found, which means the destination needs to be setup first before registering the NotificationTypes via the API.

Pretty easy to create your own destinations on the fly programitcally when onboarding, but where are the client credentials.

You can find them in Workzone Site Manager using this url
https://tenant.dt.launchpad.cfapps.region.hana.ondemand.com/notification/servicekeys
eg if using a Workzone per tenant
https://northwind.dt.launchpad.cfapps.ap10.hana.ondemand.com/notification/servicekeys

These credentials would be nice if you could get via an API in the SAP Business Accelerator Hub, but so should SAP Notifications its an V2 OData service, it was there before i thought.

One idea i had was the plugin could be a wrapper around two cds.remote.services
Numerous benefits:

• CSRF is implicit
• the APIs are typed as it generates CDS or CSN and can be used like any other service call
• you could also use the CDS to persist the NotificationTypes via CSV and have a control flag for the subscriber tenants to determine if they need syncing via a job, thinking would be handy longer term when you version the NotificationTypes.

how we doing in java

cds:
  remote.services:
    NotificationType:
      type: "odata-v2"
      http:
        suffix: "/v2/"
        service: "NotificationType.svc"
        csrf:
          enabled: true
      destination:
        name: "SAP_Notifications"
    Notification:
      type: "odata-v2"
      http:
        suffix: "/v2/"
        service: "Notification.svc"
        csrf:
          enabled: true
      destination:
        name: "SAP_Notifications"

I think the landscape here changes Q1 2025 with the Enabling embedded sites as local entry point for multitenant business solutions which hopefully gets rid of the needed to use a Workzone Standard subscription on the subscriber account and makes the onboarding a bit simpler.