The SAP Cloud Application Programming Model (CAP) is a framework of languages, libraries, and tools for building enterprise-grade services and applications.
In this post, we’ll list and describe the various capabilities of the SAP Cloud Application Programming Model framework.
Capabilities of the SAP Cloud Application Programming Model
CAP provides the following capabilities.
Object-Relational Mapping (ORM)-Like Capabilities
ORM libraries are specialized libraries that simplify application code’s database interactions. They map real-world objects with relational database artifacts. Their main goal is to free the developers from writing complex database-specific SQL queries by providing an easy and generic way to do the following:
- Define database schema and artifacts.
- Query and update database records, including transaction handling (Query Builder).
- Sequelize: This is the most popular ORM for Node.js.
- Bookshelf: This uses the Knex.js Query Builder.
- Waterline: This ORM is the default when you use the Node.js framework Sails.js.
- js: This is built on top of the Knex.js Query Builder.
CAP provides the advantages of an ORM for the SAP HANA database. It provides an easy way to model both your database schema and service interface. The CDS Definition Language (CDL) is a set of human-readable commands in a universal modeling language that helps you model database schemas and OData schemas as well.
For querying, creating, updating, and deleting database records, (Query Builder functionality) CAP provides CDS Query Language (CQL) and Query Builder APIs. Like most other ORMs, CAP aims to support multiple databases, though it officially supports only SAP HANA databases for now.
As you consider the advantages of CAP using the ORM analogy, it’s important to understand that CAP doesn’t call itself an ORM, as it uses CQL for querying, CQL outputs are REST-like, and it doesn’t use the object cache.
Tip: There is an open-source, community effort to bring CAP support to the open-source database PostgreSQL. For more details, you can refer to Node.js modules cds-pg and cds-dbm.
Create and Consume OData Services
CAP lets you define OData entities and expose an OData service. Internally, CAP uses the express framework to build an OData server. As part of your extension use case, you may want to connect to SAP and non-SAP OData services to build mash-up scenarios. CAP provides tools to easily consume such services and test them locally too.
Event-driven architecture is very popular in the modern microservice-based landscape. Because CAP provides support for emitting and consuming events, it also supports asynchronous communication. Using the SAP Event Mesh service in SAP BTP, you can easily subscribe to events of SAP S/4HANA and perform corresponding downstream processes.
Authentication and Authorization
Authentication and authorization are basic requirements of any enterprise application. CAP integrates with SAP BTP’s authentication and authorization services to enable these features. CAP provides several authentication strategies, including basic authentication and JSON Web Token (JWT)-based authentication strategies. It also provides a dummy authentication strategy to disable all authentication and authorization checks during local application testing.
CAP provides annotation-based capabilities for authorization. You can restrict the capabilities of services, as well as specific roles needed for performing a specific action within an OData service.
Extend SaaS Applications
SaaS applications are becoming very common in enterprise landscapes. CAP provides a tool to extend such SaaS applications at the tenant level (subscriber level) so that customers can extend, deploy, and consume subscriber-specific extensions.
In addition to already explained capabilities, CAP provides several capabilities:
- Deploy projects to SAP BTP and SAP HANA XSA
- Use language-specific texts (i18n) in domain modeling
- Handle various media files
- Manage data privacy by identifying private data and integrating with the SAP Personal Data Manager service in SAP BTP
To better understand CAP, let’s consider how to get started in building an application for the real-world. Here are our requirements and the solution for clarity:
A purchaser in the procurement division of a company issues several purchase orders for fulfilling the requirements of his manufacturing department. Each of these purchase orders has a delivery schedule that is driven by the needs of the manufacturing process. However, suppliers don’t always stick to the delivery schedule, which causes delays in manufacturing.
Currently, whenever there is a likely schedule miss, the purchaser escalates by communicating with suppliers over several emails and following up on the delivery schedule. The purchaser needs to keep his superiors informed about the communications.
The following pain points may occur during this process:
- At any moment, it’s very cumbersome to list all the escalations that are currently under pursuit.
- It’s tedious to collect all the comments from various people on the purchase order.
- Management has no visibility regarding the status of various escalations at any time.
Create an SAP Fiori app, where the purchaser can choose a purchase order and create an escalation against it. Escalation will be a new business object, and comments by various involved parties can be stored against it. The ability to assign statuses to each escalation can let stakeholders know the current status of the escalation. The SAP Fiori app should also list all the current escalations with the ability to search and filter based on various aspects of the escalation object.
One easy solution would be to completely build the application in the backend SAP S/4HANA system. However, in that case, we’re not keeping the “core clean” and would complicate the future move to an SAP S/4HANA Cloud system. So, we want to build this solution as a side-by-side extension while trying to minimize the footprint on the on-premise system.
Our preferred solution to build a side-by-side extension is to use SAP BTP along with its SAP Extension Suite offering. The figure below shows this architecture. The SAP S/4HANA on-premise system would expose many APIs for external systems to consume. One of them is a purchase order API that can list purchase orders. Next, on the SAP BTP layer, you would build a backend application that would expose an OData service for the SAPUI5 application to consume. This backend application would also consume the Purchase Order OData API from the SAP S/4HANA system and expose purchase orders via an entity set. Whenever a supplier updates the shipping information against a purchase order, the SAPUI5 app would send that to the OData API, and the backend code would capture the information and store it in an SAP HANA database via the SAP HANA Cloud service.
In this scenario, the following tasks need to be performed by the backend application developer:
- Expose the OData service for the SAPUI5 app to consume.
- Consume the OData service from external systems (SAP S/4HANA, in this case).
- Ensure that users need to be authenticated before accessing the preceding OData service.
- Ensure that the app checks the user authorization for performing the read or update.
- Create a data model (schema, tables, views) in the SAP HANA Cloud service.
- Create APIs for storing and retrieving data from the SAP HANA Cloud service in SAP BTP.
- Log errors and messages for troubleshooting.
Editor’s note: This post has been adapted from a section of the book SAP Extension Suite Certification Guide: Development Associate Exam by Krishna Kishor Kammaje and Mahesh Kumar Palavalli.