In Chapter 17, you built a RAP business object. You created CDS Views, a Behavior Definition, and a Service Binding. But a business object that only reads data is a snapshot — not a living application.

Real business objects need behavior. Users should be able to create records. Data should be validated before saving. Fields should be filled automatically. Business actions like “Approve” or “Cancel” should be triggered by the click of a button.

This chapter teaches you the three pillars of RAP behavior: EML (how to manipulate data), Validations (how to check it), and Determinations (how to shape it automatically). Together, these turn a static model into a real SAP application.

🎯 What You Will Learn in This Chapter

• What EML is and how it differs from Open SQL
• How to use READ ENTITIES, MODIFY ENTITIES, and COMMIT ENTITIES
• What the REPORTED and FAILED parameters do
• How to write and register a Validation in a RAP business object
• How to write and register a Determination
• How to implement Actions (custom business operations)
• Understanding when to use Validation vs Determination vs Action
• How RAP handles errors, messages, and transactions

📘 What is EML?

EML stands for Entity Manipulation Language. It is a specialized ABAP syntax for interacting with RAP business objects — reading, creating, updating, deleting, and calling actions.

You can think of EML as the RAP counterpart of Open SQL. But while Open SQL talks directly to the database, EML talks to the business object — which means the framework enforces validations, determinations, authorizations, and transactional consistency automatically.

The main EML statements

📖 READ ENTITIES — Reading Business Object Data

Use READ ENTITIES to read data from the business object. This ensures the framework applies authorizations correctly.

Basic READ ENTITIES

DATA: lt_keys   TYPE TABLE FOR READ IMPORT ZI_Travel,
      lt_travel TYPE TABLE FOR READ RESULT ZI_Travel.

" 1. Prepare the keys
lt_keys = VALUE #( ( TravelId = '00000001' )
                ( TravelId = '00000002' ) ).

" 2. Read the entities
READ ENTITIES OF ZI_Travel IN LOCAL MODE
  ENTITY Travel
    ALL FIELDS WITH CORRESPONDING #( %key )
    WITH lt_keys
  RESULT lt_travel
  FAILED DATA(lt_failed)
  REPORTED DATA(lt_reported).

" 3. Use the result
LOOP AT lt_travel INTO DATA(ls_travel).
  WRITE: / ls_travel-TravelId, ls_travel-TotalPrice.
ENDLOOP.

✏️ MODIFY ENTITIES — Creating, Updating, Deleting

Use MODIFY ENTITIES to change data. In a Managed RAP scenario, the framework handles the persistence automatically — you provide the data, and it takes care of the database.

Create a new record

DATA: lt_create TYPE TABLE FOR CREATE ZI_Travel.

" 1. Prepare the new entity data
lt_create = VALUE #(
  ( %cid         = 'CID_1'
    TravelId     = '00000099'
    AgencyId     = '070001'
    CustomerId   = '000077'
    BeginDate    = '20260501'
    EndDate      = '20260510'
    TotalPrice   = '1200.00'
    CurrencyCode = 'USD'
  ) ).

" 2. Execute the create
MODIFY ENTITIES OF ZI_Travel IN LOCAL MODE
  ENTITY Travel
    CREATE FIELDS ( TravelId AgencyId CustomerId
                   BeginDate EndDate TotalPrice CurrencyCode )
    WITH lt_create
  MAPPED   DATA(lt_mapped)
  FAILED   DATA(lt_failed)
  REPORTED DATA(lt_reported).

Update an existing record

DATA: lt_update TYPE TABLE FOR UPDATE ZI_Travel.

lt_update = VALUE #(
  ( TravelId   = '00000099'
    TotalPrice = '1500.00' ) ).

MODIFY ENTITIES OF ZI_Travel IN LOCAL MODE
  ENTITY Travel
    UPDATE FIELDS ( TotalPrice )
    WITH lt_update
  FAILED   DATA(lt_failed)
  REPORTED DATA(lt_reported).

Delete a record

DATA: lt_delete TYPE TABLE FOR DELETE ZI_Travel.

lt_delete = VALUE #( ( TravelId = '00000099' ) ).

MODIFY ENTITIES OF ZI_Travel IN LOCAL MODE
  ENTITY Travel
    DELETE FROM lt_delete
  FAILED   DATA(lt_failed)
  REPORTED DATA(lt_reported).

💾 COMMIT ENTITIES, REPORTED, and FAILED

COMMIT ENTITIES

After a MODIFY ENTITIES call, the changes are held in the transactional buffer. They are not yet in the database. You must call COMMIT ENTITIES to save them.

" Check for errors first
IF lt_failed IS INITIAL.
  " No failures — commit
  COMMIT ENTITIES
    RESPONSE OF ZI_Travel
      FAILED   DATA(lt_commit_failed)
      REPORTED DATA(lt_commit_reported).

  IF lt_commit_failed IS INITIAL.
    MESSAGE 'Changes saved successfully' TYPE 'S'.
  ENDIF.
