ABAP RESTful Application Programming Model (RAP)

What is RAP?

The ABAP RESTful Application Programming Model (in short RAP) defines the architecture for efficient end-to-end development of intrinsically SAP HANA-optimized OData services (such as Fiori apps) in SAP BTP ABAP Environment or Application Server ABAP. It supports the development of all types of Fiori applications as well as publishing Web APIs. It is based on technologies and frameworks such as Core Data Services (CDS) for defining semantically rich data models and a service model infrastructure for creating OData services with bindings to an OData protocol and ABAP-based application services for custom logic and SAPUI5-based user interfaces – as shown in the figure below.

RAP Big Picture

Provide a programming model…

• As a strategic long-term solution for ABAP development
• For the efficient development of
  • SAP Fiori apps and Web APIs,
  • from scratch or by integrating legacy code
• Offering an end-to-end development experience with
  • High development efficiency
  • Standardized development flow
  • Best practices and development guides
  • Focus on business logic, rather than technical aspects
  • Native testability, documentability, and supportability
  • Code pushdown to SAP HANA
  • Comfortable support for stateless and stateful environments
• Supporting the product qualities
  • User experience: SAP Fiori and SAP HANA
  • Cloud: scalability
  • Out-of-the-box extensibility and verticalization
  • Flexibility: break-outs for nonstandardized implementations

Developer Ressorces

A good starting point is the Getting Started blog, and the TechEd2020 DEV260 session Build SAP Fiori Apps with the ABAP RESTful Application Programming Model, see also the related DEV260.pdf overview.

Concepts

The ABAP RESTful Programming Model has unified the development of OData services with ABAP. It is based on three pillars that facilitate your development:

Pillar	Description
Tools	The approach to integrate all implementation tasks in one development environment optimizes the development flow and offers an end-to-end experience in one tool environment. New development artifacts support the application developer to develop in a standardized way.
Language	The ABAP language has been aligned and extended to support the development with the ABAP RESTful Programming Model, together with CDS. The application developer uses typed APIs for standard implementation tasks and benefits from auto-completion, element information, and static code checks.
Frameworks	Powerful frameworks represent another important pillar of the ABAP RESTful Programming Model. They assume standard implementation tasks with options for the application developer to use dedicated code exits for application-specific business logic.

Runtime

The following diagram provides a runtime perspective of the ABAP RESTful Programming Model. Runtime objects are necessary components to run an application. This runtime stack is illustrated in a top-down approach. An OData client sends a request, which is then passed to the generic runtime frameworks. These frameworks prepare a consumable request for ABAP code and dispatch it to the relevant business logic component. The request is executed by the business object (BO) when data is modified or by the query if data is only read from the data source.

RAP Runtime

Data Model and Behavior

Data Model

The data model comprises the description of the different entities involved in a business scenario, for example travel and booking, and their relationships, for example the parent-child relationship between travel and booking. The ABAP RESTful Programming Model uses CDS to define and organize the data model. CDS provides a framework for defining and consuming semantic data models. These data models have a physical representation in the database in the form of database views which are automatically created based on a CDS data model. Every real-world entity is represented by one CDS entity. View building capabilities allow you to define application-specific characteristics in the data model. That means, CDS entities are the fundamental building blocks for your application. When using the CDS entity for a data selection, the data access is executed by the SQL-view, which is defined in the CDS entity.

Depending on the use case, data models support transactional access or query access to the database. Thus, data models are used in business objects or queries respectively.

The following diagram gives you an overview of the data model that is used in the development guides of this documentation. Every block refers to one database table view and the respective CDS entity. The blue boxes represent a Travel business object, with its child entities Booking and Booking Supplement. The white boxes represent the entities that are not part of the business object, but support with value helps or text associations. For read-only access to the database, that is simple data retrieval, the data model is used for the query.

RAP Data Model

PlantUML

 

Behavior

The behavior describes what can be done with the data model, for example if the data can be updated.

In transactional scenarios, the business object behavior defines which operations and what characteristics belong to a business object. For read-only scenarios, the behavior of the data model is defined by the query capabilities, for example if the data is filterable.

Query

A query is the connecting interface for read-only access to the database in OData services. It is used for list reports or analytical reports to process data.

As the non-transactional counterpart of a business object, it consists of a data model, generic and modeled query capabilities and a runtime. This threefold division is known from the BO concept. However, a query provides only read access to the database. Its runtime never modifies data, but only executes structured data retrieval, for example for filtering.

Business Object

