Skip to Content
Product Information
Author's profile photo Yuval Morad

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

Overview

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.

Conclusion

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.

 

 

Assigned Tags

      13 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Wolfgang Röckelein
      Wolfgang Röckelein

      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 com.sap.application.content module. Is this really necessary or can it deleted so only resources remian in the central mta project?

      Thanks,

      Wolfgang

      Author's profile photo Yuval Morad
      Yuval Morad
      Blog Post Author

      please choose create UI : No in the wizard

      Author's profile photo Wolfgang Röckelein
      Wolfgang Röckelein

      Hi Yuval Morad ,

      I did choose "No" and still got a com.sap.application.content module (tried this now three time with the same result)!

      So I assume I can delete it, or?

      Regards,

      Wolfgang

      Author's profile photo Yuval Morad
      Yuval Morad
      Blog Post Author

      can you share the MTA of central approuter?

      Author's profile photo Wolfgang Röckelein
      Wolfgang Röckelein

      Of course, see below

      _schema-version: "3.2"
      ID: tst
      version: 0.0.1
      modules:
      - name: tst-destination-content
        type: com.sap.application.content
        requires:
        - name: tst-destination-service
          parameters:
            content-target: true
        - name: uaa_tst
          parameters:
            service-key:
              name: uaa_tst-key
        parameters:
          content:
            instance:
              destinations:
              - Authentication: OAuth2UserTokenExchange
                Name: testX_uaa_tst
                ServiceInstanceName: tst-xsuaa-service
                ServiceKeyName: uaa_tst-key
                sap.cloud.service: testX
              existing_destinations_policy: ignore
        build-parameters:
          no-source: true
      resources:
      - name: tst-destination-service
        type: org.cloudfoundry.managed-service
        parameters:
          config:
            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
        parameters:
          path: ./xs-security.json
          service: xsuaa
          service-name: tst-xsuaa-service
          service-plan: application
      
      Author's profile photo Yuval Morad
      Yuval Morad
      Blog Post Author

      looks great like the blog sample the content module is the destination module which is a MUST

       

      Author's profile photo Wolfgang Röckelein
      Wolfgang Röckelein

      Well there is a content module and a destination resource. The latter one is a MUST, of course, but is the content module really necessary?

      Author's profile photo Yuval Morad
      Yuval Morad
      Blog Post Author

      yes it uploads the 2 destinations content to the destination instance: xsuaa and html5 repo

      Author's profile photo Wolfgang Röckelein
      Wolfgang Röckelein

      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.

      Author's profile photo Yuval Morad
      Yuval Morad
      Blog Post Author

      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

      Author's profile photo Wolfgang Röckelein
      Wolfgang Röckelein

      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?

      Thanks,

      Wolfgang

      Author's profile photo Yuval Morad
      Yuval Morad
      Blog Post Author

      No the "glue" is the business solution as central entry point

      Author's profile photo Wolfgang Röckelein
      Wolfgang Röckelein

      Thanks! I overlooked that you also deleted lines 15-18...

       

      And I think I now understand now how this all works. Thank you for your patience with me and your quick answers!