SAP RAP — Complete Study Guide RESTful ABAP Programming Model

SAP RAP

RESTful ABAP Programming Model

Complete Study & Interview Preparation Guide

Concepts • Architecture • Annotations • OData • Interview Q&A • Scenarios

Version SAP BTP / S/4HANA

For interview preparation and revision use only Page 1

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

Level Beginner → Expert

Pages ~80+

For interview preparation and revision use only Page 2

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

Table of Contents
• 1. Introduction to SAP RAP
■ 1.1 What is RAP?
■ 1.2 RAP vs Classic ABAP Programming
■ 1.3 Key Benefits
• 2. RAP Architecture & Layers
■ 2.1 Data Model Layer (CDS Views)
■ 2.2 Business Object Layer
■ 2.3 Service Definition & Binding
• 3. CDS Views in Detail
■ 3.1 Basic CDS View
■ 3.2 CDS Annotations
■ 3.3 Associations & Compositions
■ 3.4 CDS View Extensions
• 4. Behavior Definition (BDEF)
■ 4.1 Managed vs Unmanaged
■ 4.2 BDEF Syntax
■ 4.3 Standard Operations
■ 4.4 Actions & Functions
• 5. Behavior Implementation
■ 5.1 ABAP Behavior Pool
■ 5.2 Validation
■ 5.3 Determination
■ 5.4 Side Effects
■ 5.5 Feature Control
• 6. OData Services
■ 6.1 Service Definition
■ 6.2 Service Binding
■ 6.3 OData V2 vs V4
• 7. RAP BO Runtime & Concepts
■ 7.1 EML (Entity Manipulation Language)
■ 7.2 RAP Locking
■ 7.3 Draft Handling
■ 7.4 Authorization
• 8. Interview Questions & Answers
■ 8.1 Basic Level
■ 8.2 Intermediate Level
■ 8.3 Advanced Level
• 9. Scenario-Based Questions
• 10. Quick Reference Cheat Sheet

For interview preparation and revision use only Page 3

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

1. Introduction to SAP RAP

1.1 What is SAP RAP?

SAP RESTful ABAP Programming Model (RAP) is SAP's strategic programming model for building SAP
Fiori applications and OData-based services on SAP BTP ABAP Environment and S/4HANA. It provides a
standardized, framework-driven approach to develop scalable, transactional, and analytical business
applications using ABAP and Core Data Services (CDS).

RAP was introduced as the successor to the ABAP Programming Model for Fiori (APMF) and the older
BOPF (Business Object Processing Framework). It follows a top-down, model-driven approach where the
data model (CDS views) is the central artifact from which business logic and services are derived.

1.2 RAP vs Classic ABAP Programming

Aspect Classic ABAP / BOPF SAP RAP

Data Model Database tables + SE11 CDS Views (DDIC)

Service Layer ICF Handlers / Gateway OData V2/V4 Auto-generated

Business Logic Function Modules / BOPF Nodes ABAP Behavior Pools (ABP)

Transactions SAP LUW (manual) Managed by RAP Framework

Draft Handling Custom implementation Built-in framework support

Test Tools Manual / ABAP Unit RAP BO Test via EML

Fiori Integration Manual Gateway config Seamless via Service Binding

Learning Curve High (multiple frameworks) Unified, structured model

1.3 Key Benefits of RAP

• Productivity: Built-in draft, locking, and authorization reduce custom code by up to 70%.
• Standardization: Uniform patterns for CDS, BDEF, and ABP across all SAP applications.
• OData Out-of-the-Box: Automatic OData V2/V4 service generation without Gateway config.
• Cloud-Ready: Designed for SAP BTP ABAP Environment and S/4HANA Public Cloud.
• Fiori Elements: Tight integration with SAP Fiori Elements floorplans via annotations.
• Testability: EML enables unit testing of business object behavior independently.
• Extensibility: Clean extension concepts via CDS view extensions and BDEF extensions.

For interview preparation and revision use only Page 4

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

2. RAP Architecture & Layers

RAP is built on a layered architecture. Each layer has a distinct responsibility and maps to a specific
artifact in the ABAP development environment. Understanding these layers is fundamental to working
effectively with RAP.

Layer Artifact Tool Purpose

Data Model CDS View / CDS View ADT / SE11 Define structure,
Entity associations, projections

Behavior Definition BDEF (.bdef) ADT Define CRUD, actions,

validations, determinations

Behavior ABAP Behavior Pool ADT Implement business logic in

Implementation (ABP) ABAP classes

Service Definition .srvd file ADT Expose CDS entities as a

service

Service Binding .srvb file ADT Bind service to OData

V2/V4 protocol and publish

2.1 Data Model Layer

The foundation of every RAP business object is the data model built with CDS (Core Data Services). CDS
views are the single source of truth for data structure, associations between entities, access control, and
UI annotations. A typical RAP data model consists of:

• Base/Interface CDS Views (I_*): Expose database tables with associations. These are the reusable,
stable layer.
• Projection/Consumption CDS Views (C_*): Consumer-specific views built on top of interface views.
These contain UI annotations.
• Value Help Views: CDS views annotated with @[Link]: #VALUE_HELP for
dropdown/search help.

2.2 Business Object (BO) Layer

The BO layer defines the transactional behavior of the data model. It consists of the Behavior Definition
(BDEF) and the Behavior Implementation (ABP). The BO can be composed of multiple entities forming a
composition tree — a root entity with child (composition) entities.

2.3 Service Definition & Binding

Once the data model and behavior are defined, the entities are exposed as an OData service. The Service
Definition selects which CDS entities to expose. The Service Binding links this definition to a specific
OData version (V2 or V4) and protocol (UI or API), making it consumable by Fiori apps or external API
clients.

For interview preparation and revision use only Page 5

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

3. CDS Views in Detail

3.1 Basic CDS View Structure

A CDS view (DDIC-based or CDS View Entity) is defined using ABAP DDL syntax:

