Build an SAP CAP Application With SAP Build Code & CockroachDB

Enter CockroachDB, a nextgen-SQL database with which I have garnered quite an interest in. As such, I wish to accomplish a few things with this blog :

Demonstrate the inherent flexibility of the SAP CAP framework, through it’s ability to leverage non-SAP data storage as it’s persistency layer, while keeping the application on track with SAP best practice recommendations for development on SAP BTP (open yet opinionated).Have this blog serve as a neat and tidy reference point for any of my colleagues who may at some point have such a requirement to create an application in SAP CAP with date persisted within CockroachDB.Inform those that are new to application development on SAP BTP as to what is SAP CAP, SAP Build Code, Cloud Foundry, Fiori, CDS, etc., as well as the uninitiated as to what is CockroachDB, and Sequelize.

So, this will serve as a place for those who are new to application development on SAP BTP and the CAP Framework to get some guidance as to the moving parts involved, as well as for those who are experienced but are looking for perhaps some new use case for the framework. I’ve done some scouring and haven’t seen any materials on integration between SAP CAP and CockroachDB, so if my humble blog makes a splash, I hope it’s a good, and informative one for all.

I will be making the assumption that those reading are at least familiar with what SAP BTP is, so I will not be doing a deep dive into that specifically. With that being said, I will break this up into the following table of contents :

What is SAP CAP?What is CockroachDB?What is Sequelize?What is SAP Build Code?Creating our project and source code walkthrough.What is the Cloud Foundry?Deployment and accessing from SAP BTP Subaccount.

Throughout the blog I will also provide links to any documentation, and videos which are relevant to the section if you are interested in learning more. With that being said, let’s get started.

What is SAP CAP?

The SAP Cloud Application Programming Model, often abbreviated to SAP CAP or SAP CAPM, is a development framework meant specifically for developing applications on the SAP Business Technology Platform, or SAP BTP.

It is an open, yet opinionated model, meaning that it does provide a degree of freedom and flexibility in regards to a number of factors :

UI Technology – SAP CAP apps can leverage any UI technology. The recommended is SAP Fiori or UI5, however front-ends can be developed in any framework (Angular, Vue, React, etc.).Persistency Layer – The point of this blog! While of course SAP CAP has out of the box capabilities to interact with and bind to SAP HANA Cloud, you can leverage your desired persistency layer (CockroachDB, MongoDB, Cassandra, etc.).Development Stack – Currently there are 2 supported development stacks for creating SAP CAP applications, Node.js, and Java Springboot.Development Environment – You can create SAP CAP applications in any IDE, you will just need to install the appropriate extensions (CDS, Cloud Foundry Command Line, MBT, etc.). The necessary extensions come built in on SAP Build Code, which is SAP BTP’s platform native IDE built on top of VS Code, and has embedded Gen AI capabilities via SAP joule. This will be the development environment we utilize in this blog.

So you do have a variety of options for what with, and where you develop your applications. However, even with this flexibility, the framework ensures you are in alignment with SAP best practices when developing and deploying applications on SAP BTP.

As mentioned, we have 2 development stacks we can leverage for developing our SAP CAP applications. In our blog we will be utilizing Node.js, this is used for our custom business logic in our application’s service layer.

The server itself is defined, and started using what’s called Core Data Services, or CDS. Those coming from an on-premise SAP S/4HANA or SAP ECC development background are more likely than not acquainted with CDS. Similarly to how things are in these systems, in SAP CAP, CDS is used to define entities within our project. However, it is also used to construct queries to communicate with our persistency layer, and interact with our project (for example, start a local server for testing our application, add files and dependencies to our projects, etc.). CDS services defined in SAP CAP are exposed as OData Services, which is a protocol that can be leveraged to create RESTFUL APIs.

To learn more about the CAP Framework, here’s the link to the official documentation :

Home | capire

For our UI layer, as mentioned you can utilize a variety of front-end frameworks. However, for our project we will be utilizing SAP UI5, which can be utilized to create a unified user-experience across your developments within your SAP landscape. Within the context of development on SAP BTP, we have two flavorings of UI5 development :

UI5 freestyle – traditional UI5 development, create the entire project from scratch and your developers own all the source code (views, controllers, etc.).Fiori elements – a selection of UI5 template applications which can be used out of the box. The underlying codebase is managed by SAP, however you do have access to elements of the UI5 application such as the deployment files, manifest, etc. Controllers and views can be modified via fragments.

For our UI, we will be leveraging a Fiori elements template for a List Report application to view Sales Order data. To learn more about UI5, refer to the following link :

Demo Kit – SAPUI5 SDK

This data, of course, will be stored in CockroachDB.

What is CockroachDB?

CockroachDB is an open source, nextgen-distributed-SQL database. It’s somewhat less-than-charming name is in reference to one of its core qualities, resiliency. It is cloud hosted, and similar to SAP BTP, you can select what region/hyperscaler combination will host your cluster. Within this cluster your various databases will be hosted.

Under the hood it leverages PostgreSQL wire protocol for communication with databases. Since it is open source as well, you can of course browse the source code in the github repository.

Refer to the following links to learn more about CockroachDB, and also browse the github repo :

Documentation : CockroachDB Docs

Github Repository : GitHub – cockroachdb/cockroach: CockroachDB — the cloud native, distributed SQL database designed fo…

To create a cluster, navigate to CockroachDB’s website (CockroachDB | Distributed SQL for always-on customer experiences), and create an account by clicking, Get Started Free. Once your account is created you can create a cluster.

When creating a cluster you will have to select a region/hyperscaler combination. You can provision your cluster either on AWS or GCP. Ideally, depending on the region/hyperscaler combination of your SAP BTP subaccount, you should locate your cluster close to that. For example my SAP BTP trial subaccount is hosted on AWS US East, so I selected that as the host for my cluster.

It will take a bit for your cluster to create, but once created, you will be presented with credentials to access your cluster and databases. One of these is a connection string. Copy this and save it for later, you will be using this to communicate with the cluster, and the databases within it from your SAP CAP application.

Looking at the databases within the cluster, defaultdb is where your tables and such will actually be stored. To persist an initial collection of data, you can utilize the SQL console to create an initial table, and insert some initial records.

In our case, we want to create a Sales Orders table, and it will have the following fields :

orderid: Integer Primary Keyprice: Integer (for sake of simplicity)productname: Varcharcountry: Varcharbuyer: Varchar

With our table created, initial pool of records inserted, and connection string saved, let’s talk about how we will actually communicate with this database using Sequelize.

What is Sequelize?

