RAP / CDS / ODataadvanced

ABAP Cloud Part 2: RAP and ABAP Cloud Architecture for Clean-Core Extensions

Key takeaway

Design clean-core extensions with RAP and ABAP Cloud: the extensibility options, the layered architecture of an extension, and how SAP's three-tier model handles code that cannot yet be cloud-ready on private cloud and on-premise.

Explanation

📌 KEY POINTS
✅ Three extensibility options: key user (no code/low code), developer (on-stack ABAP Cloud), side-by-side (BTP).
✅ A RAP extension = your own BO + released SAP APIs + released extension points.
✅ On private cloud / on-premise, SAP's tier model separates cloud-ready code, released wrappers and classic code.
💡 Wrappers turn unreleased SAP functionality into a small, released, testable API.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 introduced ABAP Cloud. This part shows how a real extension is structured.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE EXTENSIBILITY OPTIONS

Key user extensibility — custom fields, custom logic in released BAdIs, custom CDS views via Fiori apps. For simple needs; no developer tools.
Developer extensibility (on-stack) — ABAP Cloud in ADT, in the same system as S/4HANA. For custom apps, custom BOs, logic close to SAP data.
Side-by-side extensibility — separate application on SAP BTP (ABAP environment, CAP), connected via released remote APIs and events. For decoupled scenarios (Part 5).

━━━━━━━━━━━━━━━━━━━━
▶ 2. ANATOMY OF AN ON-STACK RAP EXTENSION
Example: a custom purchase request pre-approval app that later creates SAP purchase requisitions.

Own persistence and RAP BO: ZPR_HEAD/ZPR_ITEM, ZR_PurchReq, behavior pool — fully ABAP Cloud.
Read SAP data through released CDS views: I_Supplier, I_Product, I_CostCenter (names as examples; check availability).
Change SAP data through released RAP BO interfaces via EML (e.g. a released purchase requisition BO interface) — not BAPIs.
React to SAP processes through released BAdIs or business events.
Expose through RAP services (UI and Web API).

━━━━━━━━━━━━━━━━━━━━
▶ 3. WHAT IF SOMETHING IS NOT RELEASED? — THE TIER MODEL
On S/4HANA private cloud and on-premise, SAP recommends a layered model (often called the three-tier model):

Tier 1 — ABAP Cloud: all new development; only released APIs.
Tier 2 — cloud API enablement: small wrapper classes in Standard ABAP that call unreleased SAP functionality (e.g. a BAPI) and are themselves released for use in cloud development (C1). Tier 1 code calls the wrapper, never the BAPI.
Tier 3 — classic ABAP: existing legacy code, not changed now, migrated over time.

When SAP later releases an API, you replace the wrapper — tier 1 code does not change.
⚠️ WATCH OUT: wrappers must stay thin: a clear interface, no business logic, no UI, full error handling.

━━━━━━━━━━━━━━━━━━━━
▶ 4. DESIGN RULES

Business logic in tier 1 (RAP BO, classes).
One wrapper per missing capability, not one per caller.
Document every wrapper with the unreleased API it hides and the planned replacement.
Keep own persistence separate from SAP tables.

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

List the SAP data you read and change.
For each: find a released CDS view / RAP interface / class (Business Accelerator Hub, ADT API state).
Missing? → design a tier 2 wrapper (code example) and release it for cloud development.
Build the RAP BO in tier 1 on top.

✅ CHECKPOINT: you can draw the architecture of a clean-core extension.

Code example

ABAP Code

" ===== Tier 2: thin wrapper (Standard ABAP), released for use in cloud development =====" Package language version: Standard ABAP" Object API state: Released for "Use in Cloud Development" (contract C1)CLASS zcl_pr_requisition_wrapper DEFINITION PUBLIC FINAL CREATE PUBLIC.  PUBLIC SECTION.    TYPES: BEGIN OF ty_item,             material TYPE c LENGTH 40,             quantity TYPE p LENGTH 13 DECIMALS 3,             unit     TYPE c LENGTH 3,             plant    TYPE c LENGTH 4,           END OF ty_item,           ty_items TYPE STANDARD TABLE OF ty_item WITH EMPTY KEY.     "! Creates a purchase requisition; returns its number or raises an exception    METHODS create      IMPORTING items         TYPE ty_items      RETURNING VALUE(number) TYPE string      RAISING   zcx_pr_wrapper.ENDCLASS. CLASS zcl_pr_requisition_wrapper IMPLEMENTATION.  METHOD create.    " calls the unreleased classic API here (e.g. a BAPI), maps messages,    " raises zcx_pr_wrapper on error. No business logic, no UI.  ENDMETHOD.ENDCLASS. " ===== Tier 1: ABAP Cloud code uses the wrapper, never the BAPI =====" (e.g. in the saver or an action of ZBP_R_PURCHREQ, respecting the RAP LUW:"  the wrapper must not COMMIT - posting runs in the RAP save phase)"   DATA(pr_number) = NEW zcl_pr_requisition_wrapper( )->create( items ). " ===== Preferred: released RAP BO interface via EML (when available) ====="   MODIFY ENTITIES OF <released purchase requisition BO interface> ..."   -> replace the wrapper as soon as a released interface exists " ===== Architecture overview =====" Tier 1  ZR_PurchReq (RAP BO), ZC_ projections, services  - ABAP Cloud"         reads: I_Supplier, I_Product (released CDS)" Tier 2  zcl_pr_requisition_wrapper (Standard ABAP, released C1)" Tier 3  existing classic reports/FMs - migrated later

Real project scenario

A team building a new approval app on S/4HANA private cloud needed to create purchase requisitions, but the classic BAPI was not released for cloud development, and the team's first draft called it directly from RAP code in Standard ABAP.
The architect introduced a tier-2 wrapper with a five-parameter interface, released it for cloud development and kept all business logic in the ABAP Cloud RAP BO. When a released RAP interface for purchase requisitions became available in a later release, only the wrapper's usage was replaced; the rest of the app did not change.

Common mistakes

Writing all new code in Standard ABAP "because something is not released".
Fat wrappers containing business logic or UI.
One wrapper per caller instead of per capability.
Wrappers that commit inside the RAP LUW.
Not documenting which unreleased API a wrapper hides.
Choosing side-by-side when the logic needs tight transactional coupling with SAP data.

Best practices

Default to tier 1 (ABAP Cloud); use tier 2 wrappers only for gaps.
Keep wrappers thin, released (C1), documented and tested.
Prefer released RAP BO interfaces and released CDS views.
Choose the extensibility option per requirement (key user, developer, side-by-side).
Review tier 2 wrappers after each upgrade for newly released replacements.

Interview angle

Questions: "What extensibility options exist in S/4HANA?", "How do you build a clean-core extension that needs an unreleased API?", "What is the three-tier model?"
Strong answer: key user, developer (on-stack ABAP Cloud) and side-by-side (BTP) extensibility; an on-stack extension combines a RAP BO with released CDS views, released RAP interfaces via EML and released BAdIs/events; for gaps on private cloud/on-premise use tier 2 wrappers released for cloud development, keeping tier 1 clean, and replace them when SAP releases APIs.

Practice this lesson

Quick check

1. Which scenario fits a side-by-side extension on SAP BTP best?

2. A custom wrapper selects an unreleased SAP table and is used by many programs. What is the main clean-core concern?

3. A clean-core extension on S/4HANA private cloud needs a BAPI that is not released. What is the recommended approach?

Interview questions

1. What is the three-tier extensibility model and how do you keep tier 2 healthy?

Answer it in your own words first, then compare.

2. You inherit a "clean core" project. What do you check to confirm it really is clean core?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.