@[Link]: [#NONE]
@[Link]: #CHECK
@[Link]: 'Travel Interface View'
@[Link]: true
@[Link]:{
serviceQuality: #X,
sizeCategory: #S,
dataClass: #MIXED }

define view entity ZI_TRAVEL

as select from /dmo/travel as Travel
association [0..1] to /DMO/I_Agency as _Agency
on $[Link] = _Agency.AgencyID
{
key Travel.travel_id as TravelID,
Travel.agency_id as AgencyID,
Travel.customer_id as CustomerID,
Travel.begin_date as BeginDate,
Travel.end_date as EndDate,
Travel.total_price as TotalPrice,
Travel.currency_code as CurrencyCode,
Travel.overall_status as OverallStatus,
[Link] as Description,
@[Link]: true
Travel.last_changed_at as LastChangedAt,
/* Associations */
_Agency
}

3.2 Key CDS Annotations

Annotations are metadata decorators that control how the CDS view behaves in various contexts including
UI rendering, access control, OData exposure, and object model semantics. They begin with @ and are
processed by consumers like Fiori Elements or the OData framework.

Annotation Purpose Example

@[Link] Controls view extensibility #NONE /

Category #PROJECTION_LIST

@[Link] Defines access control #CHECK /

ck enforcement #NOT_REQUIRED

For interview preparation and revision use only Page 6

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

@[Link] UI label for the view/field 'Travel Data'

@[Link] Fiori Object Page header typeName: 'Travel'

config

@[Link] List Report table column config [ { position: 10 } ]

@[Link] Search filter field config [ { position: 10 } ]

@[Link] Object Page section/facet targetElement: '_Booking'

config

@[Link] Links amount field to currency 'CurrencyCode'

e

@[Link] Marks field as currency code true

@[Link] Links key field to text field ['AgencyName']

@[Link] Enables full-text search on true

view

@[Link] Default search field true

@[Link] Assigns value help to field [Link]:

n 'ZI_Agency_VH'

@[Link] Allows metadata extensions true

3.3 Associations and Compositions

Associations represent navigational relationships between CDS entities (like JOINs but lazy).
Compositions define parent-child relationships forming the RAP Composition Tree — the backbone of a
RAP business object. A composition means the child entity's lifecycle is fully managed by the parent.

-- Association (navigational, not ownership)

association [0..1] to ZI_Agency as _Agency
on $[Link] = _Agency.AgencyID

-- Composition (parent owns the child)

composition [0..*] of ZI_Booking as _Booking

-- In child view: back-association to parent

association to parent ZI_Travel as _Travel
on $[Link] = _Travel.TravelID

3.4 CDS View Entity vs Classic CDS View

Feature Classic CDS View (define CDS View Entity (define view entity)
view)

Syntax define view ZXX as select from define view entity ZXX as select from

DDIC Artifact Creates a DB view in DDIC Purely virtual, no DB view

Recommended For Legacy / older systems S/4HANA 2020+ / BTP

For interview preparation and revision use only Page 7

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

Performance Good Better (no DB view overhead)

Extensions Limited Full CDS Extension support

3.5 CDS Metadata Extensions

Instead of putting all UI annotations directly in the CDS view, you can use a Metadata Extension file. This
is the preferred approach as it keeps the data model clean and separates UI concerns. The CDS view
must have @[Link]: true.

@[Link]: #CUSTOMER
annotate view ZI_TRAVEL with
{
@[Link]: [
{ id: 'HeaderInfo',
type: #DATAPOINT_REFERENCE,
targetQualifier: 'TotalPrice',
purpose: #HEADER,
position: 10 }
]

@[Link]: {
typeName: 'Travel',
typeNamePlural: 'Travels',
[Link]: 'TravelID',
[Link]: 'Description'
}

@[Link]: [ { position: 10, importance: #HIGH } ]

@[Link]: [ { position: 10 } ]
TravelID;

@[Link]: [ { position: 20 } ]
AgencyID;
}

For interview preparation and revision use only Page 8

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

4. Behavior Definition (BDEF)

The Behavior Definition (BDEF) is a DDL-like artifact (.bdef extension) that declares the transactional
capabilities of a RAP Business Object. It specifies which standard CRUD operations are supported,
defines actions, validations, determinations, and feature controls.

4.1 Managed vs Unmanaged Implementation

Aspect Managed Unmanaged

Definition managed implementation in class... unmanaged implementation in class...

Keyword

CRUD by YES – framework handles NO – developer implements all CRUD

Framework create/update/delete

Locking Automatic (ETag / persistent lock) Developer must implement lock()

Numbering Internal or early external numbering Developer implements in augment

Use Case New development on S/4HANA / BTP Legacy system wrappers (RFC/BAPI)

Draft Handling Built-in with with draft Complex, needs custom

implementation

Recommended YES for greenfield Only when wrapping legacy APIs

4.2 Full BDEF Syntax (Managed)

managed implementation in class zbp_travel unique;
strict ( 2 );
with draft;

define behavior for ZI_TRAVEL alias Travel

persistent table /dmo/travel
draft table zdtravel
lock master total etag LastChangedAt
authorization master ( instance )
etag master LastChangedAt
{
/* Standard CRUD Operations */
create;
update;
delete;

/* Field Control */
field ( readonly : update ) TravelID;
field ( readonly ) TotalPrice, CurrencyCode;
field ( mandatory : create ) AgencyID, CustomerID, BeginDate, EndDate;

/* Actions */

For interview preparation and revision use only Page 9

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

action ( features : instance ) acceptTravel result [1] $self;

action ( features : instance ) rejectTravel result [1] $self;

static action copyTravel

parameter ZD_A_Travel_Copy
result [0..*] $self;

/* Functions */
function getEarliestStartDate
result [1] D_Travel_DateResult;

/* Validations */
validation validateAgency on save { create; update; }
validation validateDates on save { create; update; }
validation validateStatus on save { create; update; }

/* Determinations */
determination setStatusToOpen on modify { create; }
determination calcTotalPrice on modify { field BookingFee, CurrencyCode; }

/* Side Effects */
side effects {
field BookingFee affects field TotalPrice;
}

/* Draft Actions */
draft action Edit;
draft action Activate optimized;
draft action Discard;
draft action Resume;
draft determine action Prepare { validation validateDates; }

/* Child Composition */
association _Booking { create; with draft; }
}

/* Child Entity */
define behavior for ZI_BOOKING alias Booking
persistent table /dmo/booking
draft table zdtbooking
lock dependent by _Travel
authorization dependent by _Travel
etag dependent by _Travel
{
update;
delete;

For interview preparation and revision use only Page 10

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

field ( readonly : update ) BookingID;

field ( mandatory : create ) BookingDate, CustomerID;

validation validateBookingStatus on save { create; update; }

association _Travel { with draft; }

association _BookingSupp { create; with draft; }
}

4.3 Standard Operations Explained

• create: Allows creation of new BO instances. The framework auto-generates the SAVE sequence for
managed BOs.
• update: Allows modification of existing BO instances. Field-level control determines which fields are
editable.
• delete: Allows deletion of BO instances. Cascading delete for child entities is handled automatically in
managed BOs.
• read: Implicitly always available; not declared in BDEF. All entities are readable via OData GET.

4.4 Actions vs Functions

Aspect Action Function

Side Effects YES – modifies data NO – read-only

HTTP Method POST GET (function import)

Declaration action actionName result [1] $self function funcName result [1] ZType

Instance vs Static Both supported Both supported

Example acceptTravel, rejectTravel getDiscount, calculateTax

ABAP Handler FOR MODIFY ...ACTION FOR READ ...FUNCTION

4.5 Feature Control

Feature control dynamically enables or disables operations and fields at runtime. This allows
context-sensitive behavior — e.g., hiding the 'Accept' button after a travel is already accepted.

METHOD get_instance_features.
READ ENTITIES OF zi_travel IN LOCAL MODE
ENTITY Travel
FIELDS ( OverallStatus )
WITH CORRESPONDING #( keys )
RESULT DATA(travels)
FAILED failed.

result =
VALUE #(
FOR travel IN travels

For interview preparation and revision use only Page 11

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

( %tky = travel-%tky
%action-acceptTravel =
COND #( WHEN travel-OverallStatus = 'A'
THEN if_abap_behv=>fc-o-disabled
ELSE if_abap_behv=>fc-o-enabled )
%action-rejectTravel =
COND #( WHEN travel-OverallStatus = 'X'
THEN if_abap_behv=>fc-o-disabled
ELSE if_abap_behv=>fc-o-enabled )
)
).
ENDMETHOD.

For interview preparation and revision use only Page 12

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

5. Behavior Implementation (ABP)

The ABAP Behavior Pool (ABP) is the ABAP class that implements the business logic declared in the
BDEF. It consists of a global class and local handler/saver classes. Each entity in the BDEF gets a local
handler class (lhc_entity) inside the behavior pool.

5.1 ABP Class Structure

CLASS zbp_travel DEFINITION PUBLIC ABSTRACT FINAL
INHERITING FROM cl_abap_behavior_handler.

PRIVATE SECTION.
" Handler methods defined here (auto-generated or manual)
ENDCLASS.

CLASS zbp_travel IMPLEMENTATION.

ENDCLASS.

"============================================================
" Local Handler Class in the include lhc_travel
"============================================================
CLASS lhc_travel DEFINITION INHERITING FROM cl_abap_behavior_handler.
PRIVATE SECTION.
METHODS:
" Validation
validateAgency FOR VALIDATE ON SAVE
IMPORTING keys FOR Travel~validateAgency,
validateDates FOR VALIDATE ON SAVE
IMPORTING keys FOR Travel~validateDates,

" Determination
setStatusToOpen FOR DETERMINE ON MODIFY
IMPORTING keys FOR Travel~setStatusToOpen,

" Action
acceptTravel FOR MODIFY
IMPORTING keys FOR ACTION Travel~acceptTravel
RESULT result,

" Feature Control

get_instance_features FOR INSTANCE FEATURES
IMPORTING keys REQUEST requested_features
FOR Travel RESULT result.
ENDCLASS.

5.2 Validations – Deep Dive

For interview preparation and revision use only Page 13

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

Validations are triggered on save and used to check data consistency. They must report errors using the
REPORTED structure. If an error is reported, the save is rejected for that instance.

METHOD validateAgency.
" Read only the AgencyID field for the keys being validated
READ ENTITIES OF zi_travel IN LOCAL MODE
ENTITY Travel
FIELDS ( AgencyID )
WITH CORRESPONDING #( keys )
RESULT DATA(travels)
FAILED DATA(lt_failed).

DATA(agency_ids) = travels->AgencyID.

" Check if agencies exist in the database

SELECT AgencyID FROM /dmo/agency
FOR ALL ENTRIES IN @travels
WHERE agency_id = @travels-AgencyID
INTO TABLE @DATA(valid_agencies).

LOOP AT travels INTO DATA(travel).

" Skip initial/empty AgencyIDs
IF travel-AgencyID IS INITIAL.
CONTINUE.
ENDIF.

" Check if agency is valid

IF NOT line_exists( valid_agencies[ AgencyID = travel-AgencyID ] ).
APPEND VALUE #( %tky = travel-%tky ) TO failed-travel.
APPEND VALUE #(
%tky = travel-%tky
%msg = new_message_with_text(
severity = if_abap_behv_message=>severity-error
text = 'Agency is invalid' )
%element-AgencyID = if_abap_behv=>mk-on
) TO reported-travel.
ENDIF.
ENDLOOP.
ENDMETHOD.