A business object (BO) is a common term to represent a real-world artifact in enterprise application development such as the Product, the Travel, or the SalesOrder. In general, a business object contains several nodes such as Items and ScheduleLines and common transactional operations such as for creating, updating and deleting business data. An additional application-specific operation in the SalesOrder business object might be, for example, an Approve action allowing the user to approve the sales order. All changing operations for all application-related business objects form the transactional behavior in an application scenario.

Business Service

The ABAP development platform can act in the roles of a service provider and a service consumer (such as SAP Fiori UI client).

In the context of the ABAP RESTful application programming model, a business service is a RESTful service which 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.

RAP Business Services

How to Use BO Projections?

The design time artifacts to create an OData service that includes a projection layer are the following:

RAP BO Projections

Naming Conventions for Development Objects

Naming conventions facilitate the development. An addition to the name of development objects conveys standardized meaning and generates consistency in your development.

General Rules

Remember

The general guideline for development objects is the following: [/<namespace>/][<prefix>]_<object_name>_[<suffix>].

• Use your own namespace that is reserved for your organization.
• A prefix is used for cases when there are generically different types of one development object. Then, this prefix states the semantic difference that cannot be conveyed through the object type. For example, a service binding can expose an OData service for UI purposes and as a Web API. That is why, for service bindings we introduce the prefixes UI_ and API_ to differentiate the semantics of service bindings.
• A suffix is used for additional differentiation between different types of development objects. It helps to recognize more subtle or secondary differences in development objects. For example, a UI service can be bound against the OData protocol version 2 and version 4. This difference can also be manifested by suffixing the name with _O2 or _O4.

Special Suffixes (_R, _M, _D, _U, _C)

This characters identifies the development object to belong to one specific development guide (read-only, managed, draft, unmanaged, service consumption).

The following list provides an overview of the prefixing and suffixing guidelines on naming specific development objects.

ABAP Dictionary Objects

Object	Prefix	Description	Example
Database Table	A_	Persistent database table, that contains the active data	/UDINA/A_TRAVEL_D
Database Table	D_	Draft database table	/UDINA/D_TRAVEL_D
SQL View	I	SQL views of CDS interface views (without underscore)	/UDINA/ITRAVEL_U

CDS Objects

Object	Prefix	Description	Example
CDS Entity	I_	Interface view	/UDINA/I_Travel_U
CDS Entity	C_	Projection view	/UDINA/C_Travel_Processor_M
Behavior Definition		A behavior definition has always the same name as the root entity of the business object.	/UDINA/I_Travel_U /UDINA/C_Travel_M
Metadata Extension		A metadata extension has the same name as the CDS entity it relates to. If you use more than one metadata extension for one CDS entity, you can add a numbered suffix	/UDINA/C_TRAVEL_U /UDINA/C_BOOKING_U_M2

Business Services

Service Definition

Since a service definition, as a part of a business service, does not have different types or different specifications, there is (in general) no need for a prefix or suffix to differentiate meaning.

Example: /UDINA/TRAVEL_U

However, in use cases where no reuse of the same service definition is planned for UI and API services, the prefix may follow the rules of the service binding.

Example: /UDINA/UI_TRAVEL_U

Service Binding

Use the suffix _O2 or _O4 concerning the used OData protocol version.

Object	Prefix	Description	Example
Service Binding	UI_	Service is exposed as a UI service	/UDINA/UI_TRAVEL_U_O2
Service Binding	API_	Service is exposed as Web API	/UDINA/API_TRAVEL_U_O4

Source Code Objects

Depending on the modularization of your behavior implementation, you can provide the semantics of the coding in the name of the classes (ex. CRUD, CUD or CREATE).

Object	Prefix	Description	Example
Behavior Pool	BP_	ABAP class that implements the behavior of a business object	/UDINA/BP_TRAVEL_U
Handler Classes	LHC_	Local handler class	/UDINA/LHC_TRAVEL_CREATE
Saver Classes	LSC_	Local saver class	/UDINA/LSC_TRAVEL_CUD

Required skillset

It is also helpful to have knowledge of both SAP and open technologies when designing the overall architecture.

Skill	Description
Platform	SAP NetWeaver and SAP Cloud Platform ABAP Environment
Dev. Language	ABAP
Database	SAP HANA
UI	SAP Fiori Elements, SAPUI5
Dev. Framework	ABAP CDS, Exit, BAdI, Key User Extensibility
API	OData, REST, (SOAP, BAPI)
DevOps	TMS, ABAP Workbench, gCTS
IDE	ABAP Workbench, ABAP Development Tools (ADT) , Business Application Studio, VS Code)