CAP Multitenancy with consumer specific HTML5 repository

[#1]

Hello all,

We are developing a CAP Java multitenant application and have deployed it in a provider subaccount.
The multitenant approuter is deployed in the provider subaccount as well and points to the HTML5 repository of the provider subaccount. The HTML5 module calls the CAP Java application.

The consumer subaccounts subscribe to the CAP Java application and call the tenant specific approuter URL.
This call leads to the HTML5 repository of the provider subaccount and not the the HTML5 repository of the consumer subaccount.
Is there a way to change this behaviour?
What is the correct/best way for a multitenant CAP server module with tenant specific HTML5 module?

Best regards and many thanks,

Chris

[Ivan-Mirisola · Accepted solution]

Hi christoffer.fuss,

Why would you require an HTML5 repository specific to each subaccount in a multitenant application?

The way I understand multitenant applications is that they all share the exact same front-end, but data gets stored on its own separation persistence store - based on the tenant context (URL). In such a way that you have to maintain your solution at a single deployable unit for all customers you have.

If you must give access to different applications based on the user's context (authorization scopes), then there are different options you could use. For instance, you could create an instance of the Launchpad Service (*not* the subscription - since the later is not compatible with multitenant applications) during the on-boarding subscription process. A group of applications will be assigned to a role on this Launchpad instance which can then be assigned to the user during runtime according to a Role Collection on the subaccount level.

Hope this helps.

Best regards,
Ivan

[christoffer_fuss · Accepted solution]

Hi ivan.mirisola, thanks for helping.
We are using a multitenant server module which is the same for all customers. The frontend modules are customer specific and have different release cycles.
The frontend modules are not UI5 modules (Angular modules) and so we are not using the Launchpad Service. We are just deploying the frontend modules to the HTML5 repository and access them via standalone approuter.
Is this maybe possible to deploy all customer specific frontend modules to the provider acccount and use an approuter extension to navigate to the tenant specific frontend modules?

Best regards,
Chris

[Ivan-Mirisola · Accepted solution]

Hi christoffer.fuss,

You could deploy all html5 modules on the provider account and restrict its usage based on authorization scopes directly on the xs-app.json. Let's say you map a route (for the multitenant app router) with a custom domain for customer X. And on the xs-app.json, you create a route match for that custom domain to make it access some specific html5 application (or different ones based on the suffixes you apply after the hostname). For instance: customerA.domainA.com/app1 and customerA.domainA.com/app2, etc.

I don't think splitting html5 modules on different MTAs and deploy them on each consumer sub-account will make operations any easier. Beside, it might pose a different challenge altogether - sharing the emitted JWT (by different App Routers) to the same service. Also, you will require Application Runtime memory for each standalone App Router you deploy - which probably is a waste of resourses.

Best regards,
Ivan

[christoffer_fuss · Accepted solution]

Hi ivan.mirisola ,
thanks again. So it is possible to use one approuter with multiple HTML repositories? I always see examples like this:

{
  "source": "(.*)",
  "target": "/mietercockpit/$1",
  "service": "html5-apps-repo-rt",
  "cacheControl": "no-cache, no-store, must-revalidate"
}

So it is possible to do something like this:

{
  "source": "customerA.domainA.com/mietercockpit(.*)",
  "target": "/mietercockpit-customerA/$1",
  "service": "html5-apps-repo-rt",
  "cacheControl": "no-cache, no-store, must-revalidate"
},
{
  "source": "customerB.domainB.com/mietercockpit(.*)",
  "target": "/mietercockpit-customerB/$1",
  "service": "html5-apps-repo-rt",
  "cacheControl": "no-cache, no-store, must-revalidate"
},
{
  "source": "(.*)",
  "target": "/mietercockpit-provider/$1",
  "service": "html5-apps-repo-rt",
  "cacheControl": "no-cache, no-store, must-revalidate"
}

Best regards,
Chris

[Ivan-Mirisola · Accepted solution]

Hi christoffer.fuss,

Correct me if I misunderstood you, but it sounds like you are trying to deliver the same application to different customers by duplicating a template application and manually performing changes to them. If so, this is not the best approach. Instead, I would highly recommend you to make such UI changes dynamically (via code) by controlling what your customers can see on their subscriber's cockpit app. As mentioned before, this could be achieved by configuration data stored in a database and retrieved during runtime plus authorization scopes defined on your xsuaa. This will allow you to do minimal manual intervention in your project. All will be achieved via xsuaa attributes you define during the on-boarding together with data you store on a table.

It doesn't really make any sense having multiple instances of the same application being delivered to different customers with simple cosmetic changes. This will increase your application maintenance and overall complexity.

My suggestion was that if you had completely different applications to deliver to different subscribers, than you could declare them on a single xs-app.json as routes to different web modules in your <app> folder project (deployed to your html5 repo). Anyway... If that's your case, I would never hard code domain names on this file. Mapped routed will take care of that for you. The downside of this approach is that different customers could potentially make calls to each other's applications - if they knew which suffix to use. This could be fixed by setting the "identityProvider" clause on each route - so even if other customers knew another app's suffix, they would still be required to log in using an IdP for which they do not have the credentials to.

Best regards,
Ivan

[christoffer_fuss · Accepted solution]

Hi ivan.mirisola,

you got it right and this is of course our goal to achieve this but our frontend module is not yet ready for this (and it is a little bit more complex than changing a template).

So we have to start with the approach with the different routes on the xs-app.json. I will try it out and let you know the result 🙂
Many thanks and best regards,

Chris

[Ivan-Mirisola · Accepted solution]

Hi christoffer.fuss,

There is also another option which I didn't mention to you here:

https://answers.sap.com/answers/13638723/view.html

Keep in mind this is a very specific scenario where your destination will call a service in another subaccount - which may be using a completely different IdP.

Best regards,
Ivan