5.3 Determinations – Deep Dive

Determinations auto-compute field values when triggered by field changes (on modify) or on save. They
run within the ABAP runtime and modify the entity's data. Unlike validations, they write data — they don't
report errors.

METHOD setStatusToOpen.
" Read the current status

For interview preparation and revision use only Page 14

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

READ ENTITIES OF zi_travel IN LOCAL MODE

ENTITY Travel
FIELDS ( OverallStatus )
WITH CORRESPONDING #( keys )
RESULT DATA(travels).

" Filter only those where status is not yet set

DELETE travels WHERE OverallStatus IS NOT INITIAL.
CHECK travels IS NOT INITIAL.

" Set status to 'Open'

MODIFY ENTITIES OF zi_travel IN LOCAL MODE
ENTITY Travel
UPDATE FIELDS ( OverallStatus )
WITH VALUE #( FOR travel IN travels
( %tky = travel-%tky
OverallStatus = 'O' ) )
REPORTED DATA(reported_modify)
FAILED DATA(failed_modify).

" Propagate failures

reported = CORRESPONDING #( DEEP reported_modify ).
failed = CORRESPONDING #( DEEP failed_modify ).
ENDMETHOD.

5.4 Side Effects

Side effects inform the Fiori Elements UI framework which fields need to be re-read from the backend
when a specific field changes. This enables dynamic form updates without full page reload. Declared in
BDEF:

" In BDEF
side effects {
" When BookingFee changes, TotalPrice must be refreshed
field BookingFee affects field TotalPrice;

" When AgencyID changes, refresh the whole entity

field AgencyID affects entity;

" Action side effects: after action, refresh child entity

action acceptTravel affects entity _Booking;
}

5.5 Early Numbering vs Late Numbering

Type When Generated How to Implement Use Case

For interview preparation and revision use only Page 15

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

Internal Early At the time of CREATE Implement FOR UUID-based keys

call (before save) NUMBERING in ABP

External Early Provided by the caller No numbering User-defined IDs

implementation needed

Late Numbering During the SAVE Implement adjust_numbers ERP number ranges
sequence in SAVE handler
(on_save_prepare)

For interview preparation and revision use only Page 16

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

