Everything you have learned so far has been leading to this. CDS Views gave you the data model. Behavior Definitions give you the business logic. Service Bindings expose it to the world. And the result is a complete, transactional, cloud-ready SAP application.

This is RAP — the RESTful ABAP Programming Model. It is the standard for all new SAP development on S/4HANA and BTP. If you have been building classic ABAP for years, this is the chapter that changes how you build applications. If you are new to ABAP, this is your foundation for the future.

🎯 What You Will Learn in This Chapter

• What RAP is and why it replaced classic ABAP application development
• The RAP architecture: Business Objects, CDS Views, Behavior, and Services
• The difference between Managed and Unmanaged RAP
• How to define a Behavior Definition (BDEF)
• How to implement Behavior Implementation classes
• What EML (Entity Manipulation Language) is and how to use it
• How Draft Handling works with the dual-table architecture
• How to expose a RAP business object via Service Definition and Service Binding
• The full RAP development flow from database table to Fiori app

📘 What is RAP?

RAP stands for RESTful ABAP Programming Model. It is SAP’s modern framework for building transactional, cloud-ready applications on SAP S/4HANA and SAP BTP.

Before RAP, building a transactional SAP application meant:

• Writing a custom screen (or Fiori app) separately
• Writing a report or function module for the logic
• Writing your own authorization checks
• Writing your own error handling
• Duplicating code across multiple entry points

RAP replaces all of this with a single, model-driven approach. You define a Business Object — and the framework handles the rest.

Why RAP matters in 2026

🏗️ RAP Architecture — The Layers

RAP has four main layers. Understanding them is the key to understanding RAP.

⚖️ Managed vs Unmanaged RAP

This is the most important decision you make when starting a RAP project. It affects everything that follows.

📜 Behavior Definition (BDEF) — The Contract

A Behavior Definition is a file that declares what a RAP business object can do. It is written in a domain-specific language and lives alongside your CDS Views in Eclipse ADT.

What a BDEF declares

• Implementation type — Managed or Unmanaged
• Operations — Create, Update, Delete, Read
• Validations — Rules that must pass before saving
• Determinations — Automatic logic that runs when data changes
• Actions — Custom operations (approve, cancel, etc.)
• Draft handling — Whether drafts are enabled
• Authorization — How permissions are checked
• Field mappings — Which fields map to which table columns

A minimal Managed BDEF

managed implementation in class ZBP_TRAVEL unique;

define behavior for ZI_Travel
persistent table /dmo/travel
lock master
etag master LastChangedAt
authorization master ( global )
draft table /dmo/travel_d
{
  create;
  update;
  delete;

  field ( readonly ) TravelId;

  validation validateDates on save { field BeginDate, EndDate; }
  determination setStatus on modify { field Status; }
}

Breaking it down

⚙️ Behavior Implementation — The Logic

The Behavior Implementation is an ABAP class (conventionally named ZBP_*) that implements the methods declared in the BDEF. In Managed RAP, you only implement validations, determinations, actions, and authorization — never CRUD.

The class skeleton

CLASS zbp_travel DEFINITION
  PUBLIC FINAL CREATE PUBLIC.

  PUBLIC SECTION.
    INTERFACES if_abap_behv_message.
    INTERFACES if_abap_behavior_handler.

  PRIVATE SECTION.
    METHODS validateDates FOR VALIDATE ON SAVE
      IMPORTING keys FOR Travel~validateDates.

    METHODS setStatus FOR DETERMINE ON MODIFY
      IMPORTING keys FOR Travel~setStatus.
ENDCLASS.

Implementing a validation

