Architect / Cross-trackbeginner

RAP Basics Part 1: RAP Architecture — Layers, Artifacts and When RAP Fits

Key takeaway

The architect's map of the ABAP RESTful Application Programming Model: the data model (CDS), behavior (BDEF + behavior pool), projection, service definition and service binding, how a Fiori request flows through them, and when RAP is the right choice versus SEGW or classic development.

What this complete series covers

Learn RAP Basics in a clear, practical sequence — from the basic idea to real project use, troubleshooting, and interview-ready understanding.

Who it is for: Best for SAP consultants, developers, and learners who want a practical understanding of RAP Basics.
Prerequisites: Some SAP project experience is helpful because the series connects architecture decisions across applications, integration, clean core, data, and operations.
Final outcome: By the end, you should be able to explain RAP Basics clearly, follow the main end-to-end flow, apply it in a project scenario, and troubleshoot the most common issues.

Part 1: RAP Basics Part 1: RAP Architecture — Layers, Artifacts and When RAP Fits
Understand RAP as a layered business-object architecture: CDS models data, behavior defines transactional semantics, behavior pools implement logic, and service definition plus bin
Part 2: RAP Basics Part 2: Data Model Design — Tables, Keys, Administrative Fields and Interface Views
Choose managed RAP for framework-owned persistence and unmanaged RAP for existing business logic or custom save behavior, based on transaction ownership rather than preference.
Part 3: RAP Basics Part 3: Projection Layer and Metadata Extensions
Use RAP actions for explicit business commands, determinations for automatic derivation and validations for invariants, while returning instance-specific RAP messages and keeping logic bulk-safe.
Part 4: RAP Basics Part 4: Implementation Types — Managed, Unmanaged, Additional Save and Unmanaged Save
Choose managed RAP when framework-owned persistence fits a custom business object, and unmanaged RAP when existing APIs or legacy save logic must remain authoritative, based on tra
Part 5: RAP Basics Part 5: Root Entity, Child Entity and Composition
Model RAP aggregates with a root entity and composition children only when the child lifecycle is owned by the root, enabling coherent deep create, locking, draft and transactional save behavior.
Part 6: RAP Basics Part 6: Behavior Definition — CRUD, Field Control and Features
Use RAP behavior definitions to declare the business-object contract, including CRUD operations, field control, locks, authorization, actions and feature control, rather than codin
Part 7: RAP Basics Part 7: Actions, Determinations and Validations — Design Decisions
Use RAP actions for explicit business commands, determinations for automatic derivation and validations for rule enforcement, keeping each behavior type aligned to its trigger and
Part 8: RAP Basics Part 8: Service Definition, Service Binding and OData Exposure
Expose RAP business objects cleanly by separating the projection contract, service definition and service binding, so internal CDS entities stay private while UI or API consumers r
Part 9: RAP Basics Part 9: Behavior Implementation — Handler and Saver Classes
Implement RAP behavior in the behavior pool as set-oriented transactional logic that reads BO state, delegates domain rules and returns FAILED and REPORTED feedback without taking
Part 10: RAP Basics Part 10: EML — Entity Manipulation Language
Use RAP Entity Manipulation Language for type-safe ABAP access to RAP business objects, handling READ and MODIFY responses, MAPPED, FAILED and REPORTED results, and transaction boundaries correctly.
Part 11: RAP Basics Part 11: Draft, Locking and Authorization
Design RAP draft, locking and authorization as separate concerns: use draft only for long-lived incomplete edits, locks for concurrent modification control and backend authorizatio

System and release assumptions: Architecture guidance is release-aware and clean-core oriented. Exact product capabilities and supported extension points should be checked against the target SAP release.

Explanation

📌 KEY POINTS
✅ RAP is the standard SAP model for transactional apps and APIs in S/4HANA and BTP ABAP Environment: CDS for data, BDEF for behavior, service definition + binding for exposure.
✅ Every RAP business object (BO) is a stack of artifacts — tables, interface CDS views, BDEF, behavior pool, projection views, projection BDEF, service definition, service binding.
✅ The RAP framework (runtime) handles the OData protocol, transactional buffer, draft, locking and ETags — you write only business logic.
⚠️ RAP is not a replacement for every report: read-only analytics stay in CDS analytical models, mass background jobs stay in classic ABAP or application jobs.
💡 Architect rule: design the BO first (entities, keys, lifecycle), then the UI — not the other way round.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS
Part 1: RAP architecture, layers and when RAP fits
Part 2: Data model design — tables, keys, administrative fields, interface views
Part 3: Projection layer and metadata extensions
Part 4: Implementation types — managed, unmanaged, additional and unmanaged save
Part 5: Root entity, child entity and composition
Part 6: Behavior definition — CRUD, field control and features
Part 7: Actions, determinations and validations — design decisions
Part 8: Service definition, service binding and OData exposure
Part 9: Behavior implementation — handler and saver classes
Part 10: EML — Entity Manipulation Language
Part 11: Draft, locking and authorization

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHAT RAP IS

ABAP RESTful Application Programming Model: the programming model for Fiori apps and Web APIs on S/4HANA (on-premise from 1909, full in 2020+) and SAP BTP ABAP Environment.
It replaces the SEGW + DPC_EXT pattern for new transactional development.
It is the model SAP itself uses for new standard apps and released APIs (clean core).

━━━━━━━━━━━━━━━━━━━━
▶ 2. THE LAYERS

Data model: database tables + interface CDS view entities (ZI_*), connected by composition.
Behavior: behavior definition (BDEF) declares what the BO can do; behavior pool (class ZBP_*) implements the logic.
Projection: projection views (ZC_*) and projection BDEF select what one app or API may use.
Business service: service definition (which entities to expose) and service binding (protocol: OData V2/V4, UI or Web API).

