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
RAP Big Picture
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.
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.
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. 😊
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.