Anthony Cecchini is the President and CTO of Information Technology Partners (ITP), an ERP technology consulting company headquartered now in Virginia, with offices in Herndon. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 20 years of experience in SAP business process analysis and SAP systems integration. ITP is a Silver Partner with SAP, as well as an Appian, Pegasystems, and UIPath Low-code and RPA Value Added Service Partner. You can reach him at [email protected]
SAP delivers a lot of possibilities to build a future proof SAP application. SAP has delivered two new programming models: the ABAP Restful Application Programming (RAP) model and at the Cloud Application Programming (CAP) model.
Programming models have changed from list models for SAP GUI-based apps and DYNPRO to WEB DYNPRO for web-based applications, then the SAP ABAP programming model for Fiori. SAP Fiori’s ABAP programming model has significant advantages in its flexibility, efficient modeling, and evolving landscape. Still, SAP HANA does not have some functionalities like typed access for business entities and simplicity, which are essential for application development. SAP introduced a new programming model named RESTful ABAP Application Programming (RAP) to fill this gap.
With RAP, you can build cloud and on-premise Fiori applications optimized for S/4HANA. Developers have written codes in languages like OData, UI5/Fiori, CDS, and ABAP on platforms like SAP Editor, SAP Web IDE, HANA Studio, and SAP NetWeaver to get CRUD operation for their business data. These come with limitations like platform independent development and source independent development. To negate the dependency on several platforms while combining open-source tools and SAP on one platform, SAP introduced Cloud Application Programming (CAP).
The blog below will delve into what RAP and CAP entail and the differences between these two SAP solutions to help you understand how best to use them in your application development.
To understand RAP, you need some information on the evolution of ABAP programming models. These include the traditional ABAP model and the ABAP programming for Fiori.
The classical ABAP programming model features developments and applications made using ABAP GUI-like transaction codes, reports, and module pools. The model is intended for full server-side processing on an ABAP application server. As an on-premise model, it can create web-Dynpro and ABAP GUI applications, thus providing significant value for customers. The introduction of Core Data Services (CDS) allows data modeling infrastructure and development capabilities on SAP HANA for ABAP. The views on CDS are virtual data models allowing access to tables on the HANA database. CDS-based data models are semantically rich, allowing their use in all application domains. Nonetheless, you cannot perform transactional services because the views are read-only. Moreover, only developers can implement OData services on the classical ABAP programming model.
ABAP programming for SAP Fiori was introduced to overcome the drawbacks of traditional ABAP programming. This model reduces the complexities of coding to execute gateway services as CDS views that can be exposed as OData services. The basis of the ABAP programming for Fiori model is modern technologies such as SAP Gateway services, CDS, and Business Object Processing Framework (BOPF). The model allows developers to use only ABAP to create applications.
ABAP RESTful Application Programming (RAP) is an architecture allowing the end-to-end development of SAP HANA OData services in the Application Server ABAP or SAP BTP ABAP Environment. It is an efficient solution for building enterprise-ready optimized Web APIs and OData-based Fiori UI services on-premise and in the cloud. With it, you can create several publishing APIs and Fiori applications. ABAP RAP uses CDS to define semantically-rich data models and a service model infrastructure that creates OData services binding to an ABAP-based application and OData protocol.
Here is a diagram summarizing the evolution of ABAP programming models.
With ABAP RAP, users can interact with applications behaving naturally across all devices and adapting to each device’s footprint. Developers have a toolset allowing the streamlined development of applications while leveraging the pushdown capabilities of HANA. You can use RAP to develop new applications and integrate them into existing apps based on OData services.
There are three main layers in RAP that enable it to deliver its benefits. These include:
- The data modeling and behavior level which contains domain-specific business objects defined with transactional behavior and CDS.
- The business service provisioning level comprising projection views and projection behavior to focus on a specific data model aspect that is exposed through the OData protocol as business services.
- The service consumption level that allows one to consume all OData services and OData Web APIs.
ABAP RAP is the best choice when you want to :
- Boost your end users’ UI acceptance by using role-based, draft-enabled responsive, extensible SAP Fiori apps.
- Transition custom applications fully or partially to the cloud from on-premise now or later.
- Drive innovations in business processes by harnessing the power of HANA capabilities like high-performance processing for data mining, predictive analysis, and new interaction types.
Application developers are looking for solutions that shorten their development timeframes so they can get their creations to the market as fast as possible. In the past, short timeframes meant compromising the quality of applications. Developers could only do so much to ensure the delivery of error-free codebases within compressed timeframes. The Cloud Application Programming model (CAP) was established by SAP to solve this issue.
CAP is a framework of libraries, tools, and languages for creating enterprise-grade applications and services. With this programming model, developers can be domain-centric, so they can work at higher abstraction levels compared to when using traditional frameworks and platforms. As such, when focused on the business elements of an application and its projected accomplishments, a developer can create applications that will deliver more benefits for their end-users.
At its fundamental level, CAP comprises broadly adopted and proven SAP and open-source technologies, as shown in the below:
In the CDS, you have the core data services runtime and Services SDKs. The CDS is the universal modeling language allowing developers to create service and model definitions, while the runtime and Services SDKs are for Java and Node.js, which offer libraries for implementing and consuming services. The development tools in CAP include Visual Basic Studio or SAP Business Application Studio, allowing developers to freely use any language for developing applications.
All applications need databases. The SAP CAP allows developers to use SAP HANA or other databases. There is out-of-the-box support on the frontend for SAP Fiori, but developers can use any frontend frameworks with which they are conversant. The CAP is an overarching ‘platform-as-a-service’ containing development tools, middleware, database management systems, and business intelligence services. With it, you get the entire web application lifecycle, including development, testing, deployment, and continuous updating.
SAP CAP works on three principles, including:
- Zero lock-in, meaning it is not overly prescriptive. Developers can choose the architecture frameworks and tools they will use.
- It is non-intrusive, meaning only CAP developers need to know of the existence of the framework. You thus can use it with a third-party library without the latter knowing which framework you use.
- It is platform-agnostic, meaning you can build and deploy applications free of the core cloud infrastructure. You can use APIs for integration.
From the above, you understand that RAP and CAP are programming models with many benefits to developers. Nonetheless, there are significant differences between the two. Here is a table to help clarify your understanding of these differences.
Most will base their choice of a programming model for their applications on cost. When comparing CAP and RAP, the features of CAP make it quite lean, so it does not need as many resources as RAP, an aspect that makes CAP cheaper than RAP. Nonetheless, the cost is influenced by multiple elements, including your knowledge, the specific features you want to develop, the support you need, and the applications you will be running, among other elements. As such, you cannot solely base your choice between RAP and CAP on cost.
Thus, you can look beyond cost to choose between the two SAP programming models. Both models are promising and perfectly fit into the vision of SAP of accelerating innovation and ensuring the applications you develop suit the ever-changing needs of end users.