The following contribution is intended to mark the beginning of a whole series of technically oriented blogs that will cover the “ABAP Restful Application Programming Model“ (RAP Model) as the de facto successor to the “ABAP Programming Model for SAP Fiori”. While the RAP model was originally only introduced for SAP BTP ABAP (formerly: SAP Cloud Platform ABAP), it can also be used in on-premise systems since SAP S/4HANA Release 1909, although not with the full language scope. The language scope was greatly expanded once again in an S/4 2020 and this will also remain in forthcoming releases. Here new features will be brought out every quarter for SAP BTP ABAP. These will find their way into on-premise systems via the annual S/4HANA releases. The focus of this blog is therefore going to be on the on-premise releases (especially S/4HANA 2020). Because the majority of the work of ABAP developers on a day to day basis always has to do with these or older systems. In this first blog I would like to explain the general concepts of the RAP and its advantages compared to the “ABAP Programming Model for SAP Fiori“.
ABAP Programming Model for SAP Fiori
The “ABAP Programming Model for SAP Fiori” is available on on-premise systems with Netweaver Basic Release 7.5 and higher.
Compared to classical ABAP freestyle programming, it enormously reduces the amount of code required for the modeling and implementation of a business object. However, due to its architecture it is more suited for greenfield approaches in which a new business object is defined. Here the corresponding CDS views form the core and are given the corresponding annotations so as to automatically generate the corresponding artifacts such as BOPF objects and SAP Gateway Services. However, this architecture has a number of disadvantages. Very many artifacts are generated in various layers, which make error analysis complicated and difficult. In addition, BOPF was developed before CDS. In detail, it is often more difficult to link these two networks than appears to be the case at first glance, since both need to be developed and maintained in parallel. Furthermore, for example, many redundant annotations are also required across various layers of the Virtual Data Model to activate comparatively simple features such as a Draft Mode for a business object.
ABAP RAP Model
The ABAP RAP is available on S/4HANA on-premise systems from Release 1909 onwards. Since the language scope was greatly expanded again with Release 2020, the focus will be on that in the following. As can be seen from the following illustration, the ABAP RAP essentially consists of three layers:
Data Modeling & Behavior
The main task of this layer is the definition of the data model through CDS entities based on database tables and other CDS entities. Here the fields of a CDS view represent the properties of the business object and compositions and associations represent the links to sub-objects and other business objects. A simple example for a composition would be a customer order and its link to the corresponding order items. Since orders are always created for one customer, the link to the business object (as an independent business object) would be an association.
A further important part of this layer is made up of so-called “Behavior Definitions”. While in fact the CDS entities describe the data model, including its links, the “Behavior Definitions” define the transactional behavior of the business object. In addition to the usual transactional CUD (create, update, delete) methods, among other things, the Behavior Definition also controls possible actions of the business object, the blocking behavior, draft handling and other field-related properties (Validations and Determinations). Lastly, there is also the “Behavior Implementation”, that makes it possible for a business object in ABAP to implement its own business logic. For example, these can be Validations or Determinations that had been defined previously in the Behavior Definition, or also actions that initiate a status change or the like, for example. In this connection it is also necessary to mention that basically there are two different scenarios in the ABAP RAP:
- Managed Scenario
- Unmanaged Scenario
The Managed Scenario is especially well suited for a greenfield approach and leaves large parts of the transactional behavior to the framework. It is somewhat less flexible, but also requires markedly less code. The Unmanaged Scenario places the entire implementation of the business object in the hands of the ABAP developer. This requires more implementation work, but also allows greater flexibility. Consequently, it is therefore also suitable for brownfield approaches if, for example, legacy business objects in the form of BAPIs or other legacy APIs have been incorporated. This is a clear advantage over the ABAP Programming Model for SAP Fiori.
Business Service Provisioning
This layer primarily consists of “Service Definitions” and “Service Bindings”. However, before these artifacts are created, it is also possible to restrict the view to a business object in a user- or process-dependent way via “CDS Projection Views” or “Projection Behaviors”. Thus, for example, a large business object with many attributes and dependent datasets could be displayed in a very lean way for a certain user group.
Service Definition: This makes a service available on the basis of a Behavior Definition, or a projection to the outside.
Service Binding: Based on a Service Definition, a Service Binding makes the business object consumable from the outside via OData V2/V4, or a Web API.
View
In the forthcoming blogs I will present a concrete example in a Managed Scenario and an Unmanaged Scenario, In addition, expanding successive objects with additional features such as draft handling, and Validations and Determinations.
