ABAP RESTful programming model

A brief overview of the history and the new functions of the programming model

The ABAP RESTful programming model (RAP) consists of frameworks, concepts, language features and the supporting tools and best practices. It defines the way how a web-service backend application should be developed in ABAP. The data model can be defined in a clearer and more abstract way, we can get a quick preview in a form of a SAPUI5 application from our entities in just a few click where we can validate our development before the real UI development begins.

The goal of the ABAP Platform team was to modernize application development. The intent and the used technologies were there, they only had to be improved further. In the evolutionary predecessor model, there was a complete framework and tooling to develop a modern application: the modern backend, the standard OData v2 application can be created in the Gateway Service Builder (SEGW) and under the Internet Communication Framework (ICF) the SAPUI5 application can be added. To create the implementation of the backend functionalities an ABAP developer needed who could become familiar with the Gateway Service in a short time.

The ABAP RESTful application model wants to provide an improved development flow by standardizing it and makes Eclipse ABAP Development Toolkit (ADT) the one and only development tool. The assumption would had been that beginning since ABAP 7.5 most of the developers using ADT as the development tool, why not be able to do all the service definition there without using external tools like SEGW. Each development in ADT has its own wizard, for some of the objects we can choose to get a stub to start with. Auto-completion, element info and static code checks are the key players to help the development flow.

Since ABAP 7.5 the ABAP CDS language is available and in HANA platform, we saw that CDS can also be the sufficient descriptor to define an OData service. In RAP they used the same idea: there is no need for an external tool like SEGW to define OData entities as it can be derived from the CDS model itself, furthermore the service definition itself can be protocol-agnostic we do not have to stick with OData (although currently this is the only supported). We need two types of development object: the protocol-agnostic service definition and the service binding which binds the definition to a specific protocol and scenario. The service definition contains the list of entities from our data model, in that way one data model can be reused for different service definitions.

The term Business Object (BO) has been dusted off in RAP. We could say that BO is the representation and runtime implementation of an entity from the CDS data model. In the Behavior development object, we can configure the locking, the authorization and draft handling and tell which CRUD operations and functions are available. The BO lifecycle is divided into the Interaction Phase and the Save Sequence, both contains multiple steps. As Runtime Implementation for the BO RAP offers the managed and the unmanaged scenario. With the former we tell the runtime to handle the whole lifecycle of the BO in this case we do not have to write a single line of code it works out of the box, if using the latter, the developer is responsible to create an implementation class and handle all the steps by writing the processing code, this is where we can reuse exiting application code.

The RAP framework makes it possible to try out the implemented service immediately in the so-called Fiori Elements preview application, which is an SAPUI5 application. We can understand it better if we know that Fiori Elements was called Smart Templates before, and it was smart because it is controlled by the UI Annotations of our data model without further coding. The UI Annotations tells how to represent the data, and the UI Components are programmed to behave by these directives. If we add UI annotations in ABAP CDS, it will show up in the OData service metadata and the Fiori Elements preview can be displayed without a single line of UI code. Developer test, business verification can be done easily and immediately it is not necessary to wait for the development and deployment of the UI application.
The first RAP release was in 2019 and it is a promising direction. CDS is the main cornerstone not for just RAP but also in Cloud Application Programming model which is the future of Cloud Foundry development. It is a safe investment to work with these technologies, standard report programs and ALVs can be implemented with an OData service and a Fiori Elements application.
We can try it out in S/4 HANA Cloud 1808, 1909 on-prem with limited functionality, for example the managed scenario is not available. In Steampunk – SAP Cloud Platform ABAP Environment or ABAP PaaS – we can benefit from the newest technologies. Steampunk is also available in the Cloud trial version but with a regional workspace for multiple developers.

Useful links:

SAP Development Tools

ABAP CDS Views – SAP Help Portal

Building Apps with the ABAP RESTful Application Programming Model

Getting Started with the ABAP RESTful Application Programming Model (RAP) | SAP Blogs

ABAP Platform Sessions at SAP TechEd 2020 | SAP Blogs

SAP Cloud Platform ABAP Environment | SAP Blogs

The ABAP Platform Strategy (2020 Update) | SAP Blogs

SAPUI5 Smart features controlled by OData Annotations | SAP Blogs