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. Set up 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 generates 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 Multitarget Application-Based Deployment for the actual execution of the deployment of the Cloud MTA Build tool will be used (cloud mta build tool). cds add mta

   To understand the Multitarget 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 multitiered 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 various target runtime environments. This diversity introduces many life cycle challenges.

Watch the video to get introduced to the concept of a Multi-Target Application.

A Multitarget Application (MTA) is composed of multiple parts (modules), created with different technologies and deployed to different targets, but with a single, common life cycle.

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 life cycle.

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

Watch the video to learn about the design and run time of MTA.

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) subcomponents (benefit: tools can establish a unique life cycle of these subcomponents).
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 subcomponents, can automate deployment based on default settings, or request missing mandatory values interactively).

   Watch the video to learn about the development to deployment flow.

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

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

   Its tasks 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. Its tasks are:
   • The App Router dispatches requests to our backend microservices, thus acting as a reverse proxy. The backend 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 is 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 more 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 codeSwitch to dark mode

   1
   cds build --production

6. Deploy to Cloud Foundry

By running mbt build, an archive file (MTA archive (MTAR)) is created in the gen folder. To deploy the generated archive, you must run cf deploy gen/mta.tar. The url of the approuter application appears 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.

To deploy a CAP application to Cloud Foundry, there are specific steps that must 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 is successfully built and deployed.

Example:

• Multitarget applications in CF environment
• CAP deployment