CLASS zbp_travel IMPLEMENTATION.

  METHOD validateDates.
    " Read the affected entities
    READ ENTITIES OF zi_travel IN LOCAL MODE
      ENTITY Travel
        FIELDS ( BeginDate EndDate )
        WITH CORRESPONDING #( keys )
      RESULT DATA(lt_travel).

    LOOP AT lt_travel INTO DATA(ls_travel).
      IF ls_travel-EndDate < ls_travel-BeginDate.
        APPEND VALUE #( %tky = ls_travel-%tky ) TO failed-travel.

        APPEND VALUE #(
          %tky        = ls_travel-%tky
          %msg        = new_message_with_text(
                          severity = if_abap_behv_message=>severity-error
                          text     = 'End date cannot be before begin date' )
          %element-BeginDate = if_abap_behv=>mk-on
        ) TO reported-travel.
      ENDIF.
    ENDLOOP.
  ENDMETHOD.

  METHOD setStatus.
    " Determinations run automatically when data changes
    MODIFY ENTITIES OF zi_travel IN LOCAL MODE
      ENTITY Travel
        UPDATE FIELDS ( Status )
        WITH VALUE #( FOR key IN keys
                      ( %tky   = key-%tky
                        Status = 'N' ) ).    " N = New
  ENDMETHOD.

ENDCLASS.

🔧 EML — Entity Manipulation Language

EML is how you interact with RAP business objects from ABAP code. It is an extension of the ABAP language and enforces all BDEF logic (validations, authorizations, determinations) automatically.

The four core EML statements

READ ENTITIES example

READ ENTITIES OF zi_travel
  ENTITY Travel
    ALL FIELDS
    WITH VALUE #( ( TravelId = '00000001' ) )
  RESULT DATA(lt_travel)
  FAILED DATA(ls_failed)
  REPORTED DATA(ls_reported).

LOOP AT lt_travel INTO DATA(ls_travel).
  WRITE: / ls_travel-TravelId, ls_travel-Description.
ENDLOOP.

MODIFY ENTITIES example (Create)

MODIFY ENTITIES OF zi_travel
  ENTITY Travel
    CREATE FIELDS ( Description BeginDate EndDate )
    WITH VALUE #( (
      %cid        = 'CID_1'
      Description = 'Business Trip to Berlin'
      BeginDate   = '20260401'
      EndDate     = '20260405' ) )
  MAPPED   DATA(ls_mapped)
  FAILED   DATA(ls_failed)
  REPORTED DATA(ls_reported).

" Always commit after modify
COMMIT ENTITIES
  RESPONSE OF zi_travel
  FAILED   DATA(ls_commit_failed)
  REPORTED DATA(ls_commit_reported).

MODIFY ENTITIES example (Update)

MODIFY ENTITIES OF zi_travel
  ENTITY Travel
    UPDATE FIELDS ( Description )
    WITH VALUE #( (
      TravelId    = '00000001'
      Description = 'Updated description' ) )
  FAILED   DATA(ls_failed)
  REPORTED DATA(ls_reported).

COMMIT ENTITIES.

EXECUTE ACTION example

EXECUTE ACTION acceptTravel
  ENTITY Travel
  FROM VALUE #( ( TravelId = '00000001' ) )
  FAILED   DATA(ls_failed)
  REPORTED DATA(ls_reported).

COMMIT ENTITIES.

📝 Draft Handling — The Dual-Table Architecture

Draft Handling lets users save incomplete work without triggering full business rules. It uses two tables.

The draft lifecycle

Draft-aware BDEF additions

define behavior for ZI_Travel
persistent table /dmo/travel
draft table /dmo/travel_d
lock master
etag master LastChangedAt
{
  create;
  update;
  delete;

  draft actions
  {
    Edit;
    Activate;
    Discard;
    Resume;
  }

  validation validateDates on save { field BeginDate, EndDate; }
}

🌐 Service Definition & Service Binding

Once your business object is complete, you expose it as an OData service.

Service Definition

A Service Definition declares which entities are exposed.

@EndUserText.label: 'Travel Service'
define service ZUI_TRAVEL_O4 {
  expose ZC_Travel as Travel;
}

• ZC_Travel is the projection/consumption CDS view (not the interface view).
• expose ... as ... gives the entity an external name.

Service Binding

A Service Binding turns the Service Definition into a runtime endpoint.

Preview

Once published, click Preview in Eclipse ADT to open the Fiori Elements app. You get:

• List report with filters
• Object page with details
• Create / Edit / Delete buttons
• Draft handling (Save, Activate, Discard)
• All validations and actions wired up

Without writing a single line of UI code.

🧭 The Complete RAP Development Flow

Here is the full sequence from scratch to a working Fiori app.

Naming conventions (standard)

⚠️ Common Pitfalls