Explaining the Deployment Process

After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Describe the Cloud Foundry deployment process of a CAP application
  • Describe the basic concepts about the MTA development project and understand the information contained in the mta.yaml file

The Deployment Process

Usage Scenario

Deploying a CAP application on SAP Business Technology Platform involves several steps, including setting up the required services, configuring the deployment environment, and deploying the application itself.

  1. Setup SAP BTP Environment:
    • Log in to the SAP BTP Cockpit.
    • Set up the necessary subaccounts and entitlements for the services you need.
    • Make sure the necessary entitlements for the Cloud Foundry environment are available.
  2. Prepare Your CAP Application:
    • Create your CAP project.
    • Ensure the application is ready for deployment and has the necessary configurations for the target environment.
    • Configure Deployment Settings in the mta.yaml file.
    • Define the required services and their bindings in the deployment descriptor.
  3. Build the Application:
    • Use the CAP tooling or the appropriate build tools to build the application.
    • Ensure that the application builds successfully without any errors or warnings.
  4. Deploy the Application:
    • Use the Cloud Foundry CLI or the SAP Business Application Studio to deploy the application to SAP BTP.
    • Monitor the deployment process for any errors or issues that might arise.

By following these steps, you can effectively deploy a CAP application on SAP BTP and ensure its smooth operation within the SAP cloud environment.

Deployment Process

  1. Considering step 1 in place (Access to SAP BTP, Cloud Foundry environment, a CF space created and a SAP HANA Cloud database instance configured and running), the focus will be on the next steps, starting with the preparation of the application for deployment.
  2. Prepare Your CAP Application:

    Prerequisites for preparing the application for deployment:

    1. SAP HANA Cloud database is configured in our CAP project: cds add hana --for production
    2. Authentication and authorization is configured by using the SAP Authorization and Trust Management Service: cds add xsuaa --for production This will generate an xs-security.json file, with roles/scopes derived from authorization-related annotations in the CDS models created. Ensure to rerun cds compile --to xsuaa in case of changes to the annotations in the project.
    3. Using Multi Target Application-Based Deployment For the actual execution of the deploument the Cloud MTA Build tool will be used (cloud mta build tool). cds add mta

    In order to understand the Multi-Target Application Project we will deep dive into the next subject: the MTA Development Project.

The Multi-Target Application (MTA) Development Project

Recent trends and progress for programming languages, software design architectures such as micro-services, protocols like OData, and the diversity of multi-tiered and distributed deployment platforms have accelerated the trend towards applications constructed out of smaller, decoupled and diverse modules.

Today, business applications are composed of multiple parts that are developed using different languages and technologies and deployed to a variety of target runtime environments. This diversity introduces many lifecycle challenges.

A Multi-Target Application (MTA) is comprised of multiple parts (modules), created with different technologies and deployed to different targets, but with a single, common lifecycle.

Simply put, an MTA is logically a single application, consisting of multiple related and interdependent parts (herein called modules) that are developed using different technologies or programming paradigms and designed to run on different target runtime environments, with a single, consistent lifecycle.

Development tools provided by SAP allow you to manage multiple applications (as "modules") in a unique development project, and deploy them via a unique archive file (MTA archive (MTAR)).

In SAP Business Application Studio we have options to either create a Basic MTA project or an SAP Cloud Application Programming Model (CAP) project. Throughout this course we developed the business application and the related artifacts using the project of type CAP having the following folder structure:

  • db : For the database level schema model.
  • srv : For the service definition layer
  • app : For UI artifacts

Describing the MTA Development Descriptor File

MTA Model An MTA model is a platform-independent description of the different application modules, their interdependencies and configuration data that they expose, and the resources they require to run. This model is specified, using YAML, in descriptor files that accompany the development and deployment processes.

