Modernization with the ABAP RESTful Application Programming Model (RAP)
Last edit: 2023-02
This blog is about recommendations for building modern applications and Web APIs with RAP on SAP Business Technology Platform (BTP) ABAP Environment – aka Steampunk – and SAP S/4HANA.
A. Why using the ABAP RESTful Application Programming Model (RAP)
The ABAP RESTful Application Programming Model (RAP) is a set of concepts, tools, languages, and powerful frameworks provided on the ABAP platform. It supports the efficient development of innovative and cloud-ready enterprise applications, as well as the extension of SAP standard applications in an upgrade-stable way in the cloud and on-premise.
RAP is an enabler for improving the user experience and innovating business processes in ABAP-based SAP solutions by leveraging SAP Fiori, SAP HANA, and the Cloud. It is a long-term strategic solution for ABAP development on SAP’s flagship product SAP S/4HANA, cloud and on-premise (as of release 1909) editions, as well as on the SAP BTP ABAP Environment.
SAP uses RAP to build new standard applications and modernize existing ones. SAP also recommends its customers and partners to use it for their custom developments on SAP S/4HANA and SAP BTP ABAP Environment.
RAP is based on proven and modern technologies and concepts. These include:
- Core Data Services (CDS) used to define semantically rich data models for all application domains
- The modernized and extended ABAP Language used to implement the business logic
- The OData protocol used for stateless communication and the SAP Information Access (InA) protocol used for live data access
- The concept of Business Objects used for building transactional applications
- The concept of Draft used for building stateful applications with stateless technologies
- The concept of Business Services used to create OData-, InA-, and SQL-based services
RAP offers a standardized development flow in the modern ABAP Development Tools in Eclipse (ADT) and a rich feature set for building applications of different domains, such as transactional and analytical apps, whether from scratch or by reusing existing custom code.
Different types of services and local APIs can be developed with RAP:
- OData-based services for exposure for UI development to build delightful, role-based, responsive, and draft-enabled SAP Fiori apps
- OData-based services for exposure as Web APIs
- InA-based, analytical services for building analytical apps in SAP Analytics Cloud
- SQL-based services for data integration
- Lifecycle-stable and upgrade-safe local APIs can be provided via released business objects
Built-in capabilities such as ABAP unit tests, the ABAP cross trace tool, and knowledge transfer documents are offered along the RAP development stack to cover core software quality concepts such as testability, supportability and documentability.
Comprehensive developer guides and other educational materials on RAP, such as the ABAP Flight Reference Scenario with implementation examples and a free openSAP course, complete the offering to reduce the developers’ learning curve.
Previous programming models such as the ABAP Programming Model for SAP Fiori, the classic Business Object Processing Framework (BOPF), Web Dynpro, and Dynpro have reached maturity and will continue to be supported by SAP in on-premise systems. However, SAP’s future direction with respect to ABAP application development is clearly based on RAP. RAP is the only recommended programming model in SAP S/4HANA on-premise as of edition 2021 and SAP BTP ABAP environment.
|Find more information here: Modern ABAP Development with RAP (SAP Community page)|
B. Greenfield and brownfield implementations
The heart of every application resides in the data model that comprises the description of the different entities involved in a business scenario. Depending on the use case, data models support transactional access or read-only query access to the database. Therefore, the data models are used in either business objects or read-only queries in RAP.
RAP offers two main technical implementation types, namely unmanaged and managed, for read-only and for transactional scenarios.
In read-only scenarios, the behavior of the data model is defined by the query capabilities, for example the filtering or analytical characteristics of the data. Unmanaged query implementations are defined with CDS custom entities and managed query implementations are defined with CDS views.
In transactional scenarios, the behavior of the business object (BO) defines which operations and characteristics belong to a business object. To define and implement a BO behavior, a new ABAP repository object type, the behavior definition, was introduced and the ABAP language was extended to include the Entity Manipulation Language (EML).
The unmanaged BO implementation hands over the responsibility to developers to provide the BO runtime implementation for all the data retrieval, business logic, and data storage. This includes the implementation of locking and the handling of transactional buffer. This implementation is typically used for brownfield application developments where existing custom code should be reused.
The managed BO implementation type is fully managed and orchestrated by the underlying RAP framework which manages all specified characteristics from the create, read, update and delete operations out of the box, hence its name. This relieves the application developers from repetitive implementation tasks such as constructing SQL statements to retrieve data from the database table or with technical aspects of transactional processing. In transactional scenarios, developers can therefore focus fully on providing the application-specific business logic. This implementation is typically used for greenfield application developments where developers start from scratch.
The managed BO implementation offers different variants for special transactional use cases. For example, the implementation type managed BO with unmanaged save which offers a combination of both main BO implementation types to address scenarios where the reusable legacy business logic (update function modules) is only used for the data storage. The implementation managed BO with unmanaged lock can be used for use cases where developers want to implement their own locking logic for a managed BO – e.g. use existing lock objects.
Besides the implementation types described above, SAP plans to offer a new implementation type, the BOPF-managed BO implementation, for the migration and integration of CDS-based BOPF BOs originating from the ABAP Programming Model for SAP Fiori into the RAP framework in the near future. This implementation type will be offered to customers and partners who have built applications with the ABAP Programming Model for SAP Fiori and would like to safeguard their investments but also take advantage of the benefits offered by RAP. However, a migration of existing, generated, CDS-based BOPF BOs will not be technically mandatory when upgrading to the latest SAP S/4HANA release since the ABAP Programming Model for SAP Fiori will still be supported in the future. Classic BOPF BOs will not be supported by this implementation.
|Find more information on RAP implementation types here: Query Impl. | Business Object Impl.|
C. Recommendations: When to use what
With the knowledge about benefits and the different technical runtime implementation types offered by RAP in mind, the next step is to understand when to use what.
The most prominent business requirements leading to a clear recommendation for custom development with RAP are around user experience (UX), SAP HANA innovations and the cloud.
The main customer and partner requirements are:
- You want to increase the UI acceptance of your end users by using draft-enabled, role-based, responsive, delightful, and extensible SAP Fiori Apps.
- You want to transition your custom applications partially or fully from on-premise to the cloud now or to a later time and want to be best prepared for that.
- You want to drive innovations in your business processes by leveraging the power of SAP HANA capabilities such as the high-performance processing for new types of interactions and processes, data mining, and predictive analysis.
For all transactional scenarios, the common primary task is to build RAP business objects (BOs) for exposing the required data and functionalities. The choice of the appropriate BO runtime implementation type depends on the availability or not of reusable custom code.
Status Quo 1 – No custom code available
You want to build new custom applications, rich extensions, or APIs from scratch, i.e., greenfield implementations.
The managed BO implementation is recommended for such scenarios. The RAP application infrastructure provides developers with the utmost support in this implementation.
Status Quo 2 – Tightly coupled custom code available
You want to modernize and innovate existing applications and APIs by reusing the custom business logic from the existing apps. Unfortunately, the code is tightly coupled to technical aspects such as UI technologies and protocol, unstructured and difficult to maintain, and therefore, can hardly be reused for rebuilding the applications with RAP.
Typical examples of such existing apps are:
- Dynpro or web dynpro based apps where the business logic and the UI logic are tightly coupled
- Code-based implementation of an OData services built without CDS in the SAP Gateway Service Builder (SEGW) using the Model Provider (MPC_EXT) and the Data Provider (DPC_EXT) classes
If at least the existing custom code for the update task can be decoupled and reused, then the managed BO with unmanaged save implementation is the recommended solution. This implementation type allows a large part of the BO runtime to be managed by the RAP framework and solely the save operation to be handled by the developers. In such cases, the data consistency has to be ensured with appropriate validations and determinations.
If none of the existing custom code can be reused, you can start from scratch by using the managed BO implementation.
If CDS custom entities have to be used instead of CDS views for data retrieval, the unmanaged BO implementation without draft is the only possible option.
Status Quo 3 – Loosely coupled and reusable custom code available
You want to modernize and innovate existing applications; fortunately, the existing business logic is decoupled from technical aspects such as UI technologies and protocols. Also, it is well modularized and can be reused for the interaction phase and the save sequence of the business object runtime for building the new applications with RAP.
Typical examples of loosely coupled and reusable code:
- Applications built with the classic BOPF framework
- Function modules, BAPIs or any other object-oriented custom APIs that do not performed COMMIT statements when being executed, or wrappers
Depending on the available reusable custom code, the unmanaged BO implementation or the managed BO with unmanaged save implementation is recommended.
If APIs are available for the different CRUD operations – i.e., create, read, update, and delete – can be called separately and if a transactional buffer is provided by these APIs, then the unmanaged BO implementation is recommended.
If only the update function modules can be reused, then the managed BO with unmanaged save implementation is recommended. In such cases, the data consistency has to be ensured with appropriate validations and determinations.
If CDS custom entities are used in the implementation, the unmanaged BO implementation without draft is the only possible option.
Status Quo 4 – Custom code originating from the ABAP Programming Model for SAP Fiori available
You want to modernize applications built with the ABAP Programming Model for SAP Fiori to access the benefits of RAP by reusing the generated, CDS-based BOPF BOs and its implemented business logic.
The recommended approach for such scenarios will be the BOPF-managed BO implementation for CDS-based BOPF BOs which SAP plans to be deliver in the near future.
Status Quo 5 – Never change a winning team
You want to build a new application which will be part of an existing application suite – i.e. You want to build the 101st app. No RAP specific requirement, such as cloud-readiness or draft-enabled SAP Fiori UI, applies to your use case.
The recommended approach for such scenarios is to use the same technology as the relevant application suite for building the new application – unless you want to use the latest and greatest ABAP features. 😊
|Find more information: Dealing with Legacy Code and Transactional Consistency in RAP (video)
| Conversion Exits and RAP (blog post) | Using BAPIs in RAP (blog post) | SAP LUW in ABAP Cloud (blog post)
The ABAP RESTful Application Programming Model (RAP) defines a unified architecture for the efficient and rapid development of cloud-ready, future-proof, enterprise services and the extension of SAP standard applications in the cloud and on-premise.
Whether starting from scratch or reusing existing business logic, RAP can be used on the ABAP platform to build applications for various application domains, e.g., transactions and analytics – in the cloud as well as on-premise.
SAP uses RAP to build innovative, ABAP-based applications and also recommends its customers and partners to use of the same programming model for their custom developments on SAP S/4HANA on-premise, SAP S/4HANA Cloud, and SAP BTP ABAP Environment.
SAP plans to deliver advanced, built-in extensibility options for data models, business object behaviors, business object nodes, and business services with upcoming on-premise and cloud releases. Another step planned is to lower the total cost of development (TCD) by supporting the seamless integration of reuse components, such as business events, notes, and change documents.
- 🔥Modern ABAP Development with RAP | SAP Community page
- Getting started with RAP | RAP FAQ (blog post)
- RAP – What’s New on: SAP BTP ABAP Environment | SAP S/4HANA (SAP Help)
- Building Apps with RAP (openSAP course)
- Evolution of the ABAP Programming Model (blog post)
- Compact Feature Availability Matrix of ABAP Programming Models (RAP, BOPF, Gateway)
- Guidance for developing RAP applications in ABAP Devtoberfest 2021 (video)
- ABAP Platform Releases and Consumers (blog post)
- Conversion Exits and RAP (blog post)
- Dealing with Legacy Code and Transactional Consistency in RAP (video)
- Using BAPIs in RAP (blog post)
- ABAP at SAP’s Devtoberfest in 2022 (blog post)
- 🔥ABAP Cloud (blog post)
- SAP LUW in ABAP Cloud (blog post)
does it make sense to use RAP for 'internal' development only? 'Internal' means development for customers, who use SAPgui only.
It seems to me, that RAP is usable in SAPgui development as well. BO can be modeled (including behavior). And then such BO can be consumed in SAPgui by EML calls?
Advantage of such development is, that logic can be easily converted to API, Fiori?
Does such development makes sense?
Yes, technically you can use RAP to encapsulate your business logic by building Business Objects (BO) which can then be consumed using the EML APIs. For example, you can consume the RAP BOs in a dynpro-based applications (SAP GUI).
The same BOs can then be used to build SAP Fiori Apps or Web APIs.
Hope this helps.
thank you very much, have a nice day.
Suppose I want to create custom Purchase order create FIORI application(using ABAP RAP & Fiori elements) where I have to enter material , quantities as input fields for that order. We have the standard BAPIs which creates the order and commits it and generates the order number.
So, which implementations are you suggesting, is it the managed, or unmanaged one...?
The RAP transactional model is seamlessly embedded in an SAP LUW (Logical Unit of Work) – which comprises all operations and work processes that are used to transfer data from a consistent state to another. To ensure the transactional consistency during the LUW of RAP applications, only the RAP framework is allowed to issue a COMMIT statement. The LUW of a RAP application is then terminated when the database COMMIT is executed successfully and the transactional buffer is cleared.
For this reason, the integration of APIs issuing COMMIT statements into the RAP framework is forbidden.
Regarding the use of public SAP APIs, we recommend that customers and partners first check whether released RAP Business Objects are available for the respective purposes. The SAP S/4HANA team is in the process of releasing more APIs such as RAP BOs.
Hope this helps.
I have seen many blogs on RAP and felt this would be right approach for building my greenfield solution. Can you refer me to any standard application built on RAP to understand all the possibilities of this programming mode and how the front application can be designed!
Hello, I faced this error .
Unable to find annotationPath undefined when previewing RAP List report App.
let's take the example of Ayan where he wants to use a BAPI which performs a commit. You answer that it's not possible to use it as it's necessary to let the RAP framework do the commit as the commit from RAP clears the RAP transactional buffer.
Now my question: Would it be possible to reuse the standard BAPI code without the Commit and let the RAP framework do the commit? If so, what needs to be done to achieve this. Just leaving out the commit in the BAPI?
I am also really curious about the answer to this question.
First of all, thanks for the great information.
- Object Oriented programming
- SAP GUI
- SAP S/4 HANA System
- Own Business Logic
- we also use standard BAPI's
We want to reorganize an Application using the above, with RAP. We want to migrate to a SAP BTP Abap Environment Cloud system. Our aim is to separate our Custom codes from the system kernel with "side-by-side". As far as I understand from what I've read, we have 2 options. Maybe even just option 2.
1. MANAGED BO with unmanaged save implementation
2. UNMANAGED Scenario
I reviewed the "Unmanaged flight scenario". Here the Function is called from the "Behavior Implementation Class". Then our own class is called through this function. In summary:
Behavior Implementation Class -> RFC -> Own Class
Can we do this in all unmanaged scenarios? And are there any other ways to do this?
How do we call public SAP APIs? Are there any tutorials on these?
At present, in our applications we use the POST API and BAPI to Create or Update the entries in standard SAP tables, in the blog it is mentioned we need to use RAP Framework to commit to the standard data base tables. I am not able to see any sample or examples where the standard SAP table CRUP operations using the RAP. Please through some light on this area ,