Explaining the Deployment Process

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.

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.

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

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

   Name	Description
   mta.yaml	Development descriptor for a multi-target application (MTA). The information in the mta.yaml file provides instructions for the MTA development and build process.
   mtad.yaml	Deployment descriptor for a multi-target application (MTA). The information in the mad.yaml file provides instructions for the deploy service.
   mtaext.yaml	Deployment 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 Types	Service	Service Plan	Created Service
     com.sap.xs.hana-sbss	hana	sbss	Service broker security
     com.sap.xs.hana-schema	hana	schema	Plain schema
     com.sap.xs.hana-securestore	hana	securestore	SAP HANA secure store
     com.sap.xs.hdi-container	hana	hdi-shared	HDI container
     com.sap.xs.jobscheduler	jobscheduler	default	Job Scheduler
     com.sap.xs.uaa	xsuaa	default	Global UAA service
     com.sap.xs.fs	fs-storage	free	File system storage
     com.sap.xs.uaa-devuser	xsuaa	devuser	Development-user UAA service
     com.sap.xs.uaa-space	xsuaa	space	UAA service for a space
     com.sap.xs.sds	sds	default	Smart 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

   Copy code

   Copy code

   Switch to dark mode

   Switch to dark mode

   1
   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.

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.

Example:

• Multi target applications in CF environment
• CAP deployment