6. OData Services in RAP

6.1 Service Definition

The Service Definition (.srvd) selects which CDS projection entities to expose. It acts as a catalogue of
what is available in the service, without binding to any protocol.

@[Link]: 'Travel Service Definition'

define service ZUI_TRAVEL_O4 {
expose ZC_TRAVEL as Travel;
expose ZC_BOOKING as Booking;
expose ZC_BOOKSUPPL as BookingSupplement;
expose /DMO/I_Agency_StdVH as Agency;
expose /DMO/I_Customer_StdVH as Traveller;
expose /DMO/I_Flight_StdVH as Flight;
expose I_Currency as Currency;
expose I_Country as Country;
}

6.2 Service Binding

The Service Binding (.srvb) connects the Service Definition to a specific OData version and use-case
category. Once published, it creates an active OData endpoint accessible via URL.

Binding Type Protocol Use Case

OData V2 - UI OData V2 SAP Fiori Elements (V2 apps, older

floorplans)

OData V4 - UI OData V4 SAP Fiori Elements (V4 apps, recommended)

OData V4 - Web API OData V4 External API consumption (REST clients)

OData V2 - Web API OData V2 External API (legacy consumers)

InA InA Protocol SAP Analytics Cloud, analytical queries

6.3 OData V2 vs V4 Key Differences

Feature OData V2 OData V4

Standard Older, widely supported Latest, more powerful

Query Options $filter, $select, $expand All V2 + $compute, $apply, $search

Batch Requests $batch endpoint $batch (improved changesets)

Actions/Functions FunctionImports only Actions + Functions on entity sets

Draft Supported via SAP extension Native draft actions supported

Aggregation Limited Full aggregation via $apply

Streaming Not native Supported

For interview preparation and revision use only Page 17

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

For interview preparation and revision use only Page 18

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

7. RAP Runtime Concepts

7.1 Entity Manipulation Language (EML)

EML is a set of ABAP statements that allows you to interact with RAP Business Objects programmatically
— from ABAP code. It is the ABAP equivalent of calling OData operations. EML is used in behavior
implementations, unit tests, and calling BOs from other programs.

" ■■ CREATE ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

MODIFY ENTITIES OF zi_travel
ENTITY Travel
CREATE
FIELDS ( AgencyID CustomerID BeginDate EndDate TotalPrice CurrencyCode )
WITH VALUE #(
( %cid = 'CID_001'
AgencyID = '070041'
CustomerID = '000001'
BeginDate = '20240101'
EndDate = '20240201'
TotalPrice = '1000'
CurrencyCode = 'USD' )
)
MAPPED DATA(mapped)
FAILED DATA(failed)
REPORTED DATA(reported).

" ■■ READ ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

READ ENTITIES OF zi_travel
ENTITY Travel
FIELDS ( TravelID AgencyID OverallStatus )
WITH VALUE #( ( TravelID = lv_travel_id ) )
RESULT DATA(travels)
FAILED failed.

" ■■ UPDATE ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

MODIFY ENTITIES OF zi_travel
ENTITY Travel
UPDATE
FIELDS ( OverallStatus )
WITH VALUE #(
( %tky = travel-%tky
OverallStatus = 'A' )
).

" ■■ DELETE ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

MODIFY ENTITIES OF zi_travel

For interview preparation and revision use only Page 19

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

ENTITY Travel
DELETE FROM VALUE #( ( %tky = travel-%tky ) ).

" ■■ EXECUTE ACTION ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

MODIFY ENTITIES OF zi_travel
ENTITY Travel
EXECUTE acceptTravel
FROM VALUE #( ( %tky = travel-%tky ) )
RESULT DATA(action_result).

" ■■ COMMIT WORK ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

COMMIT ENTITIES
BEGIN OF RESPONSE OF zi_travel
FAILED DATA(commit_failed)
REPORTED DATA(commit_reported)
END OF RESPONSE.

7.2 Draft Handling in RAP

Draft allows users to save incomplete work without activating it. Drafts are stored in separate draft
database tables and are only visible to the editing user. When the user clicks 'Save' in the Fiori app, the
draft is activated (becomes the active version).

Draft Concept Description

Draft Table Separate database table (zdtravel) prefixed with ZDT or custom
name. Auto-managed by framework.

Draft UUID %pid (preliminary ID) identifies draft records uniquely before
activation.

Edit Action Copies the active record to draft table, creates a lock.

Activate Action Runs validations. On success, writes draft to active table. Deletes
draft.

Discard Action Deletes draft record and releases lock without saving.

Draft Indicator @[Link] with qualifier on list shows draft indicator

icon.

with draft in BDEF Keyword in BDEF that enables full draft support for the entity.

7.3 Locking in RAP

RAP uses optimistic locking (ETag-based) by default for managed BOs. When a user opens a record for
editing, an ETag (e.g., based on LastChangedAt timestamp) is captured. When saving, the ETag is
compared — if it changed, a lock conflict is raised.

" ETag declaration in BDEF

lock master total etag LastChangedAt
etag master LastChangedAt

For interview preparation and revision use only Page 20

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

" The CDS view must have the LastChangedAt field annotated:
@[Link]: true
last_changed_at as LastChangedAt

7.4 Authorization in RAP

RAP supports authorization at two levels: Access Control (via DCL files on CDS views for read access)
and Instance Authorization (via the behavior pool for write operations).

" ■■ DCL (Data Control Language) for CDS Read Access ■■■■■■■■■■■■
@MappingRole: true
define role ZI_TRAVEL {
grant select on ZI_TRAVEL
where ( AgencyID ) = aspect pfcg_auth( /DMO/TRVL, ZAGENCY, ACTVT = '03' );
}

" ■■ Instance Authorization in ABP ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

METHOD get_instance_authorizations.
READ ENTITIES OF zi_travel IN LOCAL MODE
ENTITY Travel FIELDS ( AgencyID ) WITH CORRESPONDING #( keys )
RESULT DATA(travels).

LOOP AT travels INTO DATA(travel).

" Check authorization object
AUTHORITY-CHECK OBJECT '/DMO/TRVL'
ID 'ZAGENCY' FIELD travel-AgencyID
ID 'ACTVT' FIELD '02'. " 02 = Change

IF sy-subrc <> 0.
APPEND VALUE #( %tky = travel-%tky ) TO failed-travel.
APPEND VALUE #(
%tky = travel-%tky
%update = if_abap_behv=>auth-unauthorized
) TO result.
ENDIF.
ENDLOOP.
ENDMETHOD.

For interview preparation and revision use only Page 21

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

