Technical Articles
RAP vs CAP – Key Differences between the Two Programming Models
Introduced in January 2021, SAP Business Technology Platform (SAP BTP) is a unique and powerful solution offering by SAP. It is the technical foundation of entire SAP ecosystem and plays a crucial role for all SAP customers and partners.
SAP BTP offers 2 major programming models to build enterprise applications:
- ABAP RESTful Application Programming Model (RAP)
- SAP Cloud Application Programming Model (CAP)
Both these programming models comes with amazing tools, frameworks, languages and best practices. However, both cater for different developers and use-cases.
In this blog, we will understand:
- What is ABAP RESTful Application Programming Model (RAP)?
- What is SAP Cloud Application Programming Model (CAP)
- What are the differences between RAP and CAP?
- How to choose which programming model to use?
Note: Before understanding these programming models, you should have a clear idea about what SAP BTP is and different environments SAP BTP offers. I will strongly recommend reading below blogs before you read this further.
Explaining SAP Business Technology Platform (SAP BTP) to a Beginner
SAP BTP Environments – Cloud Foundry Vs ABAP Vs Kyma
Let’s start!
What is ABAP RESTful Application Programming Model (RAP)?
The ABAP RESTful Application Programming Model (RAP) is:
- an ABAP development model
- for building cloud-ready business apps, services, and extensions
- on SAP BTP, ABAP environment, SAP S/4HANA Cloud, and SAP S/4HANA 1909 and higher
RAP consists of
- a set of concepts, tools, languages, and powerful frameworks
- which help us to
- build innovative, cloud-ready, enterprise applications and Web APIs
- and to easily extend SAP standard applications on the ABAP platform
RAP offers a standardized development flow based on Core Data Services (CDS), modernized and extended ABAP language, concept of business object (BO), Business Service etc., and Eclipse-based ABAP Development Tools (ADT).
Below image summarizes all the points:
Example use-case for RAP
SAP recommends customers and partners to use RAP to build new ABAP based applications for SAP S/4HANA, SAP S/4HANA Cloud and SAP BTP.
RAP can be used to:
- Build full-fledged and upgrade-stable extensions on SAP S/4HANA or SAP S/4HANA Cloud
- Build ABAP based cloud solution on SAP BTP, ABAP environment
Different types of services, local APIs, and business events can be developed and modelled with RAP, for example:
- OData-based services for UI development to build delightful, role-based, responsive, and draft-enabled SAP Fiori apps.
- OData-based services for exposure as Web APIs
- Local APIs can be provided via released RAP business objects interfaces
What is SAP Cloud Application Programming Model (CAP)?
SAP Cloud Application Programming Model is:
- a set of tools, frameworks, languages, and libraries
- which provide a golden path for developers
- by bringing together SAP technologies like SAP HANA Cloud, Core Data Services, SAP Business Application Studio, SAP Fiori, and open-source languages/technologies like Java, Node.js or SQLite.
SAP CAP empowers developers to minimize the overall development effort by helping them to focus on their business logic and relieving them from tedious repetitive tasks which are common across application e.g., user and security management.
As shown in image below, SAP Cloud Application Programming Model includes a mix of SAP and open-source technologies.
What are the differences between RAP and CAP?
Aspect |
RAP |
CAP |
| Language | Supports ABAP | Supports Java or Node.js |
| Supported Environment/System | Available with SAP BTP ABAP Environment, SAP S/4HANA and SAP S/4HANA Cloud | Available with SAP BTP Cloud Foundry and Kyma Environment |
| Strengths | Use of ABAP, Possibility to reuse code from SAP system | Open source, Support for multiple programming languages and runtimes, Minimize development effort |
| Development Environment | We can develop RAP based application using Eclipse-based ABAP Development Tools (ADT) | We can develop CAP based application using SAP Business Application Studio. It also supports local development using Visual Studio Code. |
| Example use-case |
Build full-fledged and upgrade-stable extensions on SAP S/4HANA or SAP S/4HANA Cloud
Build ABAP based cloud solution on SAP BTP, ABAP environment |
Build a web application, which connects to an SAP HANA Cloud to retrieve and display real-time sales data. |
I hope by now, you will have a clear understanding of RAP and CAP.
If you have any feedback or query, please let me know in the comment or get in touch with me at LinkedIn!
For more information on RAP, click here.
For more information on CAP, click here.
What’s Next?
Check this blog to get a comprehensive learning path for SAP BTP, customized for various job profiles such as Developer, Architect, Consultant and Administrator.
Learning Path for SAP BTP – Customized for Developer, Architect, Consultant and Administrator
Other blogs on SAP BTP from me, you might be interested:
- A Beginner’s Guide to Understand Major Solutions, Services and Platforms in SAP Ecosystem
- Fundamentals of Multitenancy in SAP BTP
- Fundamentals of Security in SAP BTP
- How to Become Expert in SAP BTP Security– A Complete Learning Journey
- Demystifying SAP Build for Beginners
- Deep Dive into SAP Build Work Zone
- Demystifying DevOps with SAP BTP: Part 1 – What is DevOps?
- Demystifying DevOps with SAP BTP: Part 2 – Navigating SAP BTP DevOps Portfolio
And how do I now choose which model to go for? The last promised topic from the beginning seems to be missing somehow here ...?
I don't understand the RAP Strength "Use of ABAP, Possibility to reuse code from SAP system"
"Use of ABAP": I mean... yeah it's ABAP syntax. But I wouldn't say it is ABAP, a common ABAPer can't use RAP without a stepping learning curve.
"Possibility to reuse code from SAP system": I mean you could also leverage the use of existing code with APIs using CAP and you can't reuse hardly any existing ABAP code to use RAP.
Honestly I don't know why SAP even thought on RAP, I mean why myself as a company would ever choose RAP over CAP what is the big advantage ?
IMO SAP was mistaken on going the RAP route as it was wrong with Web Dynpro decades ago. If they really wanted to leverage the use of ABAP why don't create a standard and robust tools like abap2UI5
Or perhaps promote more the use of SAP Screen Persona. If RAP and Fiori is the way to go why SAP Screen Persona even exists and still being updated ?
S/4HANA standard code is increasingly RAP based. WebGUI Fiori tiles from older S/4HANA versions are being re-written as RAP/Fiori Elements apps at quite a pace. This sort of thing didn't happen with previous UI technologies - SAP would write completely new functionality in the framework du jour, but rarely update any existing functionality to use it. This to me is the main argument against the view that RAP is just like WebDynpro and will be replaced in a couple of releases time.
The other main use for RAP is within the S/4HANA Cloud ABAP Environment (I think that's what they're calling it this week), where the (developer) extensibility options will be entirely RAP-based. Why create a new CAP (or other HTML5) application on BTP that replicates 90% of a standard S/4HANA app, when you can just tweak the original in an upgrade-safe way.
I don't think RAP is a steep learning curve for ABAPers, unless they've had their heads in the sand for the last decade. I did a lot of learning around the older UI technologies (like BSP, WebDynpro ABAP and the ABAP Programming Model for Fiori) when they originally came out, but forgot most of it as the frameworks were not widely used in the core ERP offering of the time. RAP, however, I encounter on a daily basis in our S/4HANA system.
RAP is here to stay and is now extensively used in the standard product, so all ABAPers should be taking it very seriously.
We are in 2023, only 2 year before the first announcement when ECC was supposed to end, now extended to 2030. There are infinite number of company that still uses SAP GUI simply because Fiori is not a good product, is true that people doesn't like change but it's also true that SAP Fiori Launchpad is pretty awful.
In SAP Fiori Library there is a 75% of apps that are really SAP GUI, Web Client UI or WebDrypro "Fiori Apps", I would think that by now after that many years that number would be way lower.
You say RAP is here to stay... perhaps you are right. At one point if you needed to create a new aplication it was supposed to be done in WebDrynpro, how that went?
RAP is easy is you stick with the silly 5 minutes examples, but when you need to do more complex stuff, which is usually what the business want then you need to become a RAP ninja.
One thing is what SAP want and plans and other is where the companies goes, until ECC support is up I don't see them going away from SAP GUI, by then I'm pretty sure SAP will release a new tools with a different name. The last two big company were I worked at both had SAP Fiori Launchpad but they hardly use it.
None... Zero...my experience with RAP is only tutorial and self-learning. And the few Fiori is using SEGW, only one app was developed using the BOPF+ model because the "draft" feature was needed.
You are right you can not realise anything. CDS is not ABAP . You can call some ABAP artifacts second the limited scope of reusing some code in brownfield scenarios does not helps because here you are handicapped by the forced dogma that everything has to be a CDS
For a CAP use-case its mentioned to
The "web application" would be custom development, i.e. not a SAP product, so as per the CAP license it does not
ref https://tools.hana.ondemand.com/developer-license-3.1.txt
so it looks like the suggestion violates the SAP license terms for CAP?
Suggest changing the use-case to
then the use-case would not trigger any questions regarding license terms
When it comes down to which model you should/want to use please consider this great (imho) article by Tobias Hoffman:
https://www.itsfullofstars.de/2023/07/cap-the-new-web-dynpro-java/
And his follow up post: https://www.itsfullofstars.de/2023/08/additional-comments-on-cap/
For several reasons he takes a rather sceptical view on CAP.
RAP model is simply inefficient, does not caters to most coding needs. CDS as source for everything is a flawed concept. They could have kept ODATA, BOPF and then helped UI5 development with fast development using annotations but current model where CDS is the source for everything is very flawed, inefficient and if I have to pick I will avoid this model.
Hi, see my reply below.
Best regards
Reverted back with my comments. It still does not makes sense RAP is a dead duck. In 10 years it will go the WD Java way or it will look something different. It's a incomplete model that can not complete real world client demands.
Well SAP Moderators deleted the previous comment it was sensitive for them so, again I am writing my 2 cents and hope just criticising does not makes it sensitive and they delete it again.
The whole annotation based technology is very backward and does not looks like a professional offering from a professional enterprise software company. The simple model of separate ODATA and Fiori development based on the BOPF model was really better than the RAP model.
Even RAP has so much of limitations, I do not really see a compelling reason why one would invest here and not go the simple route and these RAP model technically offers nothing that would have been impossible with ODATA, BOPF, based ABAP to develop cloud native applications.
I have used CDS annotations in analytics as well and I appreciate it and they could have used it for generating Fiori the way they did but the concept of CDS as the cornerstone for everything and then piling it up with tons of annotations is what I find ugly, inefficient and something that will not last forever. How could one advocate and be proud of this model when they already had a model that was robust?
Prasenjit
Hello Prasenjit,
Thank you for your feedback.
Technologies such as Web Dynpro, BOPF, SEGW, and the ABAP Programming Model for SAP Fiori are still supported on SAP S/4HANA on-premises and in the private cloud, and can continue to be used on these editions.
The ABAP RESTful Application Programming Model (RAP) is an evolution of the BOPF-based ABAP Programming Model for SAP Fiori. In RAP, the BOPF principles for manipulating a business object (BO) using determinations, actions, and validations are natively integrated into the ABAP language, eliminating the need for a separate framework for the transactional processing of RAP BOs. Greenfield and brownfield implementations, draft handling, business events, and more are supported with RAP. For an overview of RAP capabilities, see the RAP Development Guide.
ABAP Core Data Services (CDS) provides the ability to define semantically rich data models with a high level of expressiveness using built-in expressions, functions, and aggregations on the ABAP platform. Annotations can be used to specify semantics of different application domains, e.g. analytics.
UI annotations can be specified in the backend for the scenarios where it makes sense, but this is not mandatory. For a separation of concerns (backend/frontend), the UI semantics can be defined in the SAP Fiori tools using the Annotation Modeler.
Best regards
You said that it is an evolution well can I use your BO the new BOPF evolution in traditional ABAP development if I want to use like the old BOPF based Fiori model? CAn I generate a RAP program with the model that I am talking about and why would I upload annotations on the annotation modeller because ultimately the things are still tied with the same CDS as the penicillin for everything approach!
What happened to the WYSIWYG Fiori model we were using a few years back in 2016 using back end ODATA services?
"ABAP Core Data Services (CDS) provides the ability to define semantically rich data models with a high level of expressiveness using built-in expressions, functions, and aggregations on the ABAP platform. Annotations can be used to specify semantics of different application domains, e.g. analytics."
I have used it in Analytics and that is only place where I appreciate it else it is a headache. I am commenting here or sharing my thoughts specific to the RAP that you call the next great evolution.
What about the consistency of the CDS model for decades you pushed CDS model with SE11 views and now you have CDS w/o that and your so called next gen innovations come only for the new CDS model model. So there is no new innovation for BOPF, WD, SEGW- isn't that funny that you still call them supported?
Regarding your feedback on the "consistency of the CDS data model".
ABAP CDS was introduced with AS ABAP 7.4 SP 05, and its feature set has expanded tremendously over the past decade to best support the development of SAP HANA-optimized applications for different domains, in the cloud and on-premises.
ABAP CDS data models have remained consistent over that past decade. CDS view entities are just the new generation of CDS views and the successor to CDS DDIC-based views.
In general, CDS view entities work similarly, but they offer simplified definition, consumption, and lifecycle management:
More information can be found here: A new generation of CDS views: CDS view entities.
If required, tool-based support is provided for easy migration of CDS DDIC-based views to CDS view entities. See blog post How to migrate your CDS views to CDS view entities
For more information, see the section "CDS view Entities" of this blog post and the ABAP Keyword documentation.
Best regards
My POV on this may sound controversial but I think it's the least confusing one: these programming models are rather different tools for different jobs, like hammer and screwdriver.
There are so many differences that it's easier to mention what they have in common: both have something to do with SAP. That's about it. 🙂