ELSE.
  " Handle errors
  LOOP AT lt_reported INTO DATA(ls_rep) WHERE %msg->severity = 'E'.
    MESSAGE ls_rep-%msg TYPE 'E'.
  ENDLOOP.

  " Explicit rollback (optional — happens automatically if you exit)
  ROLLBACK ENTITIES.
ENDIF.

REPORTED and FAILED — the diagnostic pair

✅ Validations — Checking Data Before Save

A Validation is a rule that checks data before saving. If the rule fails, the framework returns an error and blocks the save.

Step 1 — Declare the validation in the BDEF

validation validateDates on save
  { field BeginDate, EndDate; }

Step 2 — Implement the validation method

METHOD validateDates.
  READ ENTITIES OF ZI_Travel IN LOCAL MODE
    ENTITY Travel
      FIELDS ( BeginDate EndDate )
      WITH CORRESPONDING #( %key )
      WITH 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
        %msg = new_message(
          id       = 'ZMSG_TRAVEL'
          number   = '001'
          severity = if_abap_behv_message=>severity-error )
        %element-EndDate = if_abap_behv=>element->state->error )
        TO reported-Travel.
    ENDIF.
  ENDLOOP.
ENDMETHOD.

Types of validations

⚙️ Determinations — Automatic Field Calculations

A Determination fills or adjusts data automatically. It never blocks the save — it just shapes the data before it is written.

Common uses:

• Default a Status field to “New” when a record is created
• Calculate Total Price by summing line-item amounts
• Set the current timestamp on a “Last Changed At” field
• Derive a category field based on other field values

Step 1 — Declare the determination in the BDEF

determination setStatus on modify
  { field Status; }

Step 2 — Implement the determination method

METHOD setStatus.
  " Read the entities being processed
  READ ENTITIES OF ZI_Travel IN LOCAL MODE
    ENTITY Travel
      FIELDS ( Status )
      WITH CORRESPONDING #( %key )
      WITH keys
    RESULT DATA(lt_travel).

  " Modify Status to 'N' (New)
  DATA lt_update TYPE TABLE FOR UPDATE ZI_Travel.
  LOOP AT lt_travel INTO DATA(ls_travel).
    IF ls_travel-Status IS INITIAL.
      APPEND VALUE #(
        %tky   = ls_travel-%tky
        Status = 'N' )
        TO lt_update.
    ENDIF.
  ENDLOOP.

  " Write the changes back
  MODIFY ENTITIES OF ZI_Travel IN LOCAL MODE
    ENTITY Travel
      UPDATE FIELDS ( Status )
      WITH lt_update.
ENDMETHOD.

Types of determinations

🎬 Actions — Custom Business Operations

An Action is a business operation the user can trigger, like Approve, Cancel, Duplicate, or Submit. Actions can change data, call other business objects, and return results.

Declaring an action in the BDEF

action ( features : instance ) approve;

action ( features : instance ) cancel
  parameter ZD_CANCEL_PARAM  " optional abstract entity
  result    [1] $self;

Implementing the action

METHOD approve.
  " Read the current state
  READ ENTITIES OF ZI_Travel IN LOCAL MODE
    ENTITY Travel
      FIELDS ( Status )
      WITH CORRESPONDING #( %key )
      WITH keys
    RESULT DATA(lt_travel).

  " Set Status to 'A' (Approved)
  DATA lt_update TYPE TABLE FOR UPDATE ZI_Travel.
  LOOP AT lt_travel INTO DATA(ls_travel).
    APPEND VALUE #(
      %tky   = ls_travel-%tky
      Status = 'A' )
      TO lt_update.
  ENDLOOP.

  MODIFY ENTITIES OF ZI_Travel IN LOCAL MODE
    ENTITY Travel
      UPDATE FIELDS ( Status )
      WITH lt_update
    REPORTED DATA(reported).

  " Return a success message
  APPEND VALUE #(
    %tky = ls_travel-%tky
    %msg = new_message_with_text(
      severity = if_abap_behv_message=>severity-success
      text     = 'Travel approved' ) )
    TO reported-Travel.
ENDMETHOD.

🚨 Error Handling in RAP

RAP has a structured way to return errors and messages. Understanding this is critical.

The message pattern

• Reported messages — errors, warnings, or success messages from the framework or your code
• Failed entities — which records could not be processed
• Transitions — state changes (from “New” to “Approved”, etc.)

Severities of messages

📝 Chapter Summary

• EML (Entity Manipulation Language) is the RAP syntax for reading and modifying business objects.
• READ ENTITIES reads business object data with authorization enforced.
• MODIFY ENTITIES creates, updates, or deletes records.
• COMMIT ENTITIES saves changes to the database. Always check REPORTED and FAILED first.
• Validations check data and can block the save.
• Determinations fill or adjust data automatically.
• Actions are custom business operations that users can trigger.
• RAP has structured error handling with REPORTED, FAILED, and severity levels.