Content Navigation
Part 1: A simple UI5 app that runs in the SAP Launchpad Service
Part 2: Multiple Apps with a Shared Reuse Library
Part 3: Splitting Bigger Projects (Current page)
Splitting Bigger Projects
In the last posts, you have learnt how to build multiple apps and move common parts of them into a reusable library. Everything is deployed by one MTA.
In this part, we will have a look at how to split this into smaller parts. This enables us to have independent lifecycles to split responsibilities between different developer groups.
Example: The reusable library might have a different lifecycle than the apps and is not changed that often. Maybe they are also maintained by other developers and should be stored in a separate Git repository.
The sample code can be found in the GitHub repository.
Current State
Let's have a quick look at the starting point. There are three HTML5 apps, which are all deployed to one shared app-host. There is one XSUAA and one destination service. All service names in manifest.json files and the destinations are the same.
The corresponding MTA looks like this:
A First Split for the App-Hosts
The first split you would do is to use multiple HTML5 app-hosts and distribute the HTML5 apps to them.
For every app-host there will be one destination created. They all use the same cloud service name. There is no change for the apps itself.
The corresponding MTA would look like this. There are three managed resources for the app-hosts. Three content deployers and destinations are created by the destination content deployer.
If you have more apps, you can distribute them to app-hosts as needed.
Only splitting the app-hosts as it is done until now does not add a lot of value because everything is still contained in one MTA. But it is a good starting point for the next step.
Split the MTAs
In the next step, we will split the single MTA into multiple ones. Every app and app-host will be moved to a separate MTA. The XSUAA and the destination service will still be shared by all and therefore move to the MTA containing the shared library. The result of the deployment will not change at all. Below, the colors indicate which MTA will deploy which content.
The cloud service name will still be the same everywhere.
The MTAs [Shared, App1, App2] will look like this.
Note that the destination service resources in the app MTAs are of the type "existing service". Only the shared MTA defines it as a "managed service" because this MTA owns the service instance and will create it. Therefore the shared MTA has to be deployed first.
This setup already fulfils most use cases. The apps and shared library can now be developed and deployed independently. They can also be moved to different Git repositories.
Split the XSUAAs
Until now, the MTA projects are already quite independent but they still share the XSUAA and the contained authorization objects. However, your apps might contain complex back-end services and have complex authorization objects. In that case, developers would not want to maintain the xs-security.json files in the central MTA but move the app-specific parts to the MTA of the app. This is a good reason to split the XSUAAs.
Now we have three XSUAA instances. Each one is deployed by one MTA. As soon as we split the MTAs, we also split the cloud service names. Every pair of app-host and XSUAA uses the same service name including the apps which are deployed on the app-host. This way the authorization handling is bound to the correct XSUAA and its authorization model applies. Example: If you have routes in xs-app.json that require a given scope, they are defined by the corresponding XSUAA. The same would happen for any back-end apps that are possibly contained in your MTA.
The following rules apply:
- There must be exactly one XSUAA instance per cloud service name. Even if you do not have any authorization model, you would have to provide an empty XSUAA.
- All HTML5 apps on the same app-host have to use the same cloud service name
The MTAs [Shared, App1, App2] will look like this:
Every MTA now contains an own xs-security.json [Shared, App1, App2] with an own unique xsappname.
The service names have been replaced in the manifest.json (sap.cloud/service) [Shared, App1, App2] files as well as in the MTA files (sap.cloud.service in destination definition for app-host and xsuaa) [Shared, App1, App2] and in the index.html (resource mappings) [App1, App2]. Also, the URLs to run the apps standalone now contain the new service tags.
To be continued
Above are the most relevant splits for your use cases, which I wanted to publish as soon as possible due to a high demand.
Watch out for an updated version with further splits.
- SAP Managed Tags:
20 Comments
