Designing UI5 Apps for SAP Launchpad Service – Part 4

[matthias_schmalz]

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 

Part 4: Splitting the Destination Service instance (Current page) 

Splitting the Destination Service instance 

Current State

In the last posts you have learned how to split multiple apps into multiple app-hosts and xsuaa instances which are deployed by multiple MTAs. This setup allows app developers to work independently and even define their own authorization models. 

However, they still share the same instance of the destination service, and all destinations are created there.  

This instance still acts as a common context for all apps. For example, the URLs to access these apps contain the instance GUID, which is the same for all (this has been explained in part 2 of this blog). 

Reasons for the split 

In most cases, this setup works just fine. But there's a potential for conflicts, and that's when you need to split into multiple destination service instances. 
One such conflict can arise from multiple instances of the same business services: 

Let us assume there is a service with an OData endpoint that allows us to store documents. 
Every instance of this service has its own isolated area where the documents are stored and only provides access to them. These documents are protected by the credentials in the service key of the instance.  

The clientId and clientsecret are specific for this instance and are used by the service to separate the stored data. 

Here is an excerpt of how the service key could look like: 

{ 
    "endpoints": { 
        "api": "https://<URL>/api" 
    }, 
    "grant_type": "user_token", 
    "sap.cloud.service": "btp.samples.consumed.service", 
    "uaa": { 
        "clientid": "<...>", 
        "clientsecret": "<...>", 
        "url": "<...>", 
        "serviceInstanceId": "<...>" 
    } 
}

This key will then be converted into a destination on the destination service instance to make it available to the managed app router. 

To connect to the OData endpoint of the service, the app adds a routing configuration to its xs-app.json: 

{ 
      "source": "^/api/documents/info$", 
      "target": "info", 
      "authenticationType": "xsuaa", 
      "service": "btp.samples.consumed.service", 
      "endpoint": "api" 
}, 

As you can see, the routing refers to the service key by specifying the service name that appears in the service credentials as sap.cloud.service and then chooses a service endpoint. 
The contained credentials are then used to get an access token and call the service. 

Now let us further assume that app1 and app2 both have their own instance of the document service.  
You must ensure that both apps access their dedicated content by using the credentials of their instance, i.e., they must access the services within their context. 
Without splitting the destination service instance, both destinations for the document service would be created on the shared instance. 

Unfortunately, this is now causing conflicts because both destinations have the same sap.cloud.service specified and the resolution of the service keys to use is ambiguous. I.e., the destination service instance defines only one context under which the service can be accessed. 

This is the moment where you must split the destination service instance to get multiple contexts to access the service (one for app1 and one for app2). 

How to split 

After the split, you no longer have a shared destination service instance. Instead, each context gets its own. The destinations related to the apps are moved to these instances and the destinations for the shared library are now duplicated and appear on both instances. Additionally, there are destinations for the consumed service instances.  

Let us see how the MTAs have changed [Shared, App1, App2]. 

Here the resource for the destination instance has been removed from the library MTA and switched to managed instances in the app MTAs. Additionally, the app MTAs now refer to the library app-host and xsuaa as existing service.  
Each of them contains the destinations of their app-host and xsuaa instances as well as for the shared app-host and xsuaa. 
Also, there are now the resources for the consumed service and the destination definition. 

In our sample, the consumed service offers a very simple endpoint that just returns information about the access token used. 
The apps have an additional datasource and model defined in their manifest.json to read this, and the clientId is now bound to the custom control in the master.view.xml to be shown on the UI. 

Access at runtime 

Because you’ve split the destination instance, the runtime access URLs change. Now, each app URL includes the GUID of its destination instance. 
This way the resolution of sap.cloud.service names is uniquely resolved via the correct destination to use the correct credentials. 

When running the apps they display the used clientid. You can verify that both apps show a different one, which reflects the instance GUID of the consumed service. 

Well done, now we have achieved a complete separation of the two apps.