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.