Sequelize is a Object Relational Mapping, or ORM, which is available as a JavaScript package that you can download. An ORM is effectively a library which we can use to manifest tables which exist within our database, as objects within a given language or framework. So for example here, we will leverage Sequelize to define a JavaScript object which is a local representation of our Sales Order table.

ORMs are nice since it allows your application developers to interact with the persistency layer as if they were interacting with an object within the language of the application, as opposed to having to write SQL queries within the app and send them to the backend. SAP CAP also has an ORM in this sense, it’s provided through CDS and is called CDS Query Language, or CQL. This, however, doesn’t seem to be supported for CockroachDB, so Sequelize will be our ORM.

There are different Sequelize packages depending on the database your looking to leverage and communicate with, for example there are specific packages for Postgres, MySQL, and luckily for us, CockroachDB. There is also a library used to translate OData requests into Sequelizes own query language, this way we don’t need to manually construct the queries ourselves, it’s called “odata-sequelize.” This native Sequelize query notation is then translated into SQL in CockroachDB.

Refer to the following links to learn more about Sequelize itself, and the packages we will be using in our project :

Sequelize official site : Sequelize | Feature-rich ORM for modern TypeScript & JavaScript

Sequelize package docs : sequelize – npm

Sequelize CockroachDB package docs : sequelize-cockroachdb – npm

Sequelize OData Parser package docs : odata-sequelize – npm

Now that we understand our framework, our database, and our ORM which will be used to interact with that database, let’s talk about our IDE.

What is SAP Build Code?

SAP Build Code is SAP BTP’s platform native professional integrated development environment. All that meaning that it’s a browser based IDE hosted out of BTP that you can subscribe to from a subaccount. It is based on Visual Studio Code, so it’s look and feel should be very familiar to folks who have worked in that environment before.

SAP Build Code comes with a variety of extensions which you otherwise would have to configure on every developers machine for developing applications and deploying them to SAP BTP. Some of these tools include :

CDS CLI – A command line interface for interacting with your project via cds. This can be used to initialize a project, add files and dependencies to a project, and build your project.Link : CDS Command Line Interface (CLI) | capireCloud Foundry Command Line Interface – Command line tool for interacting with the Cloud Foundry Runtime Environment. We will go into detail about the runtime itself in a later section, but it will be needed for deploying our application to BTP to make it accessible to our end users.Link : Using the Cloud Foundry Command Line Interface (cf CLI) | Cloud Foundry DocsMTA Build Tools (MBT) – This will be used to compile our deployment configuration, a file called an MTA.yaml, into a format which is actually able to be understood by the Cloud Foundry environment. We will talk more about MTAs as we progress.Link : Cloud MTA Build Tool

These, alongside other tools such as git, come out of the box with SAP Build Code, so all you need to do to get your developers started with everything they need is to onboard them to the environment in SAP BTP.

SAP Build Code utilizes Dev Spaces as development environments. Under the hood these Dev Spaces are Kubernetes clusters with their own memory, which you will need to get running in order to access your development environment. For our purposes, and really all you need to concern yourself with, is that they are boxes which serve as isolated development environments within your SAP Build Code tenant.

To learn more about SAP Build Code, and get some additional hands on practice with more tutorials, please take a look at its entry in the SAP Discovery Center : SAP Discovery Center Service – SAP Build Code.

Each has its own file storage, as mentioned, as well as extensions intended to cater to a particular project type. For example, there are dev spaces for Full Stack Cloud Apps, Fiori Apps, and Mobile Apps. Full Stack Cloud Apps comes with CDS tools, as well as MBT for CAP development, Fiori Apps dev spaces come with extensions like the layout editor for drag and drop based development of UI5 front ends, and the Mobile dev spaces come with the Mobile Development Kit for creation of cross-platform applications.

So for us to get started, you will need to create a new project, and assign it to a dev space. This can be done by navigating to your SAP Build Code subscription, and clicking create. If you don’t have a SAP Build Code subscription, refer to the documentation to run the booster to get it setup. The booster is the recommended approach, as opposed to trying to setup it up manually : Initial Setup | SAP Help Portal.

Select application as your project type, then select SAP Build Code as your development environment.

Select Full Stack Cloud Application, this will create an application in a Full Stack Cloud App dev space, when you create an SAP Build Code subscription, this dev space already exists for you. You can select the existing one, or create a new one.

Enter the name of your project, the development stack is Node.js. Then click create, and click on the project to see the status of your dev space. Once it’s running you can click on the project name which will serve as a link to the dev space.

Creating our project and source code walkthrough.

In your dev space, when you create a new project in SAP Build Code, it will create a project structure for you. We’re going to create a project from the ground up. So, within the projects directory, create a new folder for our project called, CockroachDB-Project.

Navigate to this newly created project, and type in the command cds init.

See that this adds a number of things. Most importantly to us it adds :

A package.json file for our dependenciesFolders for the following layers of our app :DB – Our database schemas will be defined here. For this particular project, we won’t be leveraging this directory.App – Where our UI layer(s) will be defined which will reference our OData Service defined in the srv folder.Srv – This is where our backend is defined. This is where we will define our OData Service, as well as our custom business logic for that service in the form of event handlers.

Next, type cds add mta. This adds that mta.yaml file briefly mentioned earlier. MTA stands for Multi Target Application. It allows you to define what effectively boils down to a number of applications which share a lifecycle, so they are defined within a single deployable. These applications you are looking to deploy are defined within the modules, section.

These modules have dependencies on resources, which are Cloud Foundry services which our application will consume to perform its necessary functions. For example, the destination service for communicating with our service layer. We will also create a user-defined service within our Cloud Foundry environment which will point to our CockroachDB cluster.

Next, we will install some npm packages :

Sequelize – will allow us to interface with the Sequelize ORM.Sequelize-cockroachdb – specific Sequelize library for working with CockroachDB.Odata-sequelize – will allow us to translate OData URL queries into Sequelize query syntax.@SAP/xssec – we will be making use of the SAP Authorization and Trust Management Service in our app, this package is necessary for the usage of that service.Cfenv – a package leveraged for communicating with the environment our application will be deployed to. We will need this to reference environment variables which contain the credentials needed for communicating with our CockroachDB.

With this done, we can now start defining our service layer. To do this, we need to create 2 files in the srv folder, one we will call sales.cds, the other, sales.js. The names being the same is important, as the CAP Framework recognizes the JavaScript file as the business logic for the CDS layer of the same name.

Within the sales.cds file, define the following OData service and entity :

service sales_service{
entity sales_orders{
key orderid: Integer;
price: Integer;
productname: String;
country: String;
buyer: String;
};
};