8. Interview Questions & Answers

8.1 Basic Level Questions

Q1. What is SAP RAP and why was it introduced?
SAP RAP (RESTful ABAP Programming Model) is SAP's strategic framework for building transactional
OData services and Fiori applications on S/4HANA and SAP BTP. It was introduced to replace the
fragmented older approaches (BOPF, SEGW Gateway Builder, APMF) with a unified, model-driven,
cloud-ready programming model. RAP standardizes how business objects are defined, how business logic
is implemented, and how services are exposed — reducing development effort and increasing consistency
across SAP applications.

Q2. What are the main layers/artifacts in a RAP business object?

A RAP BO consists of: (1) CDS View/CDS View Entity – the data model layer defining structure and
associations; (2) Behavior Definition (BDEF) – declares what operations (CRUD, actions, validations) are
supported; (3) ABAP Behavior Pool (ABP) – the ABAP class implementing the declared behavior; (4)
Service Definition – selects CDS entities to expose; (5) Service Binding – binds the definition to OData V2
or V4 and publishes the endpoint.

Q3. What is the difference between managed and unmanaged RAP?

In Managed RAP, the framework automatically handles CRUD operations, locking, draft persistence, and
the save sequence. The developer only needs to implement business-specific logic (validations,
determinations, actions). In Unmanaged RAP, the developer must implement all operations manually
including reading, writing, locking, and committing. Unmanaged is used when wrapping legacy APIs (like
BAPIs or RFCs) that already handle data persistence. Managed is recommended for all new
developments.

Q4. What is CDS and what role does it play in RAP?

CDS (Core Data Services) is SAP's SQL-based data modeling language used to define semantically rich
database views with built-in annotations. In RAP, CDS views form the entire data model layer — they
define what data is exposed, how entities relate to each other (via associations and compositions), and
carry UI and semantic annotations that drive automatic Fiori Elements rendering and OData service
generation.

Q5. What is a Behavior Definition (BDEF) file?

A BDEF is a DDL-like artifact (file extension .bdef) that declares the transactional behavior of a RAP
Business Object. It specifies: which standard operations (create, update, delete) are enabled; custom
actions and functions; validations and their trigger conditions; determinations and their triggers; feature
control methods; draft handling configuration; lock and ETag definitions; and authorization controls. The
BDEF is purely declarative — the actual implementation lives in the ABAP Behavior Pool.

Q6. What is a Service Definition vs Service Binding?

A Service Definition (.srvd) is a catalog that selects and names the CDS entities to be exposed in a
service. It is protocol-agnostic. A Service Binding (.srvb) takes a Service Definition and binds it to a
specific protocol (OData V2 UI, OData V4 UI, OData V4 Web API). Publishing a Service Binding creates
the actual HTTP endpoint. One Service Definition can have multiple Service Bindings for different
protocols.

Q7. What is EML (Entity Manipulation Language)?

For interview preparation and revision use only Page 22

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

EML is a set of ABAP keywords that allow direct programmatic access to RAP Business Objects from
ABAP code. It supports READ ENTITIES (for reading), MODIFY ENTITIES (for
create/update/delete/action execution), and COMMIT ENTITIES (to trigger the save sequence). EML
bypasses the HTTP layer and interacts directly with the RAP runtime, making it ideal for unit tests,
background processing, and calling one BO from another.

Q8. What is a RAP Composition Tree?

A RAP Composition Tree is the hierarchical structure of a RAP Business Object formed by parent-child
relationships using the 'composition' keyword in CDS views. The root entity is the composition root, and it
can have child entities (e.g., Booking under Travel). The lifecycle of child entities is fully controlled by the
parent — locking, draft, and authorization flow from root to children. A child entity declares 'association to
parent' to navigate back up the tree.

Q9. What annotations control how a Fiori List Report looks?

@[Link] annotations on fields of the projection CDS view control which columns appear in the List
Report table and their order (position property). @[Link] controls the filter bar fields.
@[Link] provides the list title and item type label. @[Link] can control sorting and
grouping. These annotations can be placed directly in the CDS view or in a Metadata Extension file.

Q10. What is the purpose of @[Link] annotation?

This annotation on a CDS view controls whether the associated DCL (Data Control Language) access
control rules are enforced when the view is read. Values: #CHECK means DCL rules are applied and
unauthorized records are filtered out; #NOT_REQUIRED means no DCL check is applied (used for
internal/technical views); #PRIVILEGED_ONLY means only privileged access (bypassing DCL) is allowed.
In production CDS views, #CHECK is recommended for security.

8.2 Intermediate Level Questions

Q11. Explain the RAP BDEF 'strict' mode and its levels.
The 'strict' keyword in BDEF enforces stricter syntax and runtime checks. strict(1) is the basic level that
enforces consistent use of %tky (transactional key) and disallows some legacy patterns. strict(2) is stricter
and requires all handler method signatures to precisely match the BDEF declaration. strict(2) is mandatory
for draft-enabled BOs and is the recommended standard for all new development. It ensures compile-time
safety and eliminates ambiguous runtime behavior.

Q12. What is the difference between validation and determination in RAP?

A Validation checks data consistency and reports errors to reject the save — it reads data but never
modifies it. Validations are triggered 'on save' (just before the commit). A Determination automatically
computes or sets field values when triggered by field changes (on modify trigger) or on save.
Determinations write data to the BO instance. Example: validateDates is a validation that rejects a travel if
EndDate < BeginDate. setStatusToOpen is a determination that auto-sets OverallStatus to 'O' when a new
travel is created.

Q13. How does RAP handle number generation (key assignment)?

RAP supports three numbering types: (1) External Numbering — keys provided by the calling application
(user enters the ID). (2) Internal Early Numbering — keys generated by the framework/ABP at CREATE
time, typically UUID-based, using a FOR NUMBERING handler. (3) Late Numbering — keys generated
during the SAVE sequence (in adjust_numbers of the SAVE handler), using number ranges from
database. The type is declared in the BDEF with keywords like 'early numbering' or 'late numbering'.

For interview preparation and revision use only Page 23

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

Q14. What is %tky in RAP EML and how does it differ from %key?
%tky (transactional key) is the combination of the entity's primary key fields plus %pid (preliminary ID for
drafts) and %is_draft flag. It uniquely identifies an entity instance in both active and draft state. %key
contains only the persistent key fields. When working with draft-enabled BOs, always use %tky instead of
%key to correctly identify instances regardless of their draft/active status.

Q15. Explain side effects in RAP and when to use them.