An MTA model serves the following purposes:

  1. Define an application composed of multiple (heterogeneous) sub-components (benefit: tools can establish a unique lifecycle of these sub-components).
  2. Declare resources the application depends upon at runtime and/or deployment time (benefit: tools can allocate and bind such resources).
  3. Define configuration variables (and their relation), whose values distinguish different deployments of the application (benefit: tools can bind sub-components, can automate deployment based on default settings, or request missing mandatory values interactively).

    As seen in the image the application developer uses development tools to create the modules of an MTA and the corresponding MTA descriptor (mta.yaml).

    The application can then be distributed in the form of an MTA archive including the MTA deployment descriptor (mtad.yaml). This specification describes an archive format as a convenient distribution file. As indicated by the direct arrow from development tools to deployer,

    MTA deployers may also accept the pure contents of this format, namely the directory structure of files with a deployment descriptor (mtad.yaml).

    An administrator optionally augments the MTA model in the deployment descriptor with an extension descriptor(mtaext.yaml),and uses the MTA deployer to orchestrate the actual deployment.

    Different mta Files

    mta.yamlDevelopment descriptor for a multi-target application (MTA). The information in the mta.yaml file provides instructions for the MTA development and build process.
    mtad.yamlDeployment descriptor for a multi-target application (MTA). The information in the mad.yaml file provides instructions for the deploy service.
    mtaext.yamlDeployment extension descriptor (optional). This is used to provide system-specific details that are not known until deployment time.

    We will focus on the Development Descriptor file(mta.yaml). The MTA development descriptor contains the following parts:

    • Global elements: these include the application identifier and version, a description (optional), copyrights, author, and so on.
    • Modules: Modules created in the application, such as the SAP HANA database module and the Node.js module, including name, type, path and requirements on other modules.
    • Resources: A resource is something that is required by a module of the MTA at runtime, or at deployment time, but not provided inside the MTA. More precisely, an MTA descriptor declares a resource dependency, not the resource itself. Sometimes they are referred to as Backing Services, dependent services that are not provided by the application, such as XS Advanced User Account and Authentication (XSUAA), XS Advanced HANA Deployment Infrastructure (XSHDI) container, and XSJob-Scheduler.

      Here is the list of available Resource Types:

      Available Resource Types

      Resource TypesServiceService PlanCreated Service
      com.sap.xs.hana-sbsshanasbssService broker security
      com.sap.xs.hana-schemahanaschemaPlain schema
      com.sap.xs.hana-securestorehanasecurestoreSAP HANA secure store
      com.sap.xs.hdi-containerhanahdi-sharedHDI container
      com.sap.xs.jobschedulerjobschedulerdefaultJob Scheduler
      com.sap.xs.uaaxsuaadefaultGlobal UAA service
      com.sap.xs.fsfs-storagefreeFile system storage
      com.sap.xs.uaa-devuserxsuaadevuserDevelopment-user UAA service
      com.sap.xs.uaa-spacexsuaaspaceUAA service for a space
      com.sap.xs.sdssdsdefaultSmart data streaming
    • Properties: These can be specified when the value has to be determined during the deployment, for example, for generated URLs of other services or API keys.
    • Parameters: Reserved variables of a module, which can be accessed by other modules, for example, user, app-name, default-host, or default-uri using the placeholder notation. Parameters can be read-only or read/write enabled.
  4. Using Application Router

    It task are:

    The App Router acts as a single point-of-entry gateway to route requests to. In particular, it ensures user login and authentication in combination with XSUAA. It tasks are:
    • The App Router dispatches requests to our back-end microservices, thus acting as a reverse proxy. The back-end microservices should not be directly accessible by the client.
    • The App Router can serve static content such as web pages, SAPUI5, or another client-side code.
    • The App Router manages the authentication flows for our entire application. For authentication (who the user is) and authorization (what the user is allowed to do), the App Router takes all incoming, unauthenticated requests and initiates an OAuth2 flow (authorization code grant) with the Extended Services for User Account and Authentication (XSUAA) service of the SAP BTP in the Cloud Foundry environment .

    SAP offers two main options for using an approuter in the context of the Cloud Foundry environment: SAP Managed Approuter and Standalone Approuter.

    SAP Managed Approuter for scenarios where a launchpad is the entry point to access your applications. The managed approuter functionality comes with the subscription to SAP Build Workzone. The applications deployed with the managed approuter will will be available in the HTML5 repository. Standalone App Router: for special scenarios where the approuter extensibility is mandatory or for building multitenant applications (SAAS) on SAP BTP. The application deployed with this custom approuter will be available in the CF space.

    Use the following command to enhance the application configuration: cds add approuter --for production

    Use the following command to enhance the application configuration: cds add approuter --for production.

  5. Build the application

    Run the following command to generate additional deployment artifacts and prepare everything for production in a local ./gen folder as a staging area. While cds build is included in the next step when running mbt build, you can also run it selectively as a test, and to inspect what is generated.

    Code snippet
    cds build --production
  6. Deploy to Cloud Foundry

By running mbt build an archive file (MTA archive (MTAR)) will be created in the gen folder. In order to deploy the generated archive you need to run cf deploy gen/mta.tar. The url of the approuter application will appear at the end in the log output.

Graphical MTA Editor

As an alternative to the code editor for the MTA file, the SAP Business Application Studio also provides the possibility to use the graphical MTA editor to make changes. You can find the form-based editor on the context menu of the mta.yaml file.


In order to deploy a CAP application to Cloud Foundry there are specific steps that need to be ensured: the BTP Cloud Foundry environment is properly setup, the CAP application is prepared and the MTA descriptor file is configured by keeping in mind all the necessary bindings. With this the application will be successfully built and deployed.

Log in to track your progress & complete quizzes