We define it effectively as a one-to-one mapping to the entity we have defined in our CockroachDB. While here we are listing all the fields, you can define only a select few fields here if you wish to only expose a handful of properties to your application. This effectively serves as an OData Select statement where we specify what fields we want to expose.

Navigate to the sales.js file, and enter the following code. I have written in the comments what each function does, such that you can read through the source code and understand what everything is doing.

//These below lines will import the necessary packages we installed to our logic file, so we can utilize them.
const cds = require(‘@sap/cds’);
const Sequelize = require(‘sequelize-cockroachdb’);
const odataParse = require(‘odata-sequelize’);
const cfenv = require(‘cfenv’);

module.exports = async srv =>{

//calls a custom connectToDB function we have defined here, returns a client connection we can use to communicate
//with our CockroachDB cluster.
const cockroachdb = connectToDB();
//Calls a custom function which will define our sales orders object as a manifestation on the sales orders table
//in CockroachDB
const sales_orders = defineSalesOrders(cockroachdb);

//Event listener function for when we perform a READ request on our sales_orders entity in our
//OData service.
srv.on(‘READ’, ‘sales_orders’, async (req)=>{

//If we have filter criteria in our OData request, we want to leverage these criteria in our get request to
//our CockroachDB.
if(req._queryOptions != null){
//If we have an orderid passed in the OData READ request, but the OData $filter query option isn’t available
//we need to add it.
if(req.data.orderid != undefined){
req._queryOptions.$filter = `orderid eq ${req.data.orderid}`;
}
//We call a custom function to generate the OData request url (we don’t have access to it in the req object),
//this will then be translated via the sequelize-odata package into Sequelize query syntax.
const odataReq = generateODataUrl(req._queryOptions);
//Ensures that what is returned from the get request is the raw data, i.e. an array of JSON objects.
odataReq.raw = true;
const salesOrders = await sales_orders.findAll(odataReq).catch(err =>{
console.error(“Error: “, err);
});
//When we define our Fiori Elements UI, Fiori elements requires the service layer to return a $count field,
//which contains the number of records in the results of the READ request. If this isn’t present,
//no data will be present in the UI, even if records are returned.
salesOrders.$count = salesOrders.length;
return salesOrders;
}else{
//Fetch all the records from our sales orders table.
const all_orders = await sales_orders.findAll({raw: true});
all_orders.$count = all_orders.length;
return all_orders;
}
});

//Event listener for when we wish to delete a sales order.
srv.on(‘DELETE’, ‘sales_orders’, async (req) =>{
//Get the id of the sales order we’re looking to delete.
const orderid = req.data.orderid;
//Destroy is Sequelize’s delete function, we call this with the necessary filter criteria.
const salesOrder = await sales_orders.destroy({where: {orderid}, raw: true}).catch(err =>{
console.error(“Error: “, err);
});

return salesOrder;
});

//Event listener for when we create a new sales order.
srv.on(‘CREATE’, ‘sales_orders’, async (req) =>{
//Get the fields from the CREATE request which details the elements of the sales order
//we want to create.
const new_order = req.data;

//Create the sales order, and save it to the CockroachDB database.
const created_order = await sales_orders.create({orderid: new_order.orderid, price: new_order.price,
productname: new_order.productname, country: new_order.country, buyer: new_order.buyer}).catch(err =>{
console.error(“Error: “, err);
});
return created_order;

});

//Event listener for when we want to update a sales order.
srv.on(‘PUT’, ‘sales_orders’, async (req) =>{
//Get the details of the sales order in the request we want to update.
const orderToUpdate = req.data;

//Update the sales order with the values from the UPDATE request.
const updatedOrder = await sales_orders.update({price: req.data.price, productname: orderToUpdate.productname,
country: orderToUpdate.country, buyer: orderToUpdate.buyer
},{
where:{
orderid: orderToUpdate.orderid
}
}).catch(err =>{
console.error(“Error: “, err);
});

//If no rows were modified in our update request, we log the error.
if(updatedOrder === 0){
console.error(“Error: Updated Failed!”);
}

});

//Our custom function to connect to our CockroachDB cluster.
function connectToDB(){
//Use the cfenv library to get the details of our Cloud Foundry environment where our app is running within.
//const appEnv = cfenv.getAppEnv();
//Get the connection string from our user defined service in the Cloud Foundry.
//Use this line when you are DEPLOYING the app.
//const connectionString = appEnv.getServiceCreds(‘anthony-cockroachdb’).host;
//Provide your actual connection string to test things locally, REMOVE this line when you deploy your application.
const connectionString = “your connection string”;
//Create a new connection to our CockroachDB cluster using the connection string.
const cockroachdb = new Sequelize(connectionString);

return cockroachdb;
}

//Custom function for defining our sales orders object as a projection on our sales orders table in
//CockroachDB
function defineSalesOrders(cockroachdb){
const sales_orders_inventory = cockroachdb.define(“sales_orders”,{
orderid:{
type:Sequelize.DataTypes.INTEGER,
primaryKey:true
},
price:{
type:Sequelize.DataTypes.INTEGER
},
productname:{
type:Sequelize.DataTypes.TEXT
},
country:{
type:Sequelize.DataTypes.TEXT
},
buyer:{
type:Sequelize.DataTypes.TEXT
}
},
//If these fields aren’t specified, will lead to your application expecting columns ‘createdAt,’ and, ‘updatedAt.’
//Which we don’t have, so we want to set these following paramters to false to avoid errors.
{timestamps: false,
createdAt: false,
updatedAt: false});
return sales_orders_inventory;

}

//Custom function for constructing the OData request URL.
function generateODataUrl(queryOptions){
let odataQuery = [];

//We check to see if certain query options exist, and if so, we add them to the odataQuery array.
//This is a handful of query options, you of course can add more.
if(queryOptions.$filter != null){
odataQuery.push(`$filter=${queryOptions.$filter}`);
}
if(queryOptions.$top != null){
odataQuery.push(`$top=${queryOptions.$top}`);
}
if(queryOptions.$orderby != null){
odataQuery.push(`$orderby=${queryOptions.$orderby}`);
}
if(queryOptions.$skip != null){
odataQuery.push(`$skip=${queryOptions.$skip}`);
}
if(queryOptions.$count != null){
odataQuery.push(`$count=${queryOptions.$count}`);
}

//convert the array to a string, and replace all comma separation with &.
let finalOdataQuery = odataQuery.toString();
finalOdataQuery = finalOdataQuery.replaceAll(“,”,”&”);

//If there is a select query option, add it to the request string.
if(queryOptions.$select != null){
if(odataQuery.length > 0){
finalOdataQuery = `$select=${queryOptions.$select}&`+finalOdataQuery;
}else{
finalOdataQuery=`$select=${queryOptions.$select}`;
}
}

//Convert the OData request string into Sequelize query syntax, and return it.
const sequelizeOdata = odataParse(finalOdataQuery, Sequelize);
return sequelizeOdata;
}

}

