ABAP RAP

ABAP RESTful Application Programming Model

Overview of Web Applications

Evolution of Programming Models

Representation of the different versions and approaches of OData development with ABAP from the beginning until today

Goals of RAP

  • Simple development with focus on application logic — keyword "development efficiency"
  • All standard features should be built-in or require minimal manual effort:
    • CRUD operators
    • User interfaces
    • Locking
    • Authorization checks
    • DRAFT handling
    • Number assignment
  • Clear program flow — what happens and when
  • Integration with DDic and CDS
  • Extensibility
  • Use of SAP technologies
    • SAP HANA
    • FIORI
    • BTP-Enabled

REST

Stateless (web) applications. Each request or response contains all relevant information for server or client.

The server does not store a session, as was the case with e.g. WebDynpro

This also means every navigation in the browser can be bookmarked, because all information is contained in the URL.

OData

For transferring application data, RAP defines services that use the OData protocol.

As RAP developers we typically do not work directly with the OData protocol!

You can think of OData as SQL for REST

OData provides

  • Metadata
    • What object types exist?
    • Which attributes do they have?
    • How can we navigate between object types?
  • Application data — can be queried via URL
    • Lists of object instances — all or filtered/searched
    • Single object instances — by key
  • Annotations — additional information for presentation
    • Which fields are filterable?
    • Where does the value help (value help) come from?

Fiori Elements

Backend-driven UIs controlled by annotations. Either as a few floorplans in standalone apps (as in RAP) or as components in hand-built UI5 apps.

  • Generates UIs based on OData services and metadata (e.g., CDS annotations).
  • Focus on reusability and consistent UX design.

Typical floorplans:

List Report

List Report

Object Page

List Report

Architecture Overview

ABAP Platform Architecture

What is a Business Object (BO)

Business Object

  • Definition:
    • A Business Object (BO) is a central entity in the SAP Restful ABAP Programming Model (RAP) that models a business concept or process (e.g., sales order, inquiry).
  • Components:
    • Data model: Structure of the data, e.g., tables and views.
    • Behavior: Business logic, e.g., actions, validations and authorization checks.
    • Service: Binds the BO to a protocol and defines which parts of the BO are exposed.
    • Transaction management: Management of changes in the context of the SAP LUW (logical unit of work).

Naming convention for multi-layered CDS views

In SAP RAP, CDS views and behavior definitions are divided into several layers (as in the virtual data model) to provide a clear separation of responsibilities and better maintainability:

Lowest level: I_ Interface View

The I-view delivers data of the business object for different frameworks. Responsibilities of this layer:

  • Rename fields
  • General annotations, e.g., currencies, semantics, ...

Middle level: R_ Reuse View

  • RAP-specific — data modeling of the business object, the full set of data

Top level: C_ Consumption View

The C-view is a specialized projection of the business object for a specific consumption scenario.

In our exercises we initially limit ourselves to a single layer to keep things simpler.

Naming conventions in this training

SAP documentation on RAP.

A good <Name>

The suffixes _R, _M, _D, _U, _C from the SAP docs are not strictly necessary in the real world, because scenarios (read-only, managed, draft, unmanaged, service consumption) can be implemented on the same tables.

If you use a prefix namespace, use that instead of a leading Z prefix.

Naming conventions — object types

Object type Convention Description
DB table Z_<Name> Application table
DB table Z_<Name>_D Draft table
CDS View ZI_<Name> Interface View
CDS View ZR_<Name> Reuse View
CDS View ZC_<Name> Projection View for the Consumption layer
Behaviour Definition As the associated CDS View
Service Definition Z_<Name>
Service Binding ZUI_<Name> For UI services
Service Binding ZAPI_<Name> For API services
ABAP Class ZBP_<Name> Class for the behaviour pool
Local Class LHC_ Local handler class
Local Class LSC_ Local saver class

Links