Skip to Content
Technical Articles
Author's profile photo Matthias Schmalz

Designing UI5 Apps for SAP Launchpad Service – Part 3

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.

Assigned Tags

      5 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Kefren Conceição
      Kefren Conceição

      Hi Matthias Schmalz

      Thank you very much for the series on the subject, your explanation was of great help to my consultation and understanding of the concepts.

      Before your explanation, I was deploying the library and applications in different XSUAA and destination services. Trying to consume the library by route in xs-app.json. Frankly, I don't know if this is possible.

      My gratitude is so great that if one day you are interested in knowing Brazil, I humbly dispose of my house for you and your family. I live in Vitória, capital of the state of Espirito Santo, an excellent place to visit.

      LinkedIn: https://www.linkedin.com/in/kefrencezar

      Author's profile photo Kevin Hu
      Kevin Hu

      Thanks for sharing this. Actually I was also exploring the possibility recently for it to reuse the service instances.

      I think one of the key part is the "existing_destinations_policy: ignore" in the mta.yaml which prevents subsequent deployment from overwriting the destinations to the app-host created previously potentially by other developers.

      I think from my experience a centralized xsuaa instance will be more practical in real life, as it can be easily controlled by the security person. Of course it has pros and cons too.

      I have a seperate question, so

      once we defined the role/role collections in the xsuaa, then expose the apps to launchpad service, in which there are also roles (inside launchpad). What is the best or recommended way to handle both?

      Author's profile photo Matthias Schmalz
      Matthias Schmalz
      Blog Post Author

      Hi Kevin,

      the destination content and html5 content behaves differently when it is deployed.
      When an html5 app-host is deployed the previous content is completely erased and replaced with the new content. Therefore sharing an app-host does not work.
      However sharing a destination service instance works, as deploying destinations does not delete other destinations. Only destinations with the same name would be overwritten, which can be disabled with the flag you have mentioned.
      However I have already faced that this prevents you from updating destinations e.g. if the OData service has changed.

      Yes a central XSUAA is sufficient for most use cases. Splitting it should only be done if needed. I assume this is rather for bigger projects where there is no single security person but every development team has one.

      Regarding the roles, I am not a complete expert. As far as I know roles from Launchpad configuration appear as role collections in cockpit and you can assign your XSUAA roles to it. I am not sure if it is possible to create role collections via XSUAA, which can be used as role in launchpad.

      Best regards
      Matthias

      Author's profile photo Alfredo Oscar Montañes
      Alfredo Oscar Montañes

      Hi Matthias,

      Is it possible to onboard a Fiori Launchpad in "A subaccount" and add Fiori applications that are deployed in "B subaccount"? Or we've to deploy de Fiori app in "A subaccount" to add it to Fiori Launchpad?

      Regards,

      Alfredo

      Author's profile photo Matthias Schmalz
      Matthias Schmalz
      Blog Post Author

      Hi Alfredo,

      the FLP service only considers destinations from the same subaccount for finding the html5 applications. However there might be some options which I can't describe in details now:

      • Manually create the same destinations in the other subaccount by copying all credentials manually: This way cFLP might find the html5 apps but I have doubts that this work, because the other subaccount is a different tenant and authorization handling via the XSUAA instance is not enabled for the tenant.
      • Make the app a subscribable Software-as-a-Service app: This way, the other subaccount could do a SaaS subscription for the app which should make it available. Unfortunately I am not able to provide any instructions for this and do not know whether this is enabled for non-SAP developments.
      • Convert the app to a service with a service broker: Then a service instance could be created in the other subaccount and the app could be consumed from Launchpad. Unfortunately the same applies as above, but I had plans to enhance my 3rd blog post with a sample for this in future.

      Best regards
      Matthias