You can test your various CRUD operations using a test.http, file in your project’s root directory. I have included a sample here. To send a request, click the, “send request,” link above the different HTTP operation sections.

With this we are now ready to create our UI. Before we do this we want to add an Approuter module to our MTA deployment descriptor file. An Approuter is an artefact within our application which is responsible for routing requests from the UI layer of our application to our CAP OData Service, it serves as a client to the XSUAA service for authentication and authorization in our application, and it also tells SAP BTP where our UI application is going to live.

There are 2 distinct versions of an Approuter, a Standalone and a Managed Approuter. All you need to concern yourself with for now, is that a Standalone Approuter deployment causes the UI to live within the Cloud Foundry environment, a Managed Approuter deployment has that UI layer live in the subaccount in something called the HTML5 apps repository. For our deployment, we will use a managed Approuter.

To add the Approuter, right click your mta.yaml file, and select create mta module from template.

Select Add Approuter Module, and enter the necessary details. This will add the Approuter configuration to your mta.yaml file for when we deploy this project.

Now that we have our Approuter configured, we can go and create our UI layer using Fiori elements. To do this, click, view > command palette, and select, Fiori: Open Application Generator.

This will present to you a number of application types, one of the types is UI5 freestyle, the remaining templates are Fiori Elements applications. Select, list report application.

Our data source will be our local CAP project, and our OData service will be our Sales Orders OData service defined in our sales.cds, file.

Our main entity will be our sales orders, leave the remaining values as the defaults.

Enter a module name, recall modules are the applications deployed by the mta.yaml file, so give it a meaningful application name. The application title will be what users see within the UI of the app, so again give it a meaningful title. Select, Yes, to, Add deployment configuration to MTA project.

The deployment target is the Cloud Foundry, and for the destination, select Local CAP Api.

Once finished, if you expand the app folder, you will see that the wizard added the files for our UI layer upon completion for us. We’re not going to walk through the various files for the UI, instead we will now test our UI layer.

To do so, again run, cds watch, and open up the local server. You will see now that there are links to webapps available, click the one for your UI layer.

Now that we have our various layers defined, and our deployment configuration set. Let’s talk about where we will be deploying this to.

What is the Cloud Foundry?

The Cloud Foundry is a runtime environment available on SAP BTP for hosting Cloud Native applications. It is an open platform that has existed outside of SAP BTP for some time, and SAP has been a large contributor to the Cloud Foundry Foundation’s code base.

The environment itself has support for a wide variety of languages and frameworks, which it supports via an artefact called a buildpack. Buildpacks are used to compile your project within the runtime environment, and spin up a container within which your application is going to live in the Cloud Foundry.

As mentioned Cloud Foundry leverages containerized deployments for applications, and this deployment under the hood is powered by Kubernetes. However, you do not need to worry yourself with the intricacies of container management with the Cloud Foundry, these activities are handled implicitly by the runtime environment, so you just need to concern yourself with the development of your application, and the triggering of the deployment process once ready.

Cloud Foundry applications live in what’s called a Space, so in order for us to deploy our app, we want to ensure one is created within your Cloud Foundry environment instance within your subaccount.

Deployment and accessing from Subaccount.

To deploy our application, let’s return to our mta.yaml file, which as mentioned earlier will serve as our deployment descriptor.

Please see the sample mta.yaml file provided for my project deployment, the structure of yours should be similar after following the previous steps. The names of your services and such may be different depending on how you named your project :

_schema-version: “3.1”
ID: CockroachDB-Project
description: A simple CAP project.
version: 1.0.0
modules:
– name: CockroachDB-Project-srv
type: nodejs
path: gen/srv
requires:
– name: anthony-cockroachdb
– name: uaa_CockroachDB-Project
provides:
– name: srv-api
properties:
srv-url: ${default-url}
parameters:
buildpack: nodejs_buildpack
build-parameters:
builder: npm
– name: CockroachDB-Project-destination-content
type: com.sap.application.content
requires:
– name: CockroachDB-Project-destination-service
parameters:
content-target: true
– name: CockroachDB-Project_html_repo_host
parameters:
service-key:
name: CockroachDB-Project_html_repo_host-key
– name: uaa_CockroachDB-Project
parameters:
service-key:
name: uaa_CockroachDB-Project-key
parameters:
content:
instance:
destinations:
– Name: sales_orders_app_CockroachDB_Project_html_repo_host
ServiceInstanceName: CockroachDB-Project-html5-app-host-service
ServiceKeyName: CockroachDB-Project_html_repo_host-key
sap.cloud.service: sales-orders-app
– Authentication: OAuth2UserTokenExchange
Name: sales_orders_app_uaa_CockroachDB_Project
ServiceInstanceName: CockroachDB-Project-xsuaa-service
ServiceKeyName: uaa_CockroachDB-Project-key
sap.cloud.service: sales-orders-app
existing_destinations_policy: ignore
build-parameters:
no-source: true
– name: CockroachDB-Project-app-content
type: com.sap.application.content
path: .
requires:
– name: CockroachDB-Project_html_repo_host
parameters:
content-target: true
build-parameters:
build-result: resources
requires:
– artifacts:
– salesorderslist.zip
name: salesorderslist
target-path: resources/
– name: salesorderslist
type: html5
path: app/sales-orders-list
build-parameters:
build-result: dist
builder: custom
commands:
– npm install
– npm run build:cf
supported-platforms: []
resources:
– name: anthony-cockroachdb
type: org.cloudfoundry.user-provided-service
– name: CockroachDB-Project-destination-service
type: org.cloudfoundry.managed-service
parameters:
config:
HTML5Runtime_enabled: true
init_data:
instance:
destinations:
– Authentication: NoAuthentication
Name: ui5
ProxyType: Internet
Type: HTTP
URL: https://ui5.sap.com
– Authentication: NoAuthentication
HTML5.DynamicDestination: true
HTML5.ForwardAuthToken: true
Name: CockroachDB-Project-srv-api
ProxyType: Internet
Type: HTTP
URL: ~{srv-api/srv-url}
existing_destinations_policy: update
version: 1.0.0
service: destination
service-name: CockroachDB-Project-destination-service
service-plan: lite
requires:
– name: srv-api
– name: CockroachDB-Project_html_repo_host
type: org.cloudfoundry.managed-service
parameters:
service: html5-apps-repo
service-name: CockroachDB-Project-html5-app-host-service
service-plan: app-host
– name: uaa_CockroachDB-Project
type: org.cloudfoundry.managed-service
parameters:
path: ./xs-security.json
service: xsuaa
service-name: CockroachDB-Project-xsuaa-service
service-plan: application
parameters:
deploy_mode: html5-repo
enable-parallel-deployments: true
build-parameters:
before-all:
– builder: custom
commands:
– npx cds build –production

