After completing the functional implementation of your CAP application by following the Getting Started or Cookbook guides, you would finally deploy it to the cloud for production. The essential steps are illustrated in the following graphic:
First, you apply these steps manually in an ad-hoc deployment, as described in this guide. Then, after successful deployment, you automate them using CI/CD pipelines.
This guide is available for Node.js and Java. Press v to switch, or use the toggle.
If you followed CAP's grow-as-you-go approach so far, you've developed your application with an in-memory database and basic/mock authentication. To prepare for production you need to ensure respective production-grade choices are configured, as illustrated in the following graphic:
We'll use the cds add <facets> CLI command for that, which ensures the required services are configured correctly and corresponding package dependencies are added to your package.json.
This will also generate an xs-security.json file, with roles/scopes derived from authorization-related annotations in your CDS models. Ensure to rerun cds compile --to xsuaa, as documented in the Authorization guide whenever there are changes to these annotations.
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.
Two deployment options are available:
Managed App Router: for scenarios where SAP Fiori Launchpad (FLP) is the entry point to access your applications, the Managed App Router provided by SAP Fiori Launchpad is available. See the end-to-end tutorial for the necessary configuration in mta.yaml and on each SAP Fiori application.
Custom App Router: for scenarios without SAP Fiori Launchpad, the app router needs to be deployed along with your application. Use the following command to enhance the application configuration:
Run cds build 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 mbt build, you can also run it selectively as a test, and to inspect what is generated:
This creates two files, a manifest.yml and services-manifest.yml in the project root folder.
manifest.yml holds the applications. In the default layout, one application is the actual server holding the service implementations, and the other one is a 'DB deployer' application, whose sole purpose is to start the SAP HANA deployment.
services-manifest.yml defines which Cloud Foundry services shall be created. The services are derived from the service bindings in package.json using the cds.requires configuration.
Version-control manifest files
Unlike the files in the gen folders, these manifest files are genuine sources and should be added to the version control system. This way, you can adjust them to your needs as you evolve your application.
This command creates service instances, pushes the applications and binds the services to the application with a single call:
During deployment, the plugin reads the services-manifest.yml file and creates the services listed there. It then reads manifest.yml, pushes the applications defined there, and binds these applications to service instances created before. If the service instances already exist, only the cf push operation will be executed.
You can also apply some shortcuts:
Use cf push directly to deploy either all applications, or cf push <app-name> to deploy a single application.
Use cf create-service-push --no-push to only create or update service-related data without pushing the applications.
In the deployment log, find the application URL in the routes line at the end:
Open this URL in the browser and try out the provided links, for example, …/browse/Books. Application data is fetched from SAP HANA.
Ensure successful HANA deployment
Check the deployment logs of the database deployer application using
to ensure that SAP HANA deployment was successful. The application itself is by default in state started after HDI deployment has finished, even if the HDI deployer returned an error. To save resources, you can explicitly stop the deployer application afterwards.
No Fiori preview in the cloud
The SAP Fiori Preview, that you are used to see from local development, is only available for the development profile and not available in the cloud. For productive applications, you should add a proper SAP Fiori application.
Multitenant applications are not supported yet as multitenancy-related settings are not added to the generated descriptors. The data has to be entered manually.