Understanding the ABAP RESTful Application Programming Model

The ABAP RESTful Application Programming Model, also known as the ABAP RESTful Programming Model (ABAP RAP or RAP), provides a programming framework designed:

• As a long-term strategic solution for modern ABAP development
• To enable efficient development for SAP Fiori apps and Web APIs, whether creating applications from scratch or by integrating legacy code
• To support an end-to-end development experience by providing:
  • Standardized development flow
  • Best practices and development guides
  • High development efficiency
  • Focus on business logic, rather than technical aspects
  • Native testability, documentability, and supportability
  • Code pushdown to SAP HANA
  • Convenient support for stateless and stateful environments
• To support the product qualities:
  • User Experience: SAP Fiori and SAP HANA
  • Cloud: Scalability
  • Flexibility: Break-outs for non-standardized implementations
  • Out-of-the-box extensibility and verticalization

The ABAP RAP is a programming model for ABAP that is RESTful, which means that it meets the requirements of a REST architecture. In ABAP RAP, AS ABAP plays the role of a stateless Web server.

RAP primarily provides the following development options:

• Service Development
• Universal Programming Model
• On-premise and in the Cloud

ABAP Core Data Services (CDS)

CDS serves as the ubiquitous modeling language to declare domain data models.

Enterprise Application Infrastructure

The Enterprise Application Infrastructure offers:

• Powerful service runtime frameworks
• First-class support for SAP Fiori and SAP HANA
• Out-of-the-box implementations
• Draft support for SAP Fiori UIs
• Built-in extensibility capabilities

OData

A standardized protocol for defining and consuming data.

Service Consumption

RAP supports user interface (UI) development, either based on SAP Fiori elements or as freestyle SAPUI5 development. It also supports service consumption via Web APIs.

The ABAP RAP model represents the latest evolution of ABAP programming:

• It maintains backward compatibility with earlier ABAP models, protecting previous investments in ABAP codebase and infrastructure.
• RAP introduces cutting-edge features essential for building RESTful enterprise-grade applications optimized for modern cloud and hybrid environments.

ABAP Development Tools (ADT) is the successor of the ABAP Workbench. ADT provides the following features:

• A completely new ABAP development experience on top of the Eclipse platform
• An open platform for developing new ABAP-related tools
• A set of open, language-independent, and platform-independent APIs that developers can use to build new custom tools for the ABAP environment

An ABAP project serves as a container for the development objects that are stored in a particular ABAP back-end system and contains the logon parameters for the system logon: system, client, user, and language. You must be logged on to the system to edit an object. Within the ABAP project, you can access any development object in the repository. In addition, to make it easier to manage objects, you can set up favorite packages for each project.

To create a new repository object in ADT, right-click the project in the project explorer and choose New→ABAP Repository Object.... In the following dialog box, you can search for the type of repository object you want to create.

To create a copy of an existing repository object, right-click the source object in the Project Explorer and choose Duplicate....

To open a specific repository object in its respective editor, double-click it. The editor is shown on the right side of the ABAP perspective.

Applications that are developed with the ABAP RESTful Application Programming Model consist of the following building-blocks:

Business Objects

Business objects (BOs) represent the data model and define the data-related logic, called behavior, independent of specific consumption. RAP business objects are defined through CDS data modeling views, CDS behavior definitions, and behavior implementations in ABAP classes.

Business Object Interface

A BO interface provides stable access to the functionality of a business object. If developers want to make a business object available for reuse in other development projects, they define and release a BO Interface. In RAP, a BO Interface consists of CDS projection views and a CDS Behavior interface.

Note

Interface-specific behavior implementations are not supported.

Business Object Projections

The BO projection is an approach to project and alias a subset of the business object for a specific business service. The projection enables flexible service consumption and role-based service designs. In RAP, a BO projection consists of CDS projection views, a CDS behavior projection, and, if needed, additional or consumption-specific behavior implementations.

Note

If the BO projection reuses an existing BO from another development project, it is built on top of the stable BO interface. If the business object and the BO projection belong to the same development project, the BO projection can access the business object directly. In this case, a BO interface is not needed.

Service Definition

A service definition defines the scope of a business service, in particular, the BO projection to be exposed via this service.

Service Binding

A service binding defines the communication protocol such as OData V2 or OData V4 and the kind of service to be offered for a consumer, such as UI services or Web APIs. Typical consumers for UI services are SAP Fiori UIs. Web APIs can be accessed by any other clients.

Business Events

A RAP business event usually represents a piece of information about the outcome of a modifying operation, such as create, update, delete. Then, an interested party that has subscribed to this event can consume and process it. It is always possible to handle RAP business events locally, that is, in the same system. To make business events visible for external event handlers, they need to be exposed through event bindings.

A business object (BO) represents an entity of the data model. A RAP BO can either consist of a single node (Simple BO) or of a hierarchy of nodes (Composite BO). An example for a Composite BO is a document that consists of a header (root node) and items (child node).

The behavior of a BO defines operations that can be executed on the data, for example the standard operations Create, Update, Delete (CRUD), but also specific actions and functions.

It also provides feature control (for example, the definition which data is mandatory and which is read-only), concurrency control (for example, the handling of locks), and authorization control.

In the context of the ABAP RESTful application programming model, a business service is a RESTful service that can be called by a consumer. It is defined by exposing its data model together with the associated behavior. It consists of a service definition and a service binding.

The service definition is a projection of the data model and the related behavior to be exposed, whereas the service binding defines a specific communication protocol, such as OData V2 or OData V4, and the kind of service to be offered for a consumer. This separation allows the data models and service definitions to be integrated into various communication protocols without the need for reimplementation.

