Personal Insights
Comparing ABAP Restful Application Programming (RAP) model with the Cloud Application Programming (CAP) model
Our lessons learned developing an Enterprise-Ready application with CAP and Fiori Tools in the Business Application Studio
By Robert Eijpe, Sr. Enterprise Architect for SAP at NL for Business
September 23, 2020
Nowadays, SAP delivers a lot of possibilities to build a future proof SAP application. SAP bets for its development on two new programming models: at the ABAP Restful Application Programming (RAP) model and at the Cloud Application Programming (CAP) model. Both models are promising, and we think they both have their strengths and weaknesses. How can we find these strengths and weaknesses better than implementing a real application? So, we did, and we share our experience and lessons learned with you in our blog series under the umbrella: Our lessons learned developing an Enterprise-Ready application with CAP and Fiori Tools in the Business Application Studio.
This first blog compares the RAP and CAP model and explains why we choose to rebuild our Microsoft Time Sheet for consultancy application with CAP and Fiori Tools in the Business Application Studio.
The UI layer of CAP and RAP
When we looked at RAP and CAP, we saw that both programming models deliver an API layer without a productive UI layer. The currently supported API flavors are pure REST-based JSON services or OData Services versions 2 (standard RAP) and version 4 (standard CAP). Both models have the option to deliver OData Annotated services. A Fiori Elements player can generate a Fiori Application from these OData annotations, which can be used by the developer to check developments and as a starting point for your UI. Still, productive UI applications should be developed independently. Both models can use any UI technology, including Fiori Elements, SAPUI5, OpenUI5, Fiori for iOS, Fiori for Android, React, Angular, VUE, and HTML5 web components. All the mentioned UI technologies have their strengths, and it is up to your organization to choose the one which fits the best.We decided to build our application using Fiori Elements with UI5 custom extensions close to SAP technology. As part of the SAP Cloud Portal and in a Fiori Cloud Launchpad, we need to run the application standalone. We selected the SAP Cloud Platform multi-cloud environment as our Cloud Platform, and we want to profit from SAP key-integration points using the SAP Cloud SDK. We didn’t choose Fiori for iOS and Fiori for Android because both UI technologies will restrict our applications to specific native device types. With React, Angular, and VUE, we miss some needed Business UI Controls and out-of-the-box integration with the service layer. A decision for one of those three will cost us a lot of additional effort for Look and Feel and to connect the UI layer to the service layer. We want to spend this effort in building the application.
Supported Databases of CAP and RAP
Now we decided on the UI technology; we next needed to decide about the programming model. As mentioned, they both have their strengths and weaknesses and are relatively new but built on proven technologies. RAP uses SAP Netweaver ABAP stack, also known as Steampunk, as the underlying runtime. And CAP runs on top of Node.js or Java server. Both models are optimized for an SAP HANA DB as their database layer, and for RAP, this is the only supported database. CAP also runs on SQLite during development, and there is a community contribution for PostgreSQL.
Strength of RAP
RAP is the preferred model for ’ABAP in the Cloud’ and S/4HANA environments. RAP’s strength is its ABAP CDS layer, which is much major than the CAP CDS layer. The ABAP programming language will use, when possible, the native database capabilities behind the scenes and run the data handling on database level. With the so-called code pushdown at runtime, we will get the maximum power out of the database, without losing the strengths of the ABAP language. With the custom entities concept, RAP handles external API as CDS content. The planned development for providing the RAP services as RFC function modules, next to OData and Rest, makes backward compatible integration with traditional SAP Business Suite applications like ECC possible without complexity.Other key features of RAP are their data dictionary for data artifacts, their transport layer, and, in the case of RAP on S/4HANA (Cloud and On-Premise), their direct access to SAP S/4HANA Business Content. Together, RAP will provide a robust environment to build an application that handles big data sets, needs analytic and transactional capabilities, and the power of the underlying database.
RAP’s downside is the overkill of resources needed to run the environment and results in a high price tag for most applications. And a lack of available ABAP functionality due to restrictions is, in our opinion, a weakness at this moment. SAP re-evaluates the complete ABAP environment, including statements, data dictionary content, core data services, function modules (including BAPI, RFC, ALE, and IDOC), classes, and tools. Commonly used ABAP features are already obsolete in RAP. Workflow, reports, transactions, BSP, and (web)Dynpros and not available anymore. Only released content, released API’s and validated tools are available for the developer, the eclipse-based development environment ADT must be used. Also, the ABAP toolset and statements for handling cloud services and external APIs are not mature. It is very time-consuming to configure the system to call external services and make their services available. But these current weaknesses will be a strength in a short time from now. A clean ABAP environment will promote the ABAP stack to a modern and future proof environment without the past ballast. And SAP can make steps fast because the ABAP assets are already there, and they only have to pass the evaluation process.
Strength of CAP
When we compare CAP with RAP, we see that CAP is the opposite of RAP in most cases. The programming language of RAP is the proprietary SAP language ABAP and runs on a proprietary NetWeaver ABAP stack called Steampunk. CAP applications are written in the open-source languages like Java and Javascript/TypeScript and run on open-source runtimes like JVM or Node.js. The decision to use open source languages and runtimes for CAP brings the environment a lot of advantages. Besides the strength of the language, package managers like NPM for Node.js and POM for JAVA will speed up developments, improves the quality of code by best-practices, and removes restrictions for accessing the functionality of other systems. You can add almost any function using code library from vendors and the open-source community to your project, and this is why these languages and runtimes are so popular on Cloud Platforms. That brought us to a crucial question; Which values add CAP to existing Java and Node.js frameworks? Why should we run our application on SAP Cloud Platform instead of using the Node.js or Java runtimes of the hyperscalers like Google, Amazon, and Microsoft?But CAP adds an essential feature. Like ABAP did in the past by providing a unified SQL layer with Open SQL on top of the different databases, CAP brings a uniform SQL layer on top open-source languages and cloud-based data sources. So not only data from databases but any data sources, including these from libraries functions and external APIs, can be handled in the same way. In our perspective, CAP becomes, in some ways, the successor of RAP. We believe this even more after Thomas Jung mentioned in the CAP introduction video of the Devtoberfest 2020 that CAP would get all the best practice concepts we known from the ABAP world.
And CAP will bring even more value when using its SAP Cloud SDK capabilities and run it on the SAP Cloud Platform. With the SAP Cloud SDK, most APIs of SAP business solutions and best practice development experiences are directly available in CAP. And when deploying the CAP application on the SAP Cloud Platform, the SAP Cloud SDK gives CAP also access to the complete feature set of the Cloud Platform. It will simplify the connectivity, authorization, and identification of other SAP solutions using the SAP Cloud Platform Destinations. The SAP Cloud SDK will provide hundreds of library functions, which will make the use of cloud platform services and capabilities much more straightforward.Another excellent value of CAP is its accessibility to the databases natively. Natively access means that with CAP on the HANA DB, we get full access to database capabilities and artifacts using SQL Script. In RAP, direct access to the HANA DB artifacts is not possible. Through CDS Table Functions and ABAP Managed Database Procedures, read-only tables in the same schema as the ABAP environment are possible.
But the most significant advantage of CAP compare to RAP is its needed runtime. The package manager collects only those libraries the CAP application needs without installing resources the application doesn’t need. The easy integration of API libraries of external vendors prevents us from writing our logic by ourselves. And the multi-target application (MTA) capability of the SAP Cloud Platform makes it possible to write the CAP application in the best fitting programming language and consistently use cloud platform services and external services. Configurations, data access, business logic, service enablement, and UI logic can be written in different programming languages but packed as one deployment package. Using MTA will guarantee the consistency of the application when deployed to the runtime. All these CAP features make the application real lean and mean. It doesn’t need an overkill of resources like RAP. With CAP, we only need to buy and run the SAP Cloud Platform resources we need, which lower the initial cost barrier for starting the project. But the choice of RAP or CAP not only depends on the initial cost. TCO is influenced by multiple factors. Running multiple applications, the availability of specific features you don’t need to develop, the knowledge within your company, your support organization are some of these factors.
Our decision and motivation for CAP
The price tag was our most prominent driver to choose for CAP over RAP for our business case. But we probably also decided on the CAP model based on the compared feature set of RAP and CAP. Our solution is independent of S/4HANA, will not handle massive datasets, and need limited analytic capabilities. It should combine application database data with external API data sources from third-party applications from Google Cloud and Microsoft Azure, and Office 365 Cloud. And based on these requirements, we think CAP fits better for our application than RAP.
Now we know the model, we need to decide which IDE we will use to build our Enterprise-Ready application. In my next blog, I will compare the different IDE for CAP and explain why we choose the Business Application studio.
Many thanks to Andre Fischer (Product Manager for SAP Cloud Platform ABAP Environment and SAP Gateway) and David Kunz (SAP CAP engineering team) for reviewing this blog upfront.
Thanks! Really good comparison, looking forward for second posts regarding IDE selection. ?
Thanks, and I can let you know that I finished the second post, which will be available next week
Hi Robert,
Very good information.Thanks for sharing detailed comparison on both RAP nd CAP.
Thank you,
Syam
Thanks Syam
Hi Robert,
let me add a few comments to your blog.
You are comparing the complete stacks of SAP Cloud ABAP Environment/RAP vs. CF/Java/Node.js. The ABAP RESTful Programming Model is not limited to be used in Steampunk. You can also develop applications based on RAP in your on premise SAP S/4 HANA system.
You have compared the resources needed for a single solution used by a single client.
As announced in our roadmap we plan to support multi-tenancy based on the client field for applications built by partners based on SAP Cloud Platform ABAP environment. This will allow you to have the same solution run for several customers on one instance.
You wrote “In our perspective, CAP becomes, in some ways, the successor of RAP. We believe this even more after Thomas Jung mentioned in the CAP introduction video of the Devtoberfest 2020 that CAP would get all the best practice concepts we known from the ABAP world“.
I do not agree to this statement at all. CAP and RAP are two programming models targeting different environments in SAP Cloud Platform. They allow developers with different skill sets to develop applications with their favorite language and their favorite environment.
And if the CAP developers will get all the best practice we know from the ABAP world then this is great for them. ?
But why would I as an ABAP developer would learn Java Script just for getting the same best practices that I can already use in my favorite environment?
Having said that there is room for several environments and based on your use case, your knowledge and resources we as SAP offers choices.
Best regards,
Andre
Hi Andre,
Thanks for your comment, and you triggered me to clarify points.
You mentioned that it is a comparison of the models but about the stack. If you look only from a product owner perspective, this can be right, but you always look at the possibilities and strength you will get if you choose one or the other model from a customer and developer perspective. And Customers and developers are my target readers, so in my opinion, the title of the blog is right.
You also mentioned that.
‘you can also develop applications based on RAP in your on-premise SAP S/4 HANA system.’
I fully agree, and I also mentioned this as a strength by saying:
'Other key features of RAP are their data dictionary for data artifacts, their transport layer, and, in the case of RAP on S/4HANA, their direct access to SAP S/4HANA Business Content.'
To clarify, I will change this to the RAP on S/4HANA (On-Premise and Cloud).
You mentioned that I compare the resources needed for a single solution used by a single client. And this is correct for the business case we have because we can only compare the currently available prices. And let’s face it, the initial costs for running a RAP environment is much higher than for a CAP environment. This doesn’t mean that the operational costs for a RAP environment can be lower than CAP when running multiple applications. To make this clear, I will change the blog text. I will add my remark about the operational costs.
Besides this, I’m happy that there comes a multi-tenancy, which will lower the running costs for applications built by partners.
You mentioned that 'CAP is NOT the successor of RAP.' I agree, and so that is not what I wrote. I wrote:
In our perspective, CAP becomes, in some ways, the successor of RAP.
First, this sentence is written, in our opinion. Secondly, we try to explain that CAP is implementing RAP and ABAP's great features already providing, only in their own CAP mindset. And this makes it possible to build SAP enterprise applications, you in the past, mostly only build on an ABAP stack. And as you mentioned, customers and partners now have a choice.
I fully agree that CAP and RAP are two programming models targeting different SAP Cloud Platform environments, which was the main driver for writing this blog. And to clarify it even more, I mentioned the strength of RAP and the strength of CAP. I introduce our business case to make clear on which point we look for a decision. And in our business case CAP fits better, but that doesn’t mean that for other business cases, RAP is the better solution.
Hopefully, this will clarify the intentions of this blog.
Kinds,
Robert
For me it does ?.
Thanks for the detailed explanation Robert
Srini
Hi Robert,
Thanks for sharing detailed comparison between RAP and CAP.
Thanks,
Sourav
Hi Robert Eijpe,
thanks a lot for your insights - looking forward on your blog about the IDE's!
I have just one question on your RAP description. You mentioned:
The ABAP programming language, including ABAP CDS, will be translated into the native database behind the scenes. This so-called code pushdown will get the maximum power out of the database, without losing the strengths of the ABAP language.
To me this is a little missleading, because from my understanding ABAP CDS is exactly the one thing (besides AMDP), what is translated to native HANA artefacts to achieve the pushdown. However, when I read your sentence, this indicates that the whole ABAP language is transfered. From my understanding the "common ABAP coding", which you e.g. implement in your Behavior Implementation methods is still processed on the application server and won't be pushed down to the database.
Best regards,
Sebastian
Dear Sebastian,
Thanks for your reaction. I understood your remark that the sentence could be a little misleading if you read it so that all ABAP code is pushed down to the database. To clarify this, I will change the sentence in:
The ABAP programming language will use, when possible, the native database capabilities behind the scenes and run the data handling on database level. With the so-called code pushdown at runtime, we will get the maximum power out of the database, without losing the strengths of the ABAP language.
SAP HANA DB is the most optimized database for this code pushdown at runtime by the ABAP kernel. You can directly relate many new ABAP statements to the HANA SQLScript statements and HANA’s parallel processing capability. And this is a significant performance win if you compare this to ‘classic’ ABAP, where you cache table content on the application layer before processing.
Code pushdown at runtime capabilities can be found in many ABAP codes, such as in the new ABAP Common Table Expression, which will be processed at the database level and reduce the need for internal tables in your ABAP program. In CDS Views, you will also see these capabilities. The CDS Views are stored as Database Views, their data will be handled in the database, and only the outcome will be transferred to the application layer.
I hope this will little background helps you understand what I meant, which the code pushdown at runtime.
Kind regards,
Robert
Thank you Robert for sharing your valuable insights. From a practitioners POV, wanted to know your opinion, if a team is heavy on legacy ABAP developers, will we benefit by gong to RAP or can we also learn CAP with similar efforts as we need to put for RAP.
Also, eager to learn your feedback on the development tools to use as well.
Thank you
Sudarshan
Hi Sudarshan,
Thanks for reaching me out.
Legacy ABAP developers will undoubtedly benefit from going to RAP. The ABAP environment for RAP upgrades to a modern platform, but most tools, statements, and code are recognizable for the ABAP developer. Your legacy ABAP developers should build skills around CDS, OData, and Fiori to work with RAP, which you can also use for S/4HANA development. But they need to learn that also for CAP. Only for CAP, they also need to build knowledge around SQLScript for native HANA artifacts, Node.js or Java for service layer development, and Cloud SDK for accessing business APIs.
From a learning perspective, the road for Legacy ABAP developers to RAP is much more comfortable. But this also depends on your future solution requirements.
Internal, we have a learning road for ABAP developers and Next-Gen developers, and after every stage of the road, they can have a role in our projects. Our learning roads are:
For ABAP developers
Next-Gen developers who have Node.js and HTML5 experiences
I hope this will give you more insight into the transition of SAP developers for the future.
I recently published a blog about the IDEs for Cloud Application Programming (CAP) development.
I also encourage you to read my blog series: Why do cloud business applications change your custom build application development. In this blog series, I explain the trends for Cloud developments and how they will impact your organization.
Answer my queries as well. Thanks for listing all those details!
Great analysis, I've used both stacks and being an ABAPer, RAP looked more natural.
CAP was a lot harder to learn, especially the NodeJs parts. But after that it became relatively easy. For the same application, I built faster apps with CAP than RAP.
If an app would be a BAPI extension, I would go for RAP, closer to the source (ERP) language, but for something fully customer specific, I would go for CAP (since I can develop offline).
Another Important point for RAP, most legacy ABAPers use SAP GUI and have a certain aversion to ADT. The fact that they would have to use only ADT, source code vision of classes, it would be difficult for them as well.
Hi Robert (or any SAP colleagues),
Do you know if the ABAP cloud runtime would become available as an alternative to Java and Node.js under the CAP scenario?
I’m coming from the angle of a large company with a large pool of ABAP developers and no Java or Node.js knowledge (nor any real desire to go down the Java/Node path). And I’m talking about a scenario where all of the SAP ERP systems are not on S/4HANA and may not be for a few years.
And is it possible to use the RAP approach without an S/4HANA on-premise or S/4HANA cloud backend? My understanding, also from the current OpenSAP RAP training, is that the backend must be S/4HANA to be able to use RAP. It seems to me that technically RAP should work also with the SAP Cloud ABAP runtime service and without S/4HANA, but I am not sure?
e.g. can we purchase the SAP Cloud ABAP runtime and use the RAP scenario without S/4HANA to build stand-alone cloud applications, or side-by-side cloud extensions to our ECC backends?
Note that we already run SAP Cloud UI5 apps with OData calls to ECC for the business logic/data, but we may like to create stand-alone apps or extensions to ECC running in SAP Cloud via cloud ABAP and cloud HANA DB.
Thanks,
Brendan
Hi Brendan Farthing
The openSAP RAP training is already using the ABAP on cloud runtime you are asking for. You can use ABAP runtime on SCP to connect to non-S4HANA on-premise systems. And frankly, even non-SAP systems.
Thanks Jhodel, that’s exactly what I was thinking. But it was clearly stated in the course that RAP can only be used with S/4HANA 19xx and higher, which had me puzzled because we were obviously in the Cloud Foundry ABAP service when doing the exercises.
That statement is also correct! To clarify this, there are two platforms you can use RAP:
If you are already on S/4HANA 1909, you don't really need to invest in SCP ABAP Runtime.
Hi Robert
Thank you for writing a nice blog which actually helps me to understand RAP and CAP and which one to choose on what specific reasons. And I expect more open source stuffs from SAP.
Regards,
Sathish
Nice Post, thanks for sharing!
Most comprehensive explanation.
Thanks for sharing.