Side effects are declarations in the BDEF that tell the Fiori Elements framework which fields/entities need
to be re-fetched from the server when a field changes or an action is executed. Without side effects, the UI
would show stale data after a change. Example: When the user changes BookingFee, a server-side
determination recalculates TotalPrice. Without a side effect declaration, TotalPrice would remain
unchanged on screen. Side effects bridge the gap between server-side computations and client-side UI
refresh.

Q16. What is a projection view (consumption view) and why is it needed?

A projection (consumption) CDS view is built on top of an interface view and is consumer-specific. It allows
you to: select only the fields relevant for a specific app; add UI-specific annotations (keeping the interface
view clean and reusable); rename fields for better user-facing labels; define value help assignments; and
restrict navigation. The convention is I_* for interface views and C_* for consumption views. The BDEF is
defined on the projection view for transactional scenarios.

Q17. How does RAP authorization work at different levels?

RAP has two authorization layers: (1) Read Authorization via DCL (Data Control Language) — a .dcl file
linked to the CDS view via @[Link]: #CHECK. The DCL defines WHERE
conditions based on PFCG authorization objects, filtering rows the user cannot see. (2) Instance
Authorization via the ABAP Behavior Pool — the get_instance_authorizations method checks whether the
user is permitted to perform a specific operation (create/update/delete/action) on a specific instance by
checking authorization objects with AUTHORITY-CHECK.

Q18. What is the RAP SAVE sequence and what events occur during it?
The SAVE sequence is triggered when COMMIT ENTITIES is called. The framework executes: (1)
on_before_save — runs determinations triggered on_save; (2) validate — executes all on_save
validations; if any validation fails, the save is rejected; (3) adjust_numbers — called for late numbering
BOs to assign final persistent keys; (4) on_save — the actual write to the database (for managed, this is
done automatically; for unmanaged, the developer implements save_modified); (5) cleanup — post-save
cleanup of transactional buffers.

Q19. What are static actions vs instance actions in RAP?

Instance actions operate on specific BO instances (they receive the entity keys as input). They are called
on a single record or a set of records — e.g., acceptTravel(key=12). Static actions are not bound to any
specific instance — they operate at the entity type level (like a class method vs instance method). They
can have their own input parameters. Example: copyTravel is a static action that takes a source TravelID
as parameter and creates a copy, returning the new instance. Both can have result parameters.

Q20. How do you test RAP business objects?

RAP BOs can be tested using: (1) EML in ABAP programs/reports for manual testing; (2) ABAP Unit Tests
with CL_ABAP_BEHV_TESTDOUBLE — a test double framework that lets you mock BO behavior without
hitting the real database. Use ROLLBACK ENTITIES to undo changes. (3) Published OData Service
tested via the Service Binding's 'Preview' feature in ADT, which opens an automatically generated Fiori
Elements test app. (4) OData testing with tools like Postman or REST Client using the published endpoint
URL.

For interview preparation and revision use only Page 24

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

For interview preparation and revision use only Page 25

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

8.3 Advanced Level Questions

Q21. How do you implement a custom action with input parameters and result in RAP?
First, declare the action in BDEF with a parameter type and result type: 'action copyTravel parameter
ZD_A_Travel_Copy result [0..*] $self'. Then define the DDIC abstract entity ZD_A_Travel_Copy with the
input fields. In the ABP, implement: METHOD copyTravel FOR MODIFY IMPORTING keys FOR ACTION
Travel~copyTravel RESULT result. Inside, read the source entities using READ ENTITIES, create new
instances using MODIFY ENTITIES with %cid, and populate the result table with the newly created
instances mapped to the original %cid_ref keys.

Q22. Explain the RAP Business Object's transactional buffer and how it works.
RAP maintains an in-memory transactional buffer that holds all pending changes during a single
transaction (between the first MODIFY ENTITIES and COMMIT ENTITIES). All READ ENTITIES within
the same transaction read from this buffer (IN LOCAL MODE), ensuring consistency of in-flight changes.
The buffer is organized per entity type and keyed by %tky. The buffer is only written to the database during
the SAVE sequence. For managed BOs, buffer management is fully handled by the framework.

Q23. What is the difference between 'IN LOCAL MODE' and standard EML reads?
READ ENTITIES OF ... IN LOCAL MODE reads from the RAP transactional buffer — it sees uncommitted
changes made within the current transaction. This is used inside behavior pool methods (validations,
determinations, actions) to read the current state of in-flight modifications. READ ENTITIES OF ...
WITHOUT IN LOCAL MODE (or omitting IN LOCAL MODE in certain contexts) reads from the database,
not the buffer. Inside ABP handler methods, always use IN LOCAL MODE to correctly see the latest
pending changes.

Q24. How does RAP handle the Fiori Elements Object Page with multiple facets?
The Object Page layout is controlled via @[Link] annotations in the projection CDS view or metadata
extension. A facet can be of type: #COLLECTION_FACET (a section grouping other facets),
#IDENTIFICATION_REFERENCE (group of fields), #FIELDGROUP_REFERENCE (a specific field group
defined with @[Link]), or #LINEITEM_REFERENCE (for child entity tables). Each facet references
target elements (fields or navigation to child entities) and has position, label, and ID. Nested facets create
tabbed/subsection layouts.

Q25. Explain virtual elements in CDS views and their use in RAP.
Virtual elements (VIRTUAL keyword in CDS view) are computed fields that are not stored in the database
and are not part of any SELECT statement. They are populated by the ABP in the FOR READ method
using RESULT parameter augmentation. Virtual elements are used for: display-only computed fields;
traffic light indicators (criticality); fields that combine data from multiple sources dynamically. They must be
defined in the CDS view and their computation must be implemented in a FOR READ handler in the
behavior pool.

Q26. How do you implement a RAP BO that wraps a legacy BAPI (Unmanaged)?
In Unmanaged RAP: (1) Define the CDS view on a database view/table that the BAPI writes to. (2) Create
a BDEF with 'unmanaged implementation in class zbp_xxx unique'. (3) Implement create/update/delete
methods in the ABP that call the BAPI using CALL FUNCTION ... IN BACKGROUND TASK or
synchronously, handling errors by mapping to FAILED/REPORTED. (4) Implement the SAVE handler
(lsc_xxx INHERITING FROM cl_abap_behavior_saver) with save_modified method that calls the BAPI's
commit BAPI or BAPI_TRANSACTION_COMMIT. (5) Implement lock() and unlock() methods for
pessimistic locking.

Q27. What are the RAP extensibility concepts?

For interview preparation and revision use only Page 26

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