Developing a RAP application consists of the following main steps:

1. Provide Database Tables

   Developing a RAP application starts with providing the database tables. Depending on the development scenario, these can be existing tables, legacy tables, or tables created specifically for this application.

2. Define the Data Model

   The data model of the Business Object is defined with CDS Views. Depending on whether it is a simple or a composite BO, one or more CDS Views are required. In case of a composite BO, this is also the place where you define the entity hierarchy.

3. Define and Implement the Behavior (Transactional apps only)

   The behavior of a RAP BO is defined in a repository object called CDS Behavior Definition. Usually, the behavior of a RAP BO also requires some additional logic which is implemented in a certain type of global ABAP class, called a Behavior Pool. For a non-transactional application, for example, a list report, the behavior definition or implementation can be omitted.

4. Project the RAP Business Object and provide service specific Metadata

   The projection of the RAP BO consists of a data model projection, and, if a behavior has been defined, a behavior projection. To define a projection, you create one or more CDS projection views, a type of CDS View, and a Behavior Projection, a type of behavior definition. For UI services, the projection view(s) can be enriched with UI-specific metadata. To support future extensibility of the application, we recommend placing the service-specific annotations in metadata extensions.

5. Define the Service

   In RAP, a service is defined by creating a Service Definition. The service definition references the projection views and specifies which of them can be exposed, that is, which of them are visible for the service consumer.

6. Bind the Service and Test the Service

   To specify how the service can be consumed (UI or Web API) and via which protocol (OData V2 or OData V4), a service binding is needed. For UI services, a Preview is available.

When expanding the content of an ABAP Development Package in the Project Explorer of ADT, the repository objects are found in different categories of repository objects.

The database tables, along with the included structures, data elements, and domains needed for their definition, are found in the category Dictionary.

The repository objects defining the data model, interface, and projection views, are found in the Core Data Services→Data Definitions node. According to the recommended naming pattern, the data model views can have a letter "R" (for Restricted), the projection views for the interface a letter "I" (for Interface), and the projection views for the projection a letter "C" (for Consumption).

The repository objects for the definition and projection of the RAP BO behavior are located in Core Data Services→Behavior Definitions. Again, the letters "R", "I", and "C" can help to distinguish between repository objects for definition, interface, and projection.

Service Definitions and Service Bindings have their dedicated subnodes under the Business Services category.

The Behavior Implementation is done in behavior pools, which are global ABAP classes that fulfill certain requirements. Like all global ABAP classes, they can be found in Source Code Library→Classes. To make behavior pools distinguishable from other ABAP classes, the naming pattern requests their names to start with "BP_" or "<namespace>BP_" instead of the usual "CL_" or "<namespace>CL_" for ordinary ABAP classes.

The Business Scenario in this course is based on the flight data model, which has been used in ABAP documentation and training for many years.

For this course, we introduce new entities to the model, Flight Travel that a customer books at a Travel Agency. The Flight Travel consists of several Travel Items, for example bookings on several flights (a flight and a return flight or a flight and a connecting flight).

To make things easier, we start with Flight Travel as a simple BO that is not composite. Later in the course, we introduce the Travel Agency.

The outline of the course is as given below:

1. Step 1 – Read-Only App (Package /LRN/S4D437_SOLUTION_A)
   • OData UI Service for non-transactional app
   • Data Model, Projection, and Business service
2. Step 2 – Transactional App with Action (Package /LRN/S4D437_SOLUTION_B)
   • Behavior (definition, implementation, projection)
   • Concurrency control and authorization control
3. Step 3 – EnableDirectEditing(Package /LRN/S4D437_SOLUTION_C)
   • Update and create operations (managed)
   • Value helps, Input checks, dynamic default values, dynamic feature control
4. Step 4 – Draft-Enabled App (Package /LRN/S4D437_SOLUTION_D)

   Draft-Enable the Business Object

5. Step 5 – Composition(Package /LRN/S4D437_SOLUTION_E)

   Add child entity Travel Item

6. Step 6 – Unmanaged Save (Package /LRN/S4D437_SOLUTION_F)

   Reuse existing code to persist Travel Items on the database

7. Step 7 – Business Events (Package /LRN/S4D437_SOLUTION_G)

   Raise and handle a Business Event TravelCreated

8. Step 8 – Extensions (Package /LRN/S4D437_SOLUTION_H)
   • Enable extensibility
   • Extend Travel Items with a field for the booking class

We use the ABAP RESTful application programming model (RAP) to build an OData UI service for Flight Travels and preview the OData UI Service in a generated app that is based on the List Report Floorplan of SAP Fiori elements.

First, we develop an OData Service for a non-transactional, read-only app that displays a list and a detail page for flight travels.

Then, we add behavior to the business object, namely an action that the user can execute by pressing a button on the UI. We add concurrency control and authorization control to ensure data consistency and make sure that users only cancel travels for which they have the required authorization.

Next, we enable direct editing by the user. We discuss value helps, implement input checks, provide dynamic default values, and we discuss how to enable or disable editing dynamically.

In a next step, we enable draft-handling, so that the users of the app can interrupt and resume editing and don't lose their work in case of network failures.

By introducing a child entity Travel Item, we turn our simple business object into a composite business object. At first, we let the framework write the travel items to the database. Then we extend the BO with an unmanaged save implementation to reuse existing code for this purpose.

As an example for the raising and handling of Business Events in RAP, we let the BO raise an event TravelCreated whenever a new travel instance is created.

Finally, we make our app extensible and illustrate how it can be used to extend the Travel Items with a field for the booking class.

To define the data model, we create a database table and a CDS View entity.