Saas - Multi-Tenant Event-Mesh with On-Premise

[TimoStark]

Hi,

Scenario:

• Multi-Tenant SaaS Application (CAP)
• Multi-Tenant aware Event-Mesh

Is it possible to connect the consumer S/4 on premise system to the multi-tenant aware event-mesh?

As far as I see, we can only extract one single service-key for the whole Event Mesh instance, therefore the S/4 system pushes the events to the instance, but from here the event is not shared with the "correct" subscription of the event mesh.. (which makes sense - there is no tenant information in the global service key).

----

If it is not possible: Can i have an own dedicated event mesh in the consumer subaccount and somehow connect that event mesh to the Multi-Tenant SaaS event-mesh "transparently" (i.E. using cds.on)? I see one "solution":

1. Create a endpoint "retrieve-event" protected for technical users in cap saas
2. Create a webhook in local / consumer event mesh, pointing to the endpoint (of course with consumer app-router URL)
3. Throw away SaaS event-mesh (at least for the scenario of on-prem --> cloud events)

That should work, but is not nice as I can not use the integrated event capabilites.

Thanks,

Timo

[marcmaurí]

Hi 8ae6723ab3fa43a8980099fe48f90b04 ,

We have the same scenario and problem as you. Did you find a solution?

Best regards,

Marc

[TimoStark · Accepted solution]

marc.mauri

General solution is as follows:

• In the subaccount of the customer create a dedicated event mesh
• Connect this event mesh to the S/4 on prem / cloud system of the customer
• Create a webhook in the event mesh using oauth2 authentification (client-code credential flow). You need to have oauth2, because only in this case you have a valid JWT. The JWT contains the zone-id and can therefore be used to identify the tenant you are in.
• The webhook target is a dedicated endpoint in your multi-tenant application

This solution causes two problems:

(1) you need to have a client-id / client-secret of the subaccount of the consumer

(2) as per the webhook specification the service must answer in a well defined manner, e.g. answering an options call.

For number (2) you can see the following code as an example. Note: this is using an own implementation of a rest endpoint on purpose, as I need to answer the "options" call, so that the webhook handshake is working.. It might be possible to do that with a "normal" cds implementation too.. but i started using that way, so i just wanted to finish 🙂

For number (1) there are basically two solutions.. None of which I really like 🙂

Number 1: Custom hacking (totally bad, but works 🙂 ).

• In the client subaccount create a cloud foundry enviroment
• create a xsuaa instnce with the following settings:

• (Extremly bad): Adjust the xsuaa instance of your SaaS application to grant the right to the tenant (grayed out stuff is the subaccount). This might be automatable during the deployment process.

• Create a service key in the xsuaa instance in the customer account and extract the client-id/secret from here..

Number 2: Usage of API entitlements: There is some example of using an API entitlement using the service broker ( https://github.com/SAP-samples/btp-cf-cap-multitenant-susaas/blob/main/docu/2-basic/4-subscribe-cons... ) where you also get a well defined client-id/secret at the end. this solution seems to be preferable as you don't have to do so much manual work. I didn't had the time to try it out yet though.

BR,

Timo

[marcmaurí · Accepted solution]

Hi 8ae6723ab3fa43a8980099fe48f90b04 ,

Thanks a lot for such a detailed response, it is great!

If we test the option based on API Entitlements, we will let you know the result.

Best regards,

Marc

[Sergen_Batman · Accepted solution]

Hi Marc,

were you able to test the API Entitlement option?

Best regards,

Sergen

[marcmaurí · Accepted solution]

Hi sergenbatman ,

no, we didn't test it. If you do, please let us know the result.

Best regards,

Marc