RAP supports: (1) CDS View Extension — new fields added to an existing CDS view via 'extend view
entity ZI_TRAVEL with { extension_field; }'. (2) BDEF Extension — declared with 'extend behavior
ZI_TRAVEL' in a separate BDEF, adding new actions, validations. (3) Behavior Pool Extension — a
separate extension class implementing the extension BDEF. (4) Metadata Extension — adding/overriding
annotations without changing the CDS view. (5) Projection Extension — field added in projection layer
only. These allow partner/customer extensions without modifying SAP standard objects.

Q28. What is 'optimized draft activation' in RAP?

Standard draft activation re-reads all data from the draft table and writes it to the active table. Optimized
activation (declared as 'draft action Activate optimized') only processes fields that actually changed during
the draft session, resulting in better performance. However, optimized activation has requirements: the BO
must support ETag-based change tracking, and the data model must correctly declare administrative fields
like @[Link]. Optimized activation is recommended for large BOs
with many fields.

Q29. How do you implement global feature control vs instance feature control?
Global feature control (get_global_features) returns the same result for all instances — e.g., 'the Create
button is disabled for all instances when in read-only mode'. It is declared with 'features: global' in the
BDEF operation. Instance feature control (get_instance_features) is per-instance — each key gets its own
feature flags. Declared with 'features: instance'. Instance control reads the entity state to decide — e.g.,
'Accept button is disabled only for travels that are already accepted'. Instance control requires a READ
ENTITIES call and is more expensive than global control.

Q30. Explain the difference between %control and %element in RAP.

%control is a structure in MODIFY operations that acts as a field selector — it has one boolean flag per
field, indicating which fields should be updated. This prevents overwriting fields with empty values when
only specific fields need updating. %element is used in the REPORTED structure within validations to
indicate which specific field caused the validation error, enabling the Fiori UI to highlight the exact input
field in red. Both are automatically generated based on the entity fields. Always use %control in UPDATE
calls to avoid unintentional field overwrites.

For interview preparation and revision use only Page 27

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

9. Scenario-Based Questions
Scenario 1: Travel Agency Booking System

Situation: You need to build a Fiori app for managing travel bookings. Travel has Booking children, and
each Booking has Booking Supplements. The app must support draft saving, status transitions (Open →
Accepted/Rejected), and price calculations.

Solution: Design a three-level RAP composition tree: ZI_TRAVEL (root) → ZI_BOOKING (child) →
ZI_BOOKSUPPL (grandchild). Use managed implementation with draft. Define 'acceptTravel' and
'rejectTravel' as instance actions with feature control (disabled when already in that status). Add a
determination 'calcTotalPrice' triggered on BookingFee field change. Expose via OData V4 UI binding.
Use metadata extensions for Fiori Elements annotations.

Scenario 2: Wrapping a Legacy BAPI for a Fiori App

Situation: A legacy ERP system uses BAPI_PURCHASEORDER_CREATE to create purchase orders.

You need to expose this as a modern Fiori app without rewriting the business logic.

Solution: Use Unmanaged RAP. Create a CDS view on the EKKO/EKPO tables for reading. In the
BDEF, declare 'unmanaged implementation'. In the ABP create handler, buffer the input data in a static
variable. Implement the SAVE handler's save_modified to call BAPI_PURCHASEORDER_CREATE.
Call BAPI_TRANSACTION_COMMIT in save_modified. Map BAPI RETURN table errors to FAILED and
REPORTED structures. Implement lock() using ENQUEUE function modules.

Scenario 3: Adding a Custom Field and Logic to S/4HANA Standard

Situation: A customer wants to add a 'Risk Level' field to the standard Travel BO in S/4HANA that
affects booking approval workflow. You cannot modify SAP standard objects.

Solution: Use RAP extensibility: (1) Create a append structure on /DMO/TRAVEL table adding
ZRISK_LEVEL. (2) Extend view entity /DMO/I_Travel_U with the new field. (3) Create an extension
BDEF 'extend behavior /DMO/I_Travel_U' adding a validation 'validateRiskLevel' and action
'triggerRiskApproval'. (4) Implement in an extension ABP. (5) Extend the projection view C_Travel for UI
exposure. (6) Create metadata extension to add the field to the Fiori UI.

Scenario 4: Performance Issue: Slow List Report

Situation: Your RAP-based List Report loads slowly because it fetches 50,000+ records. Users only see
20 records at a time in the table. The CDS view joins 5 tables.

Solution: Implement server-side paging properly (OData $top/$skip is auto-handled). Review the CDS
view for unnecessary joins — break into base views and join only what's needed for the list. Add
database indexes on the join conditions. Use @[Link] for frequently-read static data.
Add @[Link] to define a default sort to improve DB query planning. Consider aggregate
views for count/total operations. Check the CDS view with the SQL trace (ST05) to identify slow
operations.

Scenario 5: Multi-Tenant Draft Conflict Resolution

Situation: Two users (User A and User B) try to edit the same Travel record simultaneously. User A
saves first. User B then tries to save. How should this be handled?

For interview preparation and revision use only Page 28

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

Solution: RAP handles this via ETag-based optimistic locking. When User A opens the record, the UI
captures the LastChangedAt ETag. When User B opens it, they get the same ETag. User A saves —
LastChangedAt is updated. When User B tries to save with the old ETag, the RAP framework detects the
mismatch and returns a lock/conflict error (HTTP 412 Precondition Failed). The Fiori app shows User B a
message that the record was changed and prompts them to refresh. For draft-enabled BOs, the draft
lock (edit action) is even more explicit — User B cannot even start editing until User A's draft is
discarded.

Scenario 6: Implementing a Value Help with Search and Filters

Situation: The Travel booking form needs a value help for selecting a Flight that shows FlightID, Airline,
DepartureAirport, DestinationAirport, and can be filtered by date.

Solution: Create a CDS view ZI_FLIGHT_VH with @[Link]: #VALUE_HELP. Add

@[Link]: true on the view and @[Link]: true on FlightID. In the
projection CDS view, annotate the FlightID field with: @[Link]: [{ entity: {
name: 'ZI_FLIGHT_VH', element: 'FlightID' }, qualifier: 'FlightVH' }]. Expose ZI_FLIGHT_VH in the
Service Definition. The Fiori Elements app auto-generates the value help dialog with a search bar and
table based on @[Link] annotations on the value help CDS view.

Scenario 7: Implementing a Batch Processing with EML

Situation: A background job needs to reject all Travels that have passed their EndDate and are still in
'Open' status. This runs as a scheduled ABAP job, not triggered by a user.

