Skip to Content

Deploy Your Multi-Target Application (MTA)

This tutorial shows you how to deploy your CAP application as Multi-Target Application (MTA).
You will learn
  • How to install the required tools
  • How to generate the MTA Deployment Descriptor (mta.yml)
  • How to add Authorization and Trust Management Service (XSUAA)
  • How to deploy your application as Multi-Target Application (MTA) to SAP BTP, Cloud Foundry runtime
iwonahahnIwona HahnOctober 10, 2022
Created by
iwonahahn
June 14, 2021
Contributors
iwonahahn
manjuX
slavipande
  • Step 1

    As a result of this tutorial, you have a running CAP application in the cloud based on SAP HANA. You will deploy the user interface later in the tutorial Add the SAP Launchpad Service.

    The deployment is based on MTA ( Multi-Target Application, sometimes also called MultiApps) technology. The MTA is a SAP-proprietary way to do deployments consisting of multiple modules that can be implemented in different technologies.

    Advantages compared to the cf push method:

    • A build tool
    • Automatically created service instances
    • Service keys
    • Destinations
    • Content deployment (HTML5, workflow, …)
    • Blue-green deployment
    1. Check if you have already installed the Cloud MTA Build Tool (MBT):

      Shell/Bash
      Copy
      mbt --version
      
    2. If you don’t get back a version number, install the MultiApps Archive Builder:

      Shell/Bash
      Copy
      npm install --global mbt
      

    If you encounter a problem with the installation of the MBT, install it manually by following the instructions in the MBT documentation.

    Which package adds multi-target application build support to your app?

  • Step 2

    To earn your badge for the whole mission, you will need to mark all steps in a tutorial as done, including any optional ones that you may have skipped because they are not relevant for you.

    The make tool is required by the mbt tool. Linux and macOS are already shipped with make. For Windows you can download it from the GNU Make site:

    1. Go to http://gnuwin32.sourceforge.net/packages/make.htm.
    2. Choose the download with the description Complete package, except sources.
    3. Run the installer.
    4. Enter Edit the System Environment Variables in the Windows search box (Windows icon in the task bar). The System Properties dialog is opened.
    5. Choose Environment Variables….
    6. Choose your Path environment variable under User Variables for <your_user_name> and choose Edit.
    7. Choose Browse and navigate to GNU make (usually C:\Program Files (x86)\GnuWin32\bin).
    8. Choose OK to add GNU make to your Path environment variable.
    9. Restart VS Code to make the change effective.
  • Step 3
  • Step 4

    When you run your CAP application, your locally installed Node.js version is used. Cloud Foundry supports multiple Node.js major versions (like 14 and 16) and usually uses the lowest available by default. Therefore, it is important to declare which Node.js version should be used.

    Node.js v16 is sufficient for this tutorial.

    Open the file package.json and add the following snippet:

    JSON
    Copy
    {
      ...
      "devDependencies": {
        ...
      },
      "engines": {
        "node": "^16"
      },
    
  • Step 5

    The MTA deployment is described in the MTA Deployment Descriptor, a file called mta.yaml.
    As the first step, you let the CAP server generate an initial mta.yaml file.

    Run the following command from the project root folder:

    Shell/Bash
    Copy
    cds add mta
    

    The file is generated based on your previously created settings in the package.json file.

    The mta.yaml file consists of different modules (Cloud Foundry apps) and resources (Cloud Foundry services).

    modules:

    • cpapp-srv - OData service
    • cpapp-db-deployer - Deploy CAP schema and data (CSV files) to database

    resources:

    The resources are generated from the requires section of cds in the package.json.

    • cpapp-db - SAP HANA DB HDMI container
    • cpapp-uaa - XSUAA service

    The resources are Cloud Foundry service instances that are automatically created and updated during the MTA deployment.

    Additional Documentation:

    Assigning Role Collections in SAP BTP documentation

  • Step 6

    In one of the first steps creating the CAP application, you have added two CSV files with test data. These files are required to pre-fill local testing with the SQLite memory. Without the files, the database would be empty after each restart.

    Test files should never be deployed to an SAP HANA database as table data.

    This can cause the deletion of all files of the affected database table with a change of a data file, even if the data file for the affected table has been removed before. SAP HANA remembers all data files that have ever been deployed to the table and might restore it. Only data files that contain data, which are defined by the application developer and can’t be changed by the application should be delivered in this way. Delivering files for tables with customer data already caused data loss in productive scenarios! See section Providing Initial Data in the CAP documentation for more details.

    Install the dependencies and to avoid any loss of data, you change the MTA build parameters to remove all the CSV files and the hdbtabledata that is generated by the CAP server out of the CSV files. Add the following line to the mta.yaml file:

    YAML
    Copy
    build-parameters:
      before-all:
       - builder: custom
         commands:
          - npm install --production
          - npx -p @sap/cds-dk cds build --production
          - npx rimraf gen/db/src/gen/data
    
  • Step 7

    The next step is to add the Authorization and Trust Management service to mta.yaml to allow user login, authorization, and authentication checks. Update the name and resource as shown.

    YAML
    Copy
    modules:
          - name: cpapp-srv
          ...
          requires:
            - name: cpapp-db
            - name: cpapp-uaa
    resources:
       ...
     - name: cpapp-uaa
       type: org.cloudfoundry.managed-service
       parameters:
         service: xsuaa
         service-plan: application
         path: ./xs-security.json
         config:
           xsappname: cpapp-${space}    #  name + space dependency
           tenant-mode: dedicated
           role-collections:
             - name: 'RiskManager-${space}'
               description: Manage Risks
               role-template-references:
                 - $XSAPPNAME.RiskManager
             - name: 'RiskViewer-${space}'
               description: View Risks
               role-template-references:
                 - $XSAPPNAME.RiskViewer
    

    The configuration for XSUAA is read from the xs-security.json file that was created in the tutorial Prepare User Authentication and Authorization (XSUAA) Setup.

    But in the config element, values can be added and overwritten.

    The value xsappname gets overwritten with a space-dependent value. The name has to be unique within a subaccount.

    This allows multiple deployments of this tutorial in different spaces of the same subaccount. For example, different people of a team that want to try it out and don’t want to create a new subaccount for each team member.

    For a productive application, the xsappname should be explicitly set to the desired value.

    Further, you can add role collections using the xs-security.json file. Since role collections need to be unique in a subaccount like the xsappname, you can add it here and use the ${space} variable to make them unique like for the xsappname.

    Alternatively, role collections can be manually assigned in the SAP BTP cockpit.

    Additional Documentation:

    Assigning Role Collections in SAP BTP documentation

  • Step 8

    Delete your older package-lock.json and run npm install --package-lock-only to generate it again to avoid errors due to use of older versions.

    1. Build the MTA module from your project root folder:

      Shell/Bash
      Copy
      mbt build -t ./
      

      This creates a mtar file cpapp_1.0.0.mtar in the current folder (option: -t ./).

      In case you get the error On Windows, this driver only supports the x64 architecture. You node process is: ia32, check if you have installed the right version of Node.js for your operating system.

    2. Deploy the module to your current Cloud Foundry space:

      Shell/Bash
      Copy
      cf deploy cpapp_1.0.0.mtar
      

      Your SAP HANA Cloud service instance will be automatically stopped overnight, according to the server region time zone. That means you need to restart your instance every day before you start working with it.

    3. The deployment can take some minutes. After successful deployment, check if all the services have been created:

      Shell/Bash
      Copy
      cf services
      

      You should see the following services in your space:

      cf services
    4. Check if the apps are running:

      Shell/Bash
      Copy
      cf apps
      
      cf apps

      You can also deploy a single module using -m <module-name> command line parameter.

    5. Enter the route displayed for cpapp-srv in your browser.

      cpapp-srv route

      You see the CAP start page, like this:

      CAP service index
    6. When you choose the Mitigation or Risk service entity, you will see an error message:

      CAP 403 error

    The service expects a so called JWT (JSON Web Token) in the HTTP Authorization header that contains the required authentication and authorization information to access the service. In the next tutorial, you will deploy the SAP Fiori UIs, so that you can access your UIs from SAP Fiori Launchpad. The Launchpad will trigger the authentication flow to provide the required token to access the service.

    The result of this tutorial can be found in the cap-mta-deployment branch.

Back to top