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.
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.
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.
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.
How to Use BO Projections?
The design time artifacts to create an OData service that includes a projection layer are the following:
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) |