Solution: Write an ABAP report that uses EML: (1) SELECT travels where EndDate < sy-datum AND
OverallStatus = 'O'. (2) Use MODIFY ENTITIES OF zi_travel ENTITY Travel EXECUTE rejectTravel
FROM VALUE #( FOR t IN travels ( %tky = t-%tky ) ) to execute the action. (3) Call COMMIT ENTITIES
to persist. Handle FAILED and REPORTED to log errors. This approach respects the BO's business
logic (validations, determinations, authorization) even from a background job, ensuring consistent
behavior.

Scenario 8: Building an Analytical List Page (ALP)

Situation: Business wants a dashboard showing total travel spend by agency, with drill-down to
individual travels and the ability to filter by date range and currency.

Solution: Create two CDS views: (1) An aggregation view ZI_TRAVEL_AGG using
@[Link]: #CUBE with @[Link]: true, using aggregation
annotations on TotalPrice (@DefaultAggregation: #SUM). (2) A transactional view for the drill-down list.
In the Service Definition, expose both. In the Fiori Elements app, use the ALP (Analytical List Page)
floorplan that combines the chart (from the aggregation view) and the table (from the transactional view).
Use @[Link] annotation to configure the chart type and dimensions.

For interview preparation and revision use only Page 29

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

10. Quick Reference Cheat Sheet

Key BDEF Keywords at a Glance

Keyword / Clause Meaning

managed Framework handles CRUD and save sequence

unmanaged Developer handles all operations manually

with draft Enable draft (work in progress) support

strict(2) Enforce strict type checking and signature matching

lock master This entity is the lock master (root entity)

lock dependent by _Parent Child entity's lock is controlled by the parent

etag master LastChangedAt Use LastChangedAt field as optimistic lock token

persistent table ZTABLE Database table where managed BO persists data

draft table ZDTTABLE Draft table for temporary draft storage

authorization master (instance) Enable instance-level authorization checks

field (readonly) Field cannot be changed by any operation

field (readonly: update) Field is read-only during update, writable on create

field (mandatory: create) Field must be provided on creation

action ... result [1] $self Instance action returning the same entity type

static action Action not bound to a specific instance

validation ... on save Validation executes just before commit

determination ... on modify Determination triggered by field change at runtime

determination ... on save Determination triggered during save sequence

side effects { field X affects field Y; } UI refresh hint: refresh Y when X changes

features: instance Feature control evaluated per instance (dynamic)

features: global Feature control same for all instances

early numbering Keys assigned at create time (before save)

late numbering Keys assigned during save sequence

Common EML Patterns

" ■■ Read one entity ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
READ ENTITIES OF ZI_TRAVEL IN LOCAL MODE
ENTITY Travel FIELDS ( TravelID AgencyID OverallStatus )
WITH VALUE #( ( TravelID = '00000001' ) )
RESULT DATA(result) FAILED DATA(failed).

For interview preparation and revision use only Page 30

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

" ■■ Create ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

MODIFY ENTITIES OF ZI_TRAVEL
ENTITY Travel CREATE FIELDS ( AgencyID CustomerID BeginDate EndDate )
WITH VALUE #( ( %cid = 'cid1' AgencyID = '070041' ... ) )
MAPPED DATA(mapped) FAILED DATA(failed) REPORTED DATA(reported).

" ■■ Update ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

MODIFY ENTITIES OF ZI_TRAVEL
ENTITY Travel UPDATE FIELDS ( OverallStatus )
WITH VALUE #( ( %tky = travel-%tky OverallStatus = 'A' ) ).

" ■■ Execute Action ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

MODIFY ENTITIES OF ZI_TRAVEL
ENTITY Travel EXECUTE acceptTravel
FROM VALUE #( ( %tky = travel-%tky ) )
RESULT DATA(action_result).

" ■■ Commit (triggers SAVE sequence) ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

COMMIT ENTITIES BEGIN OF RESPONSE OF ZI_TRAVEL
FAILED DATA(commit_failed) REPORTED DATA(commit_reported)
END OF RESPONSE.

" ■■ Rollback ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

ROLLBACK ENTITIES.

Critical RAP Naming Conventions

Artifact Convention Example

Interface CDS View ZI_ ZI_TRAVEL, ZI_BOOKING

Projection CDS View ZC_ ZC_TRAVEL, ZC_BOOKING

Value Help CDS View ZI__VH or ZI__StdVH ZI_AGENCY_VH

Behavior Definition Same as root CDS view name ZI_TRAVEL (bdef)

Behavior Pool (ABP) ZBP_ ZBP_TRAVEL

Draft Table ZDT or custom ZDTTRAVEL

Service Definition ZUI__O2 or _O4 ZUI_TRAVEL_O4

Service Binding ZUI__O2 or _O4 ZUI_TRAVEL_O4 (srvb)

Metadata Extension ZME_ ZME_TRAVEL

Access Control (DCL) Same as CDS view name ZI_TRAVEL (dcl)

Abstract Entity (param) ZD_A_ ZD_A_TRAVEL_COPY

For interview preparation and revision use only Page 31

SAP RAP — Complete Study Guide RESTful ABAP Programming Model

RAP Troubleshooting Quick Guide

• Problem: ETag mismatch error on save
Solution: Ensure LastChangedAt field is properly annotated with
@[Link]: true. Check that the determination updates this field.
ETag must be updated every time the entity is modified.
• Problem: Draft table not found
Solution: Verify the draft table name in BDEF matches an existing transparent table. The draft table must
have the same key fields as the persistent table plus the %pid and %is_draft fields. Use the standard
activation to auto-create it.
• Problem: Validation not triggered
Solution: Check the trigger condition in BDEF (create; update; etc.). Ensure the validation method
signature exactly matches the BDEF declaration in strict(2) mode. Check that the behavior pool is
correctly activated.
• Problem: Action button not visible in Fiori
Solution: Verify @[Link] or @[Link] annotation with type: #FOR_ACTION references the
correct action name. Check feature control — the action may be hidden due to instance/global features.
Ensure the action is declared in the BDEF.
• Problem: Authorization errors in production
Solution: Check DCL is active and correctly references the PFCG authorization object. Verify the user has
the correct roles. Check get_instance_authorizations handler returns correct authorization flags. Use
SU53 to find missing authorizations.
• Problem: Determination runs but data not saved
Solution: Determinations modify the transactional buffer but the COMMIT ENTITIES must be called to
persist. In Fiori apps, the framework handles this. In EML-based programs, ensure COMMIT ENTITIES
is called after MODIFY ENTITIES.

SAP RAP Complete Study Guide | Generated for Interview Preparation | SAP BTP & S/4HANA

For interview preparation and revision use only Page 32