RAP layers

A typical RAP service is built in layers, each with a clear responsibility:

Behavior Definition

Defines the transactional operations allowed on the entity. This is where draft is enabled, allowing intermediate changes to be saved without committing them to the database until "Save".

ABAP RAPZI_CONTRACT_MANAGER.bdef
managed implementation in class zbp_i_contract_manager unique;
strict(2);
with draft;

define behavior for ZI_CONTRACT_MANAGER alias Contract
persistent table zcontract
draft table zcontract_d
etag master LocalLastChangedAt
lock master
authorization master ( instance )
{
  create;
  update;
  delete;

  draft action Edit;
  draft action Activate;
  draft action Discard;
  draft action Resume;
  draft determine action Prepare;

  field ( readonly ) ContractId;
  field ( mandatory ) ContractManager1;

  determination setDefaults on save { create; }
  validation validateManager on save { field ContractManager1; }
}

Behavior Implementation

The business logic lives in an ABAP class that implements the methods defined in the Behavior Definition. Here, for example, a validation that prevents saving a contract without an assigned manager.

ABAPzbp_i_contract_manager.clas.abap
METHOD validateManager.

  READ ENTITIES OF zi_contract_manager IN LOCAL MODE
    ENTITY Contract
    FIELDS ( ContractManager1 )
    WITH CORRESPONDING #( keys )
    RESULT DATA(contracts).

  LOOP AT contracts INTO DATA(contract).
    IF contract-ContractManager1 IS INITIAL.
      APPEND VALUE #( %tky = contract-%tky ) TO failed-contract.
      APPEND VALUE #( %tky = contract-%tky
        %msg = NEW zcx_contract( textid = zcx_contract=>manager_missing ) )
        TO reported-contract.
    ENDIF.
  ENDLOOP.

ENDMETHOD.
Managed vs. unmanaged: in a managed scenario (like the one above), RAP generates database access automatically. In an unmanaged scenario, the developer manually implements Create/Update/Delete — useful when there's complex persistence logic or integration with non-standard tables.

Projection and exposing it as a service

The Behavior Projection exposes only what the Fiori consumer needs, and the Service Binding publishes that projection as an OData endpoint that SAPUI5 consumes directly.

ABAP RAPZC_CONTRACT_MANAGER.bdef
projection;
strict(2);

define behavior for ZC_CONTRACT_MANAGER alias Contract
{
  use create;
  use update;
  use delete;

  use action Edit;
  use action Activate;
  use action Discard;
  use action Resume;
}

Custom actions

Beyond Create/Update/Delete, RAP supports custom actions for business operations that don't map to plain field changes — approving a contract, cancelling it, sending a notification. They appear in the Fiori UI as buttons automatically.

ABAP RAPZI_CONTRACT_MANAGER.bdef — action
action approve result [1] $self;
ABAPzbp_i_contract_manager.clas.abap — action impl
METHOD approve.
  MODIFY ENTITIES OF zi_contract_manager IN LOCAL MODE
    ENTITY Contract
    UPDATE FIELDS ( Status )
    WITH VALUE #( FOR key IN keys ( %tky = key-%tky Status = 'A' ) )
    FAILED failed
    REPORTED reported.

  result = VALUE #( FOR key IN keys ( %tky = key-%tky %param = key ) ).
ENDMETHOD.

Side effects

When changing one field should trigger the UI to refresh another (e.g. changing the manager should refresh the calculated approval limit), RAP's side effects declaration tells Fiori Elements exactly what to re-read — without writing a single line of JavaScript.

ABAP RAPZC_CONTRACT_MANAGER.bdef — side effects
side effects
{
  field ( ContractManager1 ) affects field ( ApprovalLimit );
}
Why this matters for an interview: being able to explain determinations vs. validations vs. side effects — three RAP concepts that sound similar but solve different problems — is a strong signal that you've actually built something with RAP, not just read about it.
← SAPUI5 Previous