Notice the cockroachdb service which is labelled as user-provided, this is different from the other services we are leveraging within the resources section, as it’s one that we define ourselves within the Cloud Foundry. So let’s do that before we deploy.

Navigate to your SAP BTP Subaccount, and go to your Cloud Foundry Space. Click on the Instances tab, and click Create > User Provided Service.

Name the service whatever you like, you will reference this within your mta.yaml file, and in your logic file as we saw earlier.

For the parameters, provide one field for host, and the value of the host will be the connection string we saved way back in the beginning.

We have a couple of different ways to build and deploy this application, since we’re in SAP Build Code we have MBT (MTA Build Tools) which is used to compile this project, available out of the box.

We can compile the project either via the command line, or by right clicking the mta.yaml file, and selecting the build command.

To compile the project via the command line, ensure you’re in the directory with your mta.yaml file, and type mbt build.

Whichever way you choose to build your project, the outcome is the same. It compiles your project into an mtar file, mtar meaning MTA Archive. This is what we will actually deploy to Cloud Foundry. This file resides in a newly created folder for your mtar files.

Same as with building our project, we can deploy our project either by right clicking our newly created mtar file, or by using the Cloud Foundry command line interface. For either option, ensure you are first logged into the Cloud Foundry by performing a cf login command in the terminal.

For the first option, simply right click the file, and select the deploy option.

For using the command line, navigate into your mta_archives folder, and type cf deploy <mtar file name>.mtar. This will trigger the same process as if you right clicked the file.

Once we see the project has successfully deployed, let’s navigate back to our Cloud Foundry Space, and notice in the Applications section, we have our service layer deployed here.

Don’t get worried about your UI layer not being present. Recall we deployed using a Managed Approuter, which means that it doesn’t live here, but in the HTML5 Apps Repo.

NOTE : In order to view apps deployed with a Managed Approuter in the Subaccount, you need to have a subscription to SAP Build Work Zone, either Standard or Advanced Edition.

Click on the link for your application, and see your UI we had tested earlier locally, now publicly available on your BTP landscape.

