RAP — Restful Application Programming Model
SAP's modern ABAP framework for building OData V4 services and Fiori applications — the mandatory programming model for ABAP Cloud development, replacing classical ABAP Gateway and Dynpro.
RAP Architecture
Executive Summary
RAP (Restful Application Programming Model) is the mandatory programming model for building OData V4 services in ABAP Cloud. It replaces classical ABAP Gateway (SEGW), Dynpro, and Web Dynpro for all new development. RAP follows a strict layered architecture: CDS data models → Behaviour Definition (CRUD + actions + validations) → Service Definition → Service Binding (OData V4 endpoint). The generated OData V4 service can be consumed by Fiori Elements apps (auto-generated UI) or by CAP side-by-side extensions on BTP.
RAP Object Types
| Object | Tool / Extension | Purpose |
|---|---|---|
| Database Table | ABAP Dictionary | Persistence layer — stores business object data |
| CDS Interface View | ADT (.ddls.asddls) | Business object data model — pure data, no UI concerns |
| CDS Projection View | ADT (.ddls.asddls) | Service-specific projection with UI annotations |
| Behaviour Definition | ADT (.bdef.asbdef) | Declares CRUD operations, actions, and validations |
| Behaviour Implementation | ADT (ABAP class) | Implements the actual business logic |
| Service Definition | ADT (.srvd.assrvd) | Exposes CDS projections as a named service |
| Service Binding | ADT (.srvb.assrvb) | Binds the service to an OData V4 URL endpoint |
Step 1 — Database Table (ZDEWA_WORK_ORDER)
The ABAP Dictionary table is the physical persistence layer for a RAP business object. It includes standard administrative fields (created_by, changed_at) required by the managed scenario for automatic ETag and locking handling.
" Database table: ZDEWA_WORK_ORDER
@EndUserText.label : 'DEWA Work Order'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
define table zdewa_work_order {
key client : abap.clnt not null;
key work_order_id : sysuuid_x16 not null;
work_order_number : abap.char(10);
description : abap.char(250);
plant : /iwbep/v4_ddl_plant;
priority : abap.char(1);
status : abap.char(10);
assigned_technician : abap.char(12);
scheduled_date : abap.dats;
@Semantics.amount.currencyCode : 'currency'
estimated_cost : abap.curr(15,2);
currency : waers;
created_by : syuname;
created_at : timestampl;
last_changed_by : syuname;
last_changed_at : timestampl;
local_last_changed_at : timestampl;
}Step 2 — CDS Interface View (ZI_DEWA_WorkOrder)
@AccessControl.authorizationCheck: #CHECK — never #NOT_REQUIRED. It should contain only data model concerns — no UI annotations.@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'DEWA Work Order — Interface View'
define root view entity ZI_DEWA_WorkOrder
as select from zdewa_work_order
{
key work_order_id as WorkOrderId,
work_order_number as WorkOrderNumber,
description as Description,
plant as Plant,
priority as Priority,
status as Status,
assigned_technician as AssignedTechnician,
scheduled_date as ScheduledDate,
estimated_cost as EstimatedCost,
currency as Currency,
@Semantics.user.createdBy: true
created_by as CreatedBy,
@Semantics.systemDateTime.createdAt: true
created_at as CreatedAt,
@Semantics.user.lastChangedBy: true
last_changed_by as LastChangedBy,
@Semantics.systemDateTime.lastChangedAt: true
last_changed_at as LastChangedAt,
@Semantics.systemDateTime.localInstanceLastChangedAt: true
local_last_changed_at as LocalLastChangedAt
}Step 3 — Behaviour Definition
The Behaviour Definition file (.bdef) declares what operations the RAP business object supports: standard CRUD, custom actions, validations, and draft handling. This file is the contract between the service layer and the behaviour implementation.
" ZI_DEWA_WorkOrder.bdef
managed implementation in class zbp_i_dewa_workorder unique;
strict ( 2 );
with draft;
define behavior for ZI_DEWA_WorkOrder alias WorkOrder
persistent table zdewa_work_order
draft table zdewa_work_order_d
lock master total etag LastChangedAt
authorization master ( instance )
etag master LocalLastChangedAt
{
create;
update;
delete;
field ( readonly ) WorkOrderId, CreatedBy, CreatedAt, LastChangedBy, LastChangedAt;
field ( numbering : managed ) WorkOrderId;
" Custom actions
action assignTechnician parameter zd_work_order_assign result [1] $self;
action completeWorkOrder result [1] $self;
" Custom validations
validation validatePriority on save { create; update; }
validation validateScheduledDate on save { create; update; }
draft action Edit;
draft action Activate optimized;
draft action Discard;
draft action Resume;
draft determine action Prepare;
mapping for zdewa_work_order corresponding
{
WorkOrderId = work_order_id;
WorkOrderNumber = work_order_number;
Description = description;
Plant = plant;
Priority = priority;
Status = status;
AssignedTechnician = assigned_technician;
ScheduledDate = scheduled_date;
EstimatedCost = estimated_cost;
Currency = currency;
}
}DEWA Enterprise Implementation
- Custom RAP Business Objects
- 3
- OData V4 Endpoints Generated
- 3
- Fiori Elements Apps (auto-generated)
- 3
- CAP Extensions consuming RAP APIs
- 6
- AI Analytics consuming RAP OData
- 1
Best Practices
Always maintain distinct I_ (interface) and C_ (projection) views. Never expose the Interface View directly in the Service Definition — this pattern allows multiple projections (apps) per BO.
Choose managed RAP over unmanaged for all new business objects. SAP handles persistence, locking, and ETag management automatically — saving hundreds of lines of boilerplate code.
Enable draft handling for all transactional BOs. This prevents data loss when users navigate away or browsers crash before saving, and is required for any Fiori transactional app.
Add @ObjectModel, @UI, and @Search annotations on the CDS Projection View. These annotations drive auto-generation of the Fiori Elements app UI — no frontend code required.
Write ABAP Unit tests for every handler method (validate, action, determination). RAP behaviour code is complex and unit tests are the primary regression safety net.
Common Pitfalls
Security Considerations
@AccessControl.authorizationCheck: #CHECK and write CDS Access Control (DCL) objects for every entity. Test authorisation checks with restricted test users before go-live. Enable audit logging for all RAP modify operations on sensitive business objects (financial data, personal data). Never use #NOT_REQUIREDin production CDS views.