━━━━━━━━━━━━━━━━━━━━
▶ 3. HOW A REQUEST FLOWS

Fiori sends an OData request (e.g. PATCH on a travel).
Service binding → service definition → projection → interface BO.
The RAP runtime puts the change in the transactional buffer, calls your determinations/validations, then saves in one LUW.
No DPC_EXT method is written for standard CRUD in a managed BO.

━━━━━━━━━━━━━━━━━━━━
▶ 4. WHEN RAP FITS

New Fiori transactional app on S/4HANA 2020+ → RAP.
New released API for integration → RAP (Web API binding).
Simple read-only list → CDS + UI annotations (RAP query without behavior), or analytical CDS.
Older release (ECC, S/4 1610/1709) → SEGW is still the tool.
Heavy legacy logic that must be reused → unmanaged RAP wrapping existing function modules/BAPIs (Part 4).

━━━━━━━━━━━━━━━━━━━━
▶ 5. ARCHITECT DECISIONS UP FRONT

BO boundaries: what is one lock unit (root + children)?
Keys: UUID (technical) or semantic (order number)?
Implementation type: managed or unmanaged?
Draft: needed for multi-step Fiori editing?
Exposure: UI service only, or also a Web API for integration?

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Write down the BO: root entity, child entities, key, lifecycle states.
Decide managed/unmanaged and draft.
Create tables, then interface views, then BDEF and behavior pool.
Create projection views and projection BDEF.
Create service definition and binding, publish, preview.

✅ CHECKPOINT: you can name all eight artifacts of a RAP BO and say which layer each belongs to.

Code example

ABAP Code

// ===== STEP 1: artifact map of one RAP BO (naming convention) =====// Table            ZTRAVEL_A        persistence of the root entity// Interface view   ZI_TRAVEL        data model, root view entity// BDEF             ZI_TRAVEL        behavior (managed implementation)// Behavior pool    ZBP_I_TRAVEL     ABAP class with local handler classes// Projection view  ZC_TRAVEL        app-specific projection// Projection BDEF  ZC_TRAVEL        which operations the app may use// Service def.     ZUI_TRAVEL       exposed entities// Service binding  ZUI_TRAVEL_O4    OData V4 - UI // ===== STEP 2: minimal root view entity =====@AccessControl.authorizationCheck: #CHECK@EndUserText.label: 'Travel - root'define root view entity ZI_Travel  as select from ztravel_a{  key travel_uuid     as TravelUUID,      travel_id       as TravelID,      agency_id       as AgencyID,      overall_status  as OverallStatus,      @Semantics.systemDateTime.localInstanceLastChangedAt: true      local_last_changed_at as LocalLastChangedAt} // ===== STEP 3: behavior definition (managed) =====managed implementation in class zbp_i_travel unique;strict ( 2 ); define behavior for ZI_Travel alias Travelpersistent table ztravel_alock masterauthorization master ( instance )etag master LocalLastChangedAt{  create; update; delete;  field ( readonly, numbering : managed ) TravelUUID;} // ===== STEP 4: service definition =====@EndUserText.label: 'Travel UI service'define service ZUI_TRAVEL {  expose ZC_Travel as Travel;}// Service binding ZUI_TRAVEL_O4 is created in ADT (OData V4 - UI) and published.

Real project scenario

A global pharma client wanted a Fiori app for field-sales sample requests on S/4HANA 2022. The first design from the team was SEGW with custom DPC_EXT code and a freestyle UI5 app — the pattern they knew from ECC. The architect reviewed it against the target: clean core, upgrade-safe, and a second consumer (a CRM integration) needing the same API. The team switched to a managed RAP BO with draft: one BO, two bindings (OData V4 UI for Fiori Elements, OData V4 Web API for the CRM). Standard CRUD needed no code; only three validations and one action were written. Build effort dropped by roughly 40% compared with the SEGW estimate, and the upgrade to 2023 needed no adaptation.

Common mistakes

Starting with the UI and deriving the data model from screens, producing a BO with the wrong lock boundary.
Choosing RAP for a pure read-only report where a CDS view with UI annotations would be enough.
Choosing SEGW on S/4HANA 2020+ for a new app "because the team knows it", creating new technical debt.
Putting business logic in the projection layer instead of the interface BO.
Forgetting that one BO can serve several consumers through several projections/bindings.

Best practices

Design the BO (entities, keys, lifecycle, lock unit) before creating any artifact.
Follow a naming convention (ZI_/ZC_/ZBP_/ZUI_/ZAPI_) across the project.
Keep business logic in the interface BO; projections only restrict and shape.
Use managed + draft as the default for new Fiori transactional apps; justify deviations.
Plan exposure: UI service and Web API as separate bindings on separate projections.

Interview angle

Questions: "Explain the RAP architecture", "Which artifacts make up a RAP business object?", "When would you not use RAP?"
Strong answer: names the layers (data model with CDS, behavior with BDEF and behavior pool, projection, service definition and binding), explains that the RAP runtime handles protocol, buffer, locking and draft, and gives clear decision criteria — RAP for new transactional apps and released APIs on S/4HANA 2020+ or BTP, SEGW for older releases, CDS analytics for read-only reporting. Architect-level candidates talk about BO boundaries and one BO serving multiple consumers.

Practice this lesson

Quick check

1. For a new transactional Fiori app on S/4HANA 2022, why is RAP generally preferred over SEGW?

2. Which requirement is the weakest fit for building a RAP business object?

3. Which pair of artifacts forms the business-service (exposure) layer of a RAP business object?

Interview questions

1. What is RAP in SAP ABAP?

Answer it in your own words first, then compare.

2. How does RAP fit S/4HANA Clean Core?