Skip to content
Search

    Deploy & Operate

    Towards SAP Business Technology Platform

    CAP applications can be deployed to the Cloud Foundry environment of SAP BTP. At the end, it’s about deploying Node.js and Java applications, and about creating and binding appropriate service instances. See the Cloud Foundry Developer Guide for more details.

    The following sections are based on our cap/samples bookshop project.

    Prepare for Production

    Add SAP HANA Configuration

    cds add hana
    

    Learn more about configuration for the Node.js and Java runtime.

    You can omit this step, if your deployment doesn’t need a database.

    Add MTA Configuration

    For clean, production-like (pipeline) builds and deployments, we enhance our application to become a Multitarget Application (MTA). The Cloud MTA build Tool creates a self-contained MTA archive, packaging the different parts of the application (database, service, and UI).

    Create the MTA development descriptor mta.yaml in the project’s root:

    cds add mta
    

    You can extend generated descriptors with your own MTA extension descriptors.

    Learn more about the cds command line client.

    Install Dependencies

    Local NPM Registry → cap/samples Only

    As cap/samples is designed as monorepo, this one step is only needed for this repository. In your samples folder (the root of cap/samples), install all dependencies and start your local NPM registry. This enables you to use the different samples within cap/samples as dependencies in each samples package.json, like @capire.common. This terminal has to stay open.

    npm install
    npm run registry
    

    The output is like this:

    $ user: samples $ npm run registry
    
    > @capire/samples@2.0.0 registry C:\Users\some\path\samples
    > node .registry/server.js
    
    npm set @capire:registry=http://localhost:4444
    @capire registry listening on http://localhost:4444
    

    To go on with the next steps open a new terminal and go to the bookshop sample.

    cd bookshop
    

    Use npm install

    To be ready to build a deployable archive, install all your dependencies and fix them in a package-lock.json. This includes fixed versions for all your dependencies, also along the dependency chain. The following command does all this for you.

    npm install
    

    As this step fixes versions, you can’t benefit from the monorepo setup anymore, when you’re in a development scenario w/o deployment.
    To use cap/samples again as monorepo, delete the node_modules folder.

    Learn more about dependency management for Node.js

    Build & Assemble

    Execute:

    mbt build
    

    An archive with extension .mtar is created in the mta_archives folder.

    This requires the Cloud MTA Build Tool.

    Got errors? See the troubleshooting guide.

    Deploy to SAP BTP, Cloud Foundry

    Execute:

    cf deploy mta_archives/capire.bookshop_1.0.0.mtar
    

    Requires:
    MTA plugin for the CF CLI
    cf command line client
    Login to an SAP BTP (Trial) Account

    This process can take some minutes.

    Identify the URL of the bookshop-srv application from the log output.

    user: bookshop $ cf deploy mta_archives/capire.bookshop_1.0.0.mtar
    [..]
    Starting application "bookshop-srv"...
    Application "bookshop-srv" started and available
    at "acmeorg-acmespace-bookshop-srv.landscape-domain.com"
    [..]
    

    Open this URL in your browser.

    Got errors? See the troubleshooting guide.

    More Deploy Options

    Reducing MTA Size During Development

    MTA files can reach considerable size due to the node_modules folder being included. If you use MTAs during development, you can omit that folder from the archive, provided that all your dependencies are available on the public registry npmjs.org.

    To do that, first add a file bookshop.mtaext with this content:

    _schema-version: '3.1'
    ID: bookshop-small
    extends: bookshop
    
    modules:
     - name: bookshop-srv
       build-parameters:
         ignore: ["node_modules/"]
    

    Then rebuild with:

    mbt build -e bookshop.mtaext
    

    This speeds up the build significantly as there is less content that is packaged. Since the archive is smaller the upload (cf deploy) is also much faster compared to an archive containing the node_modules folder.

    Deploy Using Manifest Files

    As an alternative to MTA-based deployment, CAP also supports Cloud Foundry native deployment using cf push or cf create-service-push, which creates services and pushes the applications with a single CLI command.

    Install the Create-Service-Push Plugin

    cf install-plugin Create-Service-Push
    

    This plugin acts the same way as cf push, but extends it such that services are created first. With the plain cf push command, this is not possible.

    Create the Deployment Descriptors

    cds add cf-manifest
    

    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 CF services shall be created. The services are derived from the service bindings in package.json using the cds.requires configuration.

    On trial landscapes, if you’re not using SAP HANA Cloud, replace the broker type hana by hanatrial in services-manifest.yml.

    Unlike the files in the gen folders, these manifest files are genuine sources and should be added to the source control system. This way, you can adjust them to your needs as you evolve your application.

    Build the Project

    This prepares everything for deployment, and – by default – writes the build output, that is the deployment artifacts, to folder ./gen in your project root.

    cds build --production
    

    Learn how cds build can be configured.

    The --production parameter ensures that the cloud deployment-related artifacts are created by cds build. See section SAP HANA database deployment for more details.

    The step cds build also generates a manifest.yml file in the build staging folder. This file is redundant and will be removed in a future version.

    Push the Application

    cf create-service-push  # or `cf cspush` in short from 1.3.2 onwards
    

    This 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 deploy log, find the application URL in the routes line at the end:

    name:              bookshop-srv
    requested state:   started
    routes:            bookshop-srv-....cfapps.sap.hana.ondemand.com
    

    Open this URL in the browser and try out the provided links, for example, .../browse/Books. Application data is fetched from SAP HANA.

    To ensure that SAP HANA deployment was successful, check the deployment logs of the database deployer application (cf logs <app-name>-db-deployer --recent). 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.

    The SAP Fiori Preview, that you are used to see from local development, is only available for the development profile and not available in this scenario. 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.

    Got errors? See the troubleshooting guide.

    Deploy using CI/CD Pipeline

    We recommend setting up continuous integration and delivery (CI/CD) pipelines for your CAP projects to speed up your development and delivery cycles. SAP offers you two solutions that help you apply CI/CD in your software development. You can choose either way, depending on your requirements and expertise.

    Learn more about SAP Solutions for Continuous Integration and Delivery.

    Managed SAP Continuous Integration and Delivery Service on SAP BTP

    SAP Continuous Integration and Delivery is a service on SAP BTP, which lets you configure and run predefined continuous integration and delivery pipelines. It connects with your Git SCM repository and in its user interface, you can easily monitor the status of your builds and detect errors as soon as possible, which helps you prevent integration problems before completing your development.

    SAP Continuous Integration and Delivery has a ready-to-use pipeline for CAP, that is applicable to Node.js, Java and multitarget application (MTA) based projects. It does not require you to host your own Jenkins instance and it provides an easy, UI-guided way to configure your pipelines.

    Try the tutorial Configure and Run a Predefined SAP Continuous Integration and Delivery (CI/CD) Pipeline to configure a CI/CD pipeline that builds, tests, and deploys your code changes.

    Learn more about SAP Continuous Integration and Delivery.

    Project “Piper”

    Project “Piper” is a solution for continuous integration and delivery that offers the flexibility to set up and extend fully customized pipelines. It is an open-source project that provides preconfigured Jenkins pipelines, which you can use in your own Jenkins master infrastructure and adapt according to your needs. It consists of:

    • A shared library, which contains the description of steps, scenarios, and utilities that are required to use Jenkins pipelines
    • A set of Docker images that can be used out-of-the-box to implement best practice processes

    Try the tutorial Add Automated System Tests for CAP-Based Projects to Your CI/CD Pipeline to create system tests against a CAP-based sample application and automate your tests through a CI/CD pipeline.

    Build Configuration

    cds build executes build tasks on your project folders to prepare them for deployment. Build tasks compile source files (typically CDS sources) and create the required artifacts, for example, EDMX files, SAP HANA design-time artifacts, etc. All known root folders (app, db, and srv) or those configured in the build tasks are built.

    By default, cds build derives build tasks from the project contents:

    • A hana build task is created if an SAP HANA service binding is defined.
    • A node-cf build task for projects using the Nodejs runtime.
    • A java-cf build task for projects using the CAP Java SDK.
    • A mtx build task for multitenancy projects using the Node.js runtime. For Java projects, a mtx build task has to be configured manually as it is not created by default.

    To control which tasks cds build executes, you can add them as part of your project configuration in package.json or .cdsrc.json.

    The following build tasks are a default configuration used for Node.js projects:

    {
      "build": {
        "target": "gen",
        "tasks": [
          {"for":"hana",    "src":"db",  "options": {"model": ["db","srv"] }},
          {"for":"node-cf", "src":"srv", "options": {"model": ["db","srv"] }}
        ]
      }
    }
    

    The executed build tasks are logged to the command line. You can use them as a blue print – copy & paste them into your CDS configuration and adapt them to your needs. See also the command line help for further details using cds build --help.

    Target Folder

    • For Node.js projects, the “gen” folder below the application root is used by default. All source files are copied to it by cds build, which makes it a self-contained folder that is ready for deployment.
    • For Java projects, the symbolic "." folder is used by default, which means that the build output is stored below the individual source folders. For example, db/src/gen would contain the build output of the default db folder. No source files are copied to db/src/gen because they’re assumed to be deployed from the db folder itself.

    If you want to change the default target folder, use the target property in your package.json.

    "cds": { "build": { "target" : "custom/folder"}}
    

    It’s resolved based on the application’s root folder.

    Build Task Properties

    • for: Target technology for which the build is executed. Currently supported types are:
      • node-cf: Creates a deployment layout for Node.js apps on Cloud Foundry.
      • java-cf: Creates a deployment layout for Java apps on Cloud Foundry.
      • hana: Creates a deployment layout for SAP HANA HDI.
      • mtx: Creates a deployment layout for multitenant applications.
      • fiori: Creates a deployment layout for SAP Fiori.
    • src: Source folder of the module that is about to be build.
    • dest: Optional destination of the modules builds, relative to the enclosing project. The src folder is used by default.
    • options: Sets technology-specific options according to the target technology. The target technologies node-cf, java-cf, and hana support the option model, which can be either of type string or string array. The cds build uses the given folders or .cds files as input for resolving the entire CDS model.

    Deploy as SaaS

    Deploy SaaS Solutions