RAP - Introduction
The ABAP RESTful Programming Model will be the programming model of the future in the ABAP area, in this article we will look at the meaning, use and structure.
Table of contents
Some will ask: Why was another programming model developed? Others will ask: programming model? But the answer is very easy, the technology for the frontend has changed and developers, in contrast to the past, have to model data in the backend and make it available to the frontend via a service. The classic ABAP development has changed a lot and so have the requirements for a backend developer.
RAP
The ABAP RESTful Programming Model, or RAP for short, is one of the two programming models that was created with the Business Technology Platform (BTP). The other is the Cloud Application Programming model, CAP for short, and is based on NodeJS or Java. In this series, however, we will focus on RAP and thus remain true to ABAP.
RAP is now the third programming model when you look at ABAP development. In addition, the following graphic, which puts the three models side by side and shows the development well:
The first model (1) was based on freestyle development with dynpros and classic via PBO/PAI. Everything that the GUI construction kit offered and made available to the ABAP developer was possible here. The second model was the ABAP Programming Model for SAP Fiori (2) with the first Fiori applications supplied via the OData service. The SEGW transaction plays a central role in providing the service and the majority of the development takes place in the classic development tools. RAP (3) is the latest programming model, based primarily on Core Data Services.
Requirements
Although RAP is a cloud programming model, it has now also arrived in S/4 HANA for on-premises, since the versions share the same core. The following overview of the releases:
- Release 1808 - First release in the cloud (ABAP Environment)
- Release 1909 - On-premise release without validations, determinations and only as unmanaged
- Release 2009 - Managed and Unmanged On-Premise available, now fully usable
- Release 2109 - Recommendation to only use RAP as a programming model on on-premises
From the 2009 release it can now be fully used and learned with. From this release you can already start implementing applications, smaller functions such as draft or late numbering are still missing.
Structure
How is RAP structured and how is such a new business object assembled? First of all, the following overview picture with the individual layers. You should note that the model is always based on database tables.
On the bottom layer is the data model and the modeling of the relationships among each other. Core data services are created here that model the object and a behavior definition to implement additional functions.
The middle layer models the object for external use, the so-called projection. This defines the functionality for the application or API, it can limit the functionality but not add new functionality. The protocol in the service binding is also defined on this layer.
The last layer describes the scope for using the services.
Managed vs Unmanaged
We already mentioned the managed and unmanaged approaches above, what is that all about? This is primarily about migration scenarios that you want to map as a brownfield. If you still have existing encapsulated objects that take care of managing the data, then you can reuse them in an unmanaged object and don't have to develop everything from scratch. If you rely on Greenfield and have to redo everything anyway, then definitely use the managed approach.
With most new developments, you will always rely on the managed approach, since the entire administration of the object is taken over for you here.
Scope
What is in a business object and how can you use it? Here is a list of functions that you have available within an object:
- Validation - Checking of fields and states of the data. Error messages can prevent saving so that no inconsistent state is saved.
- Determination - Enrichment of the data and fields via rules, external APIs or existing information.
- Action - Triggering an action in the context of the business object in order to process data consistently or to implement status.
- Draft - Caching the data without changing the productive data. If the data is consistent at the end, the productive data is updated.
What can you do with a RAP object and what can you use it for?
- OData for an application (with annotations)
- OData as API
- Data integration
- Replacement for BAPI
We will explain the individual categories, functions and topics to you in the following articles so that you get a clear idea of what you can do.
BOPF
If you have looked at the scope and content of RAP and already know BOPF, then you will see many parallels to it. BOPF already represented a business object and combines tables into a logical unit. Also with BOPF there are validations, determinations and actions on the object, this concept was adopted for RAP, but reduced by the boilerplate code and the framework.
Conclusion
RAP will play a very important part in ABAP development in the future and should already be a have-to-learn for every ABAP developer who still has a few years to go. If you don't currently have a system to learn it, we recommend the free version via BTP, a sandbox system with Foundation Stack (no costs except hardware) or the Developer Edition for private computers.
