Skip to Content
Product Information

Achieve Separate Lifecycles for Managed Approuter Applications with SAP Business Application Studio


Developing a multitarget application (MTA) in one project is a straightforward development process.

Nevertheless, there could be reasons to split one business solution into multiple projects:

  1. There are multiple teams working on an MTA project, with each team working on a different application of the MTA project.
  2. Multiple applications in the MTA having different lifecycle.

In the following blog post, I will show you how to split apart the managed approuter MTA and the front-end MTA of your business solution. You will still use the same xsuaa for all MTA projects and you won’t need to create a separate xsuaa for each front-end application.

This feature is available on SAP Business Technology Platform (BTP) from April 22nd, 2021.

First, I recommend taking a look at the straightforward HTML5 application development in one MTA project.

Solution Diagram

Central Approuter MTA (right side of the image):

  • The central approuter MTA is the business solution entry point for the managed approuter.
  • The central approuter MTA manages scopes and roles of all front-end applications using:
    • One xsuaa instance
    • An “xs-security json” file
  • The central approuter MTA owns the destination instance and its destination content:
    • Destination content to the xsuaa instance
    • Destination content to all front-end apphost instances

Front-end UI MTA (left side of the image):

  • The front-end MTA includes the front-end and destination modules.
  • The front-end MTA owns the apphost instance.
  • The front-end MTA uses the existing destination instance of the central MTA and updates the central MTA’s content during deployment.
  • The front-end MTA also uses existing scopes and roles defined in the central MTA. If there is a new scope required by the front-end application, the central MTA should be updated manually.

Create a Central MTA Project

  • Create a Basic Multitarget Application (MTA) from the template wizard.
  • Right-click the “mta.yaml” file of the MTA project and click Create MTA Module from Template, and select Approuter Configuration.
  • Select the Managed Approuter option and enter the business solution name, for example, “mySolution”.
  • Select No for the following question: Do you plan to add a UI?
  • Open the MTA of the project and copy the name of the destination service locally.
    You will use it later for the front-end projects.

Create Front-end HTML5 Projects

  • Create two front-end applications (for example, UI1 and UI2).
    You can create any type of HTML5 project. In this blog post, I created a Vue.js application using the HTML5 application blog.
  • Make sure that you enter the same business solution name that you entered for the central approuter MTA.
  • Your application is created and will open in a new workspace after all its dependencies are installed. (This may take a few seconds).
  • You should now have one central MTA and two frontend applications (UI1, UI2).

  • Open the “mta.yaml” files of the two front-end applications and perform the following updates:
    • Replace the destination service name (line 66) with the central MTA destination name. For example, “centralMTA-destination-service”.
    • Replace the type of destination service from “managed” to “existing” (line 60).
    • Remove the “config” section from the destination parameters (lines 62-64).
    • As a result, the destination in the “mta.yaml” looks like this:
    • Remove the xsuaa resource (lines 74-80):
    • Remove the xsuaa section from the destination module (lines 15-18, 27-31):
  • Delete the “xs-security.json” file.


Build, Deploy, and Run Your Applications 

First, build and deploy the central MTA and only then can you build and deploy the dependent front-end applications.

To deploy your applications to Cloud Foundry, perform these steps:

  • Log in to the target Cloud Foundry space, where you want to deploy the application.
    From the menu, click View > Find Command to open the command palette and enter your login credentials.
  • Enter “MBT build” in the terminal, which generates your MTA archive file, or right-click on the project’s “mta.yaml” file and click Build MTA Project.

  • Enter “CF deploy <mtar file name>” in the terminal, which deploys your application to the space that you logged into, or right-click on the mtar file and click Deploy MTA Archive.
  • Perform the above steps to build and deploy the two front-end applications.
  • From the SAP BTP cockpit, navigate to the HTML5 Applications menu and open your deployed applications, which are served by the destination and xsuaa of the central MTA.


You have separated the front-end development lifecycle into different MTA projects.

I will be happy to hear your feedback personally or here in the comments.

Use the Trial environment to take your first steps or take a look at all of the SAP Business Application Studio tutorials.



You must be Logged on to comment or reply to a post.
  • Hi Yuval Morad ,

    thanks for the helpful blog, coming right in time, since we have some problems in this area.

    The generator used for the central mta project creates a module. Is this really necessary or can it deleted so only resources remian in the central mta project?



          • Of course, see below

            _schema-version: "3.2"
            ID: tst
            version: 0.0.1
            - name: tst-destination-content
              - name: tst-destination-service
                  content-target: true
              - name: uaa_tst
                    name: uaa_tst-key
                    - Authentication: OAuth2UserTokenExchange
                      Name: testX_uaa_tst
                      ServiceInstanceName: tst-xsuaa-service
                      ServiceKeyName: uaa_tst-key
                    existing_destinations_policy: ignore
                no-source: true
            - name: tst-destination-service
              type: org.cloudfoundry.managed-service
                  HTML5Runtime_enabled: true
                  version: 1.0.0
                service: destination
                service-name: tst-destination-service
                service-plan: lite
            - name: uaa_tst
              type: org.cloudfoundry.managed-service
                path: ./xs-security.json
                service: xsuaa
                service-name: tst-xsuaa-service
                service-plan: application
          • Sorry, but I still don't understand this, there is only one destination defined in the content module, in my case "testX_uaa_tst" and according to your description this destination is nowhere used.

            There are two services in the resource section, but they will be created also without the content module.

          • The central MTA owns the destination instance inside it should have xsuaa as destination content.

            The UI MTA is using that CENTRAL instance and upload another destination content which is a destination to the app-host

  • Hi Yuval Morad ,

    another question: When you remove the xsuaa resource and keep the requires for it in the content module (lines 15-18 in your last mta.yaml screenshot), why does this work?

    Don't you need to reference the central xsuaa as a existing service?