Sometime ago I was involved with an SAP BTP workshop where a customer was interested as to how the SAP CAP (Cloud Application Programming Model) framework could be integrated with their already existing persistency storage solutions. For them, this was MongoDB, and years later, I have become interested again as to how the SAP CAP framework can be leveraged with a variety of frontend technologies and data layers.Enter CockroachDB, a nextgen-SQL database with which I have garnered quite an interest in. As such, I wish to accomplish a few things with this blog :Demonstrate the inherent flexibility of the SAP CAP framework, through it’s ability to leverage non-SAP data storage as it’s persistency layer, while keeping the application on track with SAP best practice recommendations for development on SAP BTP (open yet opinionated).Have this blog serve as a neat and tidy reference point for any of my colleagues who may at some point have such a requirement to create an application in SAP CAP with date persisted within CockroachDB.Inform those that are new to application development on SAP BTP as to what is SAP CAP, SAP Build Code, Cloud Foundry, Fiori, CDS, etc., as well as the uninitiated as to what is CockroachDB, and Sequelize. So, this will serve as a place for those who are new to application development on SAP BTP and the CAP Framework to get some guidance as to the moving parts involved, as well as for those who are experienced but are looking for perhaps some new use case for the framework. I’ve done some scouring and haven’t seen any materials on integration between SAP CAP and CockroachDB, so if my humble blog makes a splash, I hope it’s a good, and informative one for all.I will be making the assumption that those reading are at least familiar with what SAP BTP is, so I will not be doing a deep dive into that specifically. With that being said, I will break this up into the following table of contents :What is SAP CAP?What is CockroachDB?What is Sequelize?What is SAP Build Code?Creating our project and source code walkthrough.What is the Cloud Foundry?Deployment and accessing from SAP BTP Subaccount. Throughout the blog I will also provide links to any documentation, and videos which are relevant to the section if you are interested in learning more. With that being said, let’s get started. What is SAP CAP?The SAP Cloud Application Programming Model, often abbreviated to SAP CAP or SAP CAPM, is a development framework meant specifically for developing applications on the SAP Business Technology Platform, or SAP BTP.It is an open, yet opinionated model, meaning that it does provide a degree of freedom and flexibility in regards to a number of factors :UI Technology – SAP CAP apps can leverage any UI technology. The recommended is SAP Fiori or UI5, however front-ends can be developed in any framework (Angular, Vue, React, etc.).Persistency Layer – The point of this blog! While of course SAP CAP has out of the box capabilities to interact with and bind to SAP HANA Cloud, you can leverage your desired persistency layer (CockroachDB, MongoDB, Cassandra, etc.).Development Stack – Currently there are 2 supported development stacks for creating SAP CAP applications, Node.js, and Java Springboot.Development Environment – You can create SAP CAP applications in any IDE, you will just need to install the appropriate extensions (CDS, Cloud Foundry Command Line, MBT, etc.). The necessary extensions come built in on SAP Build Code, which is SAP BTP’s platform native IDE built on top of VS Code, and has embedded Gen AI capabilities via SAP joule. This will be the development environment we utilize in this blog.So you do have a variety of options for what with, and where you develop your applications. However, even with this flexibility, the framework ensures you are in alignment with SAP best practices when developing and deploying applications on SAP BTP.As mentioned, we have 2 development stacks we can leverage for developing our SAP CAP applications. In our blog we will be utilizing Node.js, this is used for our custom business logic in our application’s service layer.The server itself is defined, and started using what’s called Core Data Services, or CDS. Those coming from an on-premise SAP S/4HANA or SAP ECC development background are more likely than not acquainted with CDS. Similarly to how things are in these systems, in SAP CAP, CDS is used to define entities within our project. However, it is also used to construct queries to communicate with our persistency layer, and interact with our project (for example, start a local server for testing our application, add files and dependencies to our projects, etc.). CDS services defined in SAP CAP are exposed as OData Services, which is a protocol that can be leveraged to create RESTFUL APIs. To learn more about the CAP Framework, here’s the link to the official documentation :Home | capireFor our UI layer, as mentioned you can utilize a variety of front-end frameworks. However, for our project we will be utilizing SAP UI5, which can be utilized to create a unified user-experience across your developments within your SAP landscape. Within the context of development on SAP BTP, we have two flavorings of UI5 development :UI5 freestyle – traditional UI5 development, create the entire project from scratch and your developers own all the source code (views, controllers, etc.).Fiori elements – a selection of UI5 template applications which can be used out of the box. The underlying codebase is managed by SAP, however you do have access to elements of the UI5 application such as the deployment files, manifest, etc. Controllers and views can be modified via fragments.For our UI, we will be leveraging a Fiori elements template for a List Report application to view Sales Order data. To learn more about UI5, refer to the following link :Demo Kit – SAPUI5 SDK This data, of course, will be stored in CockroachDB. What is CockroachDB?CockroachDB is an open source, nextgen-distributed-SQL database. It’s somewhat less-than-charming name is in reference to one of its core qualities, resiliency. It is cloud hosted, and similar to SAP BTP, you can select what region/hyperscaler combination will host your cluster. Within this cluster your various databases will be hosted.Under the hood it leverages PostgreSQL wire protocol for communication with databases. Since it is open source as well, you can of course browse the source code in the github repository.Refer to the following links to learn more about CockroachDB, and also browse the github repo :Documentation : CockroachDB DocsGithub Repository : GitHub – cockroachdb/cockroach: CockroachDB — the cloud native, distributed SQL database designed fo… To create a cluster, navigate to CockroachDB’s website (CockroachDB | Distributed SQL for always-on customer experiences), and create an account by clicking, Get Started Free. Once your account is created you can create a cluster. When creating a cluster you will have to select a region/hyperscaler combination. You can provision your cluster either on AWS or GCP. Ideally, depending on the region/hyperscaler combination of your SAP BTP subaccount, you should locate your cluster close to that. For example my SAP BTP trial subaccount is hosted on AWS US East, so I selected that as the host for my cluster. It will take a bit for your cluster to create, but once created, you will be presented with credentials to access your cluster and databases. One of these is a connection string. Copy this and save it for later, you will be using this to communicate with the cluster, and the databases within it from your SAP CAP application. Looking at the databases within the cluster, defaultdb is where your tables and such will actually be stored. To persist an initial collection of data, you can utilize the SQL console to create an initial table, and insert some initial records. In our case, we want to create a Sales Orders table, and it will have the following fields :orderid: Integer Primary Keyprice: Integer (for sake of simplicity)productname: Varcharcountry: Varcharbuyer: Varchar With our table created, initial pool of records inserted, and connection string saved, let’s talk about how we will actually communicate with this database using Sequelize. What is Sequelize?Sequelize is a Object Relational Mapping, or ORM, which is available as a JavaScript package that you can download. An ORM is effectively a library which we can use to manifest tables which exist within our database, as objects within a given language or framework. So for example here, we will leverage Sequelize to define a JavaScript object which is a local representation of our Sales Order table. ORMs are nice since it allows your application developers to interact with the persistency layer as if they were interacting with an object within the language of the application, as opposed to having to write SQL queries within the app and send them to the backend. SAP CAP also has an ORM in this sense, it’s provided through CDS and is called CDS Query Language, or CQL. This, however, doesn’t seem to be supported for CockroachDB, so Sequelize will be our ORM.There are different Sequelize packages depending on the database your looking to leverage and communicate with, for example there are specific packages for Postgres, MySQL, and luckily for us, CockroachDB. There is also a library used to translate OData requests into Sequelizes own query language, this way we don’t need to manually construct the queries ourselves, it’s called “odata-sequelize.” This native Sequelize query notation is then translated into SQL in CockroachDB.Refer to the following links to learn more about Sequelize itself, and the packages we will be using in our project :Sequelize official site : Sequelize | Feature-rich ORM for modern TypeScript & JavaScriptSequelize package docs : sequelize – npmSequelize CockroachDB package docs : sequelize-cockroachdb – npmSequelize OData Parser package docs : odata-sequelize – npmNow that we understand our framework, our database, and our ORM which will be used to interact with that database, let’s talk about our IDE. What is SAP Build Code?SAP Build Code is SAP BTP’s platform native professional integrated development environment. All that meaning that it’s a browser based IDE hosted out of BTP that you can subscribe to from a subaccount. It is based on Visual Studio Code, so it’s look and feel should be very familiar to folks who have worked in that environment before. SAP Build Code comes with a variety of extensions which you otherwise would have to configure on every developers machine for developing applications and deploying them to SAP BTP. Some of these tools include :CDS CLI – A command line interface for interacting with your project via cds. This can be used to initialize a project, add files and dependencies to a project, and build your project.Link : CDS Command Line Interface (CLI) | capireCloud Foundry Command Line Interface – Command line tool for interacting with the Cloud Foundry Runtime Environment. We will go into detail about the runtime itself in a later section, but it will be needed for deploying our application to BTP to make it accessible to our end users.Link : Using the Cloud Foundry Command Line Interface (cf CLI) | Cloud Foundry DocsMTA Build Tools (MBT) – This will be used to compile our deployment configuration, a file called an MTA.yaml, into a format which is actually able to be understood by the Cloud Foundry environment. We will talk more about MTAs as we progress.Link : Cloud MTA Build Tool These, alongside other tools such as git, come out of the box with SAP Build Code, so all you need to do to get your developers started with everything they need is to onboard them to the environment in SAP BTP.SAP Build Code utilizes Dev Spaces as development environments. Under the hood these Dev Spaces are Kubernetes clusters with their own memory, which you will need to get running in order to access your development environment. For our purposes, and really all you need to concern yourself with, is that they are boxes which serve as isolated development environments within your SAP Build Code tenant.To learn more about SAP Build Code, and get some additional hands on practice with more tutorials, please take a look at its entry in the SAP Discovery Center : SAP Discovery Center Service – SAP Build Code. Each has its own file storage, as mentioned, as well as extensions intended to cater to a particular project type. For example, there are dev spaces for Full Stack Cloud Apps, Fiori Apps, and Mobile Apps. Full Stack Cloud Apps comes with CDS tools, as well as MBT for CAP development, Fiori Apps dev spaces come with extensions like the layout editor for drag and drop based development of UI5 front ends, and the Mobile dev spaces come with the Mobile Development Kit for creation of cross-platform applications. So for us to get started, you will need to create a new project, and assign it to a dev space. This can be done by navigating to your SAP Build Code subscription, and clicking create. If you don’t have a SAP Build Code subscription, refer to the documentation to run the booster to get it setup. The booster is the recommended approach, as opposed to trying to setup it up manually : Initial Setup | SAP Help Portal. Select application as your project type, then select SAP Build Code as your development environment. Select Full Stack Cloud Application, this will create an application in a Full Stack Cloud App dev space, when you create an SAP Build Code subscription, this dev space already exists for you. You can select the existing one, or create a new one. Enter the name of your project, the development stack is Node.js. Then click create, and click on the project to see the status of your dev space. Once it’s running you can click on the project name which will serve as a link to the dev space. Creating our project and source code walkthrough.In your dev space, when you create a new project in SAP Build Code, it will create a project structure for you. We’re going to create a project from the ground up. So, within the projects directory, create a new folder for our project called, CockroachDB-Project.Navigate to this newly created project, and type in the command cds init. See that this adds a number of things. Most importantly to us it adds :A package.json file for our dependenciesFolders for the following layers of our app :DB – Our database schemas will be defined here. For this particular project, we won’t be leveraging this directory.App – Where our UI layer(s) will be defined which will reference our OData Service defined in the srv folder.Srv – This is where our backend is defined. This is where we will define our OData Service, as well as our custom business logic for that service in the form of event handlers. Next, type cds add mta. This adds that mta.yaml file briefly mentioned earlier. MTA stands for Multi Target Application. It allows you to define what effectively boils down to a number of applications which share a lifecycle, so they are defined within a single deployable. These applications you are looking to deploy are defined within the modules, section.These modules have dependencies on resources, which are Cloud Foundry services which our application will consume to perform its necessary functions. For example, the destination service for communicating with our service layer. We will also create a user-defined service within our Cloud Foundry environment which will point to our CockroachDB cluster. Next, we will install some npm packages :Sequelize – will allow us to interface with the Sequelize ORM.Sequelize-cockroachdb – specific Sequelize library for working with CockroachDB.Odata-sequelize – will allow us to translate OData URL queries into Sequelize query syntax.@SAP/xssec – we will be making use of the SAP Authorization and Trust Management Service in our app, this package is necessary for the usage of that service.Cfenv – a package leveraged for communicating with the environment our application will be deployed to. We will need this to reference environment variables which contain the credentials needed for communicating with our CockroachDB. With this done, we can now start defining our service layer. To do this, we need to create 2 files in the srv folder, one we will call sales.cds, the other, sales.js. The names being the same is important, as the CAP Framework recognizes the JavaScript file as the business logic for the CDS layer of the same name. Within the sales.cds file, define the following OData service and entity :service sales_service{
entity sales_orders{
key orderid: Integer;
price: Integer;
productname: String;
country: String;
buyer: String;
};
};We define it effectively as a one-to-one mapping to the entity we have defined in our CockroachDB. While here we are listing all the fields, you can define only a select few fields here if you wish to only expose a handful of properties to your application. This effectively serves as an OData Select statement where we specify what fields we want to expose.Navigate to the sales.js file, and enter the following code. I have written in the comments what each function does, such that you can read through the source code and understand what everything is doing.//These below lines will import the necessary packages we installed to our logic file, so we can utilize them.
const cds = require(‘@sap/cds’);
const Sequelize = require(‘sequelize-cockroachdb’);
const odataParse = require(‘odata-sequelize’);
const cfenv = require(‘cfenv’);

module.exports = async srv =>{

//Event listener function for when we perform a READ request on our sales_orders entity in our
//OData service.
srv.on(‘READ’, ‘sales_orders’, async (req)=>{

return salesOrder;
});

});

//If no rows were modified in our update request, we log the error.
if(updatedOrder === 0){
console.error(“Error: Updated Failed!”);
}

});

return cockroachdb;
}

}

//Custom function for constructing the OData request URL.
function generateODataUrl(queryOptions){
let odataQuery = [];

//convert the array to a string, and replace all comma separation with &.
let finalOdataQuery = odataQuery.toString();
finalOdataQuery = finalOdataQuery.replaceAll(“,”,”&”);

//Convert the OData request string into Sequelize query syntax, and return it.
const sequelizeOdata = odataParse(finalOdataQuery, Sequelize);
return sequelizeOdata;
}

} You can test your various CRUD operations using a test.http, file in your project’s root directory. I have included a sample here. To send a request, click the, “send request,” link above the different HTTP operation sections. With this we are now ready to create our UI. Before we do this we want to add an Approuter module to our MTA deployment descriptor file. An Approuter is an artefact within our application which is responsible for routing requests from the UI layer of our application to our CAP OData Service, it serves as a client to the XSUAA service for authentication and authorization in our application, and it also tells SAP BTP where our UI application is going to live.There are 2 distinct versions of an Approuter, a Standalone and a Managed Approuter. All you need to concern yourself with for now, is that a Standalone Approuter deployment causes the UI to live within the Cloud Foundry environment, a Managed Approuter deployment has that UI layer live in the subaccount in something called the HTML5 apps repository. For our deployment, we will use a managed Approuter.To add the Approuter, right click your mta.yaml file, and select create mta module from template. Select Add Approuter Module, and enter the necessary details. This will add the Approuter configuration to your mta.yaml file for when we deploy this project. Now that we have our Approuter configured, we can go and create our UI layer using Fiori elements. To do this, click, view > command palette, and select, Fiori: Open Application Generator. This will present to you a number of application types, one of the types is UI5 freestyle, the remaining templates are Fiori Elements applications. Select, list report application. Our data source will be our local CAP project, and our OData service will be our Sales Orders OData service defined in our sales.cds, file. Our main entity will be our sales orders, leave the remaining values as the defaults. Enter a module name, recall modules are the applications deployed by the mta.yaml file, so give it a meaningful application name. The application title will be what users see within the UI of the app, so again give it a meaningful title. Select, Yes, to, Add deployment configuration to MTA project. The deployment target is the Cloud Foundry, and for the destination, select Local CAP Api. Once finished, if you expand the app folder, you will see that the wizard added the files for our UI layer upon completion for us. We’re not going to walk through the various files for the UI, instead we will now test our UI layer. To do so, again run, cds watch, and open up the local server. You will see now that there are links to webapps available, click the one for your UI layer. Now that we have our various layers defined, and our deployment configuration set. Let’s talk about where we will be deploying this to.What is the Cloud Foundry? The Cloud Foundry is a runtime environment available on SAP BTP for hosting Cloud Native applications. It is an open platform that has existed outside of SAP BTP for some time, and SAP has been a large contributor to the Cloud Foundry Foundation’s code base.The environment itself has support for a wide variety of languages and frameworks, which it supports via an artefact called a buildpack. Buildpacks are used to compile your project within the runtime environment, and spin up a container within which your application is going to live in the Cloud Foundry.As mentioned Cloud Foundry leverages containerized deployments for applications, and this deployment under the hood is powered by Kubernetes. However, you do not need to worry yourself with the intricacies of container management with the Cloud Foundry, these activities are handled implicitly by the runtime environment, so you just need to concern yourself with the development of your application, and the triggering of the deployment process once ready.Cloud Foundry applications live in what’s called a Space, so in order for us to deploy our app, we want to ensure one is created within your Cloud Foundry environment instance within your subaccount.Deployment and accessing from Subaccount.To deploy our application, let’s return to our mta.yaml file, which as mentioned earlier will serve as our deployment descriptor.Please see the sample mta.yaml file provided for my project deployment, the structure of yours should be similar after following the previous steps. The names of your services and such may be different depending on how you named your project :_schema-version: “3.1”
ID: CockroachDB-Project
description: A simple CAP project.
version: 1.0.0
modules:
– name: CockroachDB-Project-srv
type: nodejs
path: gen/srv
requires:
– name: anthony-cockroachdb
– name: uaa_CockroachDB-Project
provides:
– name: srv-api
properties:
srv-url: ${default-url}
parameters:
buildpack: nodejs_buildpack
build-parameters:
builder: npm
– name: CockroachDB-Project-destination-content
type: com.sap.application.content
requires:
– name: CockroachDB-Project-destination-service
parameters:
content-target: true
– name: CockroachDB-Project_html_repo_host
parameters:
service-key:
name: CockroachDB-Project_html_repo_host-key
– name: uaa_CockroachDB-Project
parameters:
service-key:
name: uaa_CockroachDB-Project-key
parameters:
content:
instance:
destinations:
– Name: sales_orders_app_CockroachDB_Project_html_repo_host
ServiceInstanceName: CockroachDB-Project-html5-app-host-service
ServiceKeyName: CockroachDB-Project_html_repo_host-key
sap.cloud.service: sales-orders-app
– Authentication: OAuth2UserTokenExchange
Name: sales_orders_app_uaa_CockroachDB_Project
ServiceInstanceName: CockroachDB-Project-xsuaa-service
ServiceKeyName: uaa_CockroachDB-Project-key
sap.cloud.service: sales-orders-app
existing_destinations_policy: ignore
build-parameters:
no-source: true
– name: CockroachDB-Project-app-content
type: com.sap.application.content
path: .
requires:
– name: CockroachDB-Project_html_repo_host
parameters:
content-target: true
build-parameters:
build-result: resources
requires:
– artifacts:
– salesorderslist.zip
name: salesorderslist
target-path: resources/
– name: salesorderslist
type: html5
path: app/sales-orders-list
build-parameters:
build-result: dist
builder: custom
commands:
– npm install
– npm run build:cf
supported-platforms: []
resources:
– name: anthony-cockroachdb
type: org.cloudfoundry.user-provided-service
– name: CockroachDB-Project-destination-service
type: org.cloudfoundry.managed-service
parameters:
config:
HTML5Runtime_enabled: true
init_data:
instance:
destinations:
– Authentication: NoAuthentication
Name: ui5
ProxyType: Internet
Type: HTTP
URL: https://ui5.sap.com
– Authentication: NoAuthentication
HTML5.DynamicDestination: true
HTML5.ForwardAuthToken: true
Name: CockroachDB-Project-srv-api
ProxyType: Internet
Type: HTTP
URL: ~{srv-api/srv-url}
existing_destinations_policy: update
version: 1.0.0
service: destination
service-name: CockroachDB-Project-destination-service
service-plan: lite
requires:
– name: srv-api
– name: CockroachDB-Project_html_repo_host
type: org.cloudfoundry.managed-service
parameters:
service: html5-apps-repo
service-name: CockroachDB-Project-html5-app-host-service
service-plan: app-host
– name: uaa_CockroachDB-Project
type: org.cloudfoundry.managed-service
parameters:
path: ./xs-security.json
service: xsuaa
service-name: CockroachDB-Project-xsuaa-service
service-plan: application
parameters:
deploy_mode: html5-repo
enable-parallel-deployments: true
build-parameters:
before-all:
– builder: custom
commands:
– npx cds build –productionNotice the cockroachdb service which is labelled as user-provided, this is different from the other services we are leveraging within the resources section, as it’s one that we define ourselves within the Cloud Foundry. So let’s do that before we deploy.Navigate to your SAP BTP Subaccount, and go to your Cloud Foundry Space. Click on the Instances tab, and click Create > User Provided Service. Name the service whatever you like, you will reference this within your mta.yaml file, and in your logic file as we saw earlier.For the parameters, provide one field for host, and the value of the host will be the connection string we saved way back in the beginning. We have a couple of different ways to build and deploy this application, since we’re in SAP Build Code we have MBT (MTA Build Tools) which is used to compile this project, available out of the box.We can compile the project either via the command line, or by right clicking the mta.yaml file, and selecting the build command. To compile the project via the command line, ensure you’re in the directory with your mta.yaml file, and type mbt build. Whichever way you choose to build your project, the outcome is the same. It compiles your project into an mtar file, mtar meaning MTA Archive. This is what we will actually deploy to Cloud Foundry. This file resides in a newly created folder for your mtar files. Same as with building our project, we can deploy our project either by right clicking our newly created mtar file, or by using the Cloud Foundry command line interface. For either option, ensure you are first logged into the Cloud Foundry by performing a cf login command in the terminal. For the first option, simply right click the file, and select the deploy option. For using the command line, navigate into your mta_archives folder, and type cf deploy <mtar file name>.mtar. This will trigger the same process as if you right clicked the file. Once we see the project has successfully deployed, let’s navigate back to our Cloud Foundry Space, and notice in the Applications section, we have our service layer deployed here. Don’t get worried about your UI layer not being present. Recall we deployed using a Managed Approuter, which means that it doesn’t live here, but in the HTML5 Apps Repo. NOTE : In order to view apps deployed with a Managed Approuter in the Subaccount, you need to have a subscription to SAP Build Work Zone, either Standard or Advanced Edition.Click on the link for your application, and see your UI we had tested earlier locally, now publicly available on your BTP landscape. Read More Technology Blogs by SAP articles