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
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
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
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.
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.