Explain RAP (RESTful ABAP Programming Model) in SAP

33 / 65

S/4HANAadvanced

RAP (RESTful ABAP Programming Model)

SAP's strategic, HANA-optimized model for building transactional business objects and Fiori/OData services in S/4HANA Cloud and on-premise.

RAP is how transactional apps are built in S/4HANA today. It replaces BOPF and the practice of writing business logic inside function modules.

RAP is like a well-defined assembly line for building furniture (business objects) with mandatory quality checkpoints (validations, determinations) at fixed stations, versus the old approach of a single craftsperson (a BAPI function module) building the whole piece by hand with no enforced checkpoints - RAP's managed mode is like using the factory's standard automated frame and finish; unmanaged mode is bringing your own custom frame but still running it through the factory's checkpoint stations.

Key Concepts

A business object is assembled from three artefacts.

    CDS data model        what the object is -- interface and projection views
    behavior definition   what may be done to it
    behavior implementation  the logic, in ABAP classes

    define behavior for ZI_Travel alias Travel
    persistent table ztravel
    lock master
    {
      create; update; delete;
      field ( readonly ) TravelId;
      field ( mandatory ) CustomerId;
      action acceptTravel result [1] $self;
      validation checkDates on save { field BeginDate, EndDate; }
      determination setStatus on modify { create; }
    }

The structure is the point. In a classic BAPI, validation, defaulting and persistence are wherever the developer put them. RAP names those phases and fires them at defined moments:

    determination   sets a value when something changes
                    -- "status becomes OPEN when the record is created"
    validation      refuses a save when a rule is broken
                    -- "end date must be after begin date"
    action          an operation beyond create/update/delete
                    -- "accept this travel request"

So anyone reading a behaviour definition can see every rule that applies, without reading the implementation.

Managed or unmanaged, and the choice is about persistence.

    managed     RAP generates the save logic. For a new object over
                a table you control.
    unmanaged   you write the save sequence yourself. For wrapping
                existing tables and legacy logic that does not fit
                RAP's assumptions.

Greenfield work is managed. Wrapping a twenty-year-old posting routine is unmanaged.

Draft handling is a first-class feature, and it is why Fiori feels different. A user fills in half a form, leaves, and comes back tomorrow to finish it.

That requires storing an incomplete record that does not yet satisfy the object's own rules. RAP does it with a companion draft table: drafts are saved without validation, and validations run when the draft is activated into a real record.

Building that by hand is substantial work, which is why it is the part of RAP people underestimate.

The service comes free. A service definition and service binding expose the business object as OData V2 or V4, with no integration code:

    behavior + CDS  ->  service definition  ->  service binding  ->  OData

And because Fiori Elements generates its screen from the same CDS annotations, a working app follows from the same artefacts. That is why RAP, CDS and Fiori are always discussed together.

Testing. RAP business logic is tested with ABAP Unit using RAP's test double framework, which simulates the transactional buffer so validations and determinations can be tested without touching the database. In S/4HANA Cloud that is not optional — there is no debugging in production.

What the interviewer is probing.1. "What is the difference between managed and unmanaged RAP?" Probing: the central choice. Stalls: "Nothing much." Moves up: managed lets the framework handle persistence for greenfield objects; unmanaged lets you wire existing business logic and tables behind the same interface.

2. "What is a behaviour definition for?" Probing: the structure. Stalls: "Validation." Moves up: declaring which operations, validations, determinations and actions the entity supports, separately from the data model.

3. "How does RAP relate to BOPF and the old models?" Probing: currency. Stalls: "They are the same." Moves up: it is the successor — BOPF and the older OData-by-hand approach are legacy, and RAP generates the OData service from the CDS model.

4. "What is a draft in RAP?" Probing: the Fiori connection. Stalls: "A saved record." *Moves up:* framework-managed intermediate storage so a user can leave an unfinished object and return, which is what Fiori draft-enabled apps rely on.