Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
The principal thought behind the evolution of micro services is that few of the applications become easier to build and maintain if it broke down in to smaller units which work together and later communicate among themselves via APIs. This is in contrast to a traditional monolithic application which is developed in a single unit.

SAP is not (that) far away in the field of micro services, as SAP used different languages such as ABAP, SAP UI5/Fiori, CDS View and OData for CRUD operation, and these all have their own limitation such as source independent development, platform independent development etc. To remove such dependency and assemble SAP and open source tool in single umbrella, SAP introduced Cloud Application Programming model also known as SAP CAP is a frameworks of tools, languages and libraries (both open source and SAP tools and technologies) designed efficiently with SAP best practices to help developers to minimize coding efforts, develop reusable peace of codes in form of micro services and to focus on designing and implementing business/enterprise specific logic.


Why CAP?

SAP Cloud application programming Model is predominantly built in leveraging Node JS, also we create and develop application in Node environment. This framework is best suited for the development of applications for the enterprise having Cloud Infrastructure. Since this Application framework can consume both Hana Database as well on premise based OData exposed database, thus it is suitable for all types of enterprises.

Technical Overview

Use case:

 SAP Cloud application programming Model follow 2 main principles:

1. Declarative Approach – Focus more on the functional side for e.g. What will be the table structure? What will be the service? What will show in UI?

>Entities ()



2. Service Based Approach – Break down the functionality in to services and get the                               functionality in UI Layer.

>Service (…………)

This service exposed as OData service, it’s stateless.

          >UI Annotation (……….)


            >Service Query






 How to consume this CAPM micro service?

There are 2 ways to approach this :

Approach 1 –>Clubbing Fiori Project and CAPM Project in single SAP BAS Workspace.

The main disadvantages of this approach –

  1. It’s very difficult to maintain and its high risk to provide entire code (UI and Services) access to developer.

  2. Fiori developer who don’t have any knowledge of CAPM, will not be able to work on this.




Approach 2 –> Build Independent Fiori App which will consume this OData service.

It’s best suitable approach and strategic advantage of these are:

  1. Single access point to services which are exposed by CAPM and build these Fiori apps outside the CAPM project.

  2. Build Fiori applications like Free style and Fiori elements etc. and manage it outside CAPM.

  3. UI development don’t need to worry about backend logic, they only to need consume this services.

  4. Only need to deploy Fiori UI portion not a full archive.


   Result –




In Future Road Map SAP CAP Microservices will be well suited for Enterprise scenario and it can be easily consumed by any UI application via OData services.


For more information please visit
Labels in this area