RAP / CDS / ODataintermediate

ABAP Cloud Part 1: Released APIs, ATC and Clean Core

Key takeaway

Understand ABAP Cloud and clean core in practical terms: what changes for a developer, what "released API" means, how ATC enforces the rules, and what your first ABAP Cloud class looks like.

What this complete series covers

Learn ABAP Cloud from language restrictions and released APIs through ATC remediation, RAP architecture and on-stack versus side-by-side extensibility decisions.

Who it is for: Best for SAP consultants, developers, and learners who want a practical understanding of ABAP Cloud and Released APIs.
Prerequisites: Basic ABAP and ADT in Eclipse are recommended. The series explains the RAP/CDS/OData concepts as they are introduced.
Final outcome: By the end, you should understand how to build upgrade-stable ABAP Cloud extensions and how to replace unreleased dependencies.

Part 1: ABAP Cloud Part 1: Released APIs, ATC and Clean Core
Understand ABAP Cloud as a development model based on a restricted language scope, released APIs and upgrade-stable extension contracts rather than unrestricted access to SAP internals.
Part 2: ABAP Cloud Part 2: RAP and ABAP Cloud Architecture for Clean-Core Extensions
Design on-stack S/4HANA extensions with ABAP Cloud, released APIs and RAP so custom business objects and services remain upgrade-stable without forcing every extension to BTP.
Part 3: ABAP Cloud Part 3: Replacing Direct Table and Classic API Dependencies
Modernize classic ABAP by replacing internal SAP persistence and unreleased APIs with released CDS entities, business objects, classes and extension points.
Part 4: ABAP Cloud Part 4: ATC Readiness — Finding and Fixing Unreleased Usage
Use ATC as a continuous migration and governance control to find unsupported constructs and unreleased dependencies, prioritized by productive usage and business criticality.
Part 5: ABAP Cloud Part 5: On-Stack Developer Extension vs BTP Side-by-Side
Choose extension placement from transaction coupling, latency, lifecycle, technology and data gravity rather than a blanket on-stack or BTP rule.
Part 6: ABAP Cloud Part 6: Language Version, Syntax Restrictions and API Checks
Understand ABAP Cloud as the restricted, upgrade-stable ABAP development model built on the ABAP Cloud language version and released APIs.
Part 7: ABAP Cloud Part 7: Released APIs and Release Contracts
Treat released objects as explicit compatibility contracts and apply the same discipline when exposing custom APIs to other development teams.

System and release assumptions: Examples target recent SAP S/4HANA / ABAP Cloud capabilities. RAP, CDS, OData, and Fiori Elements syntax and tooling can differ by ABAP platform release.

Explanation

📌 KEY POINTS
✅ ABAP Cloud = a restricted development model: released language, released SAP APIs, RAP and CDS.
✅ Clean core = extensions that do not depend on SAP internals, so upgrades do not break them.
✅ Use only released SAP objects (e.g. I_ CDS views, released classes) — never SAP tables or unreleased FMs.
⚠️ "It compiles in Standard ABAP" does not mean "it is cloud-ready".

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS

Part 1 — released APIs, ATC and clean core (this lesson)
Part 2 — RAP and ABAP Cloud architecture for extensions
Part 3 — replacing direct table and classic API dependencies
Part 4 — ATC readiness: finding and fixing unreleased usage
Part 5 — on-stack developer extensibility vs BTP side-by-side
Part 6 — language version, syntax restrictions and API checks
Part 7 — released APIs and release contracts

━━━━━━━━━━━━━━━━━━━━
▶ WHY CLEAN CORE
Classic custom code reads SAP tables directly, calls internal function modules and modifies SAP objects. Every upgrade can break it, so upgrades become expensive projects. Clean core means: extensions use only stable, released interfaces. SAP guarantees those interfaces across upgrades, so extensions keep working.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT ABAP CLOUD IS
ABAP Cloud is the development model for clean-core extensions. It is used in SAP BTP ABAP environment, in S/4HANA Cloud Public Edition, and in S/4HANA Cloud Private Edition and on-premise (for "developer extensibility"). It consists of:

A language version: "ABAP for Cloud Development" — a restricted ABAP (no dynpros, no WRITE lists, no SUBMIT, no direct access to unreleased objects).
Released SAP APIs only: CDS views (I_…), RAP business object interfaces (…TP), classes and interfaces with a release contract.
Modern models: RAP for transactions and services, CDS for data, ABAP classes for logic.
Tooling: ADT (Eclipse), ATC checks, abapGit/gCTS.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT CHANGES FOR YOU AS A DEVELOPER

Instead of SELECT FROM vbak → SELECT FROM i_salesorder.
Instead of BAPI_… → EML on a released RAP BO interface, or a released wrapper.
Instead of reports with WRITE → RAP services with Fiori Elements, or console classes (if_oo_adt_classrun) for technical tests.
Instead of sy-uname/sy-datum → cl_abap_context_info.
Instead of SE38/SE80 → ADT only.

━━━━━━━━━━━━━━━━━━━━
▶ HOW RULES ARE ENFORCED

The syntax check of "ABAP for Cloud Development" objects rejects forbidden statements and unreleased objects.
ATC (ABAP Test Cockpit) with cloud readiness variants finds violations in existing code (Part 4).
In ADT, each SAP object shows its API state (released or not) in the Properties view.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP — YOUR FIRST ABAP CLOUD CLASS

In ADT, create a package with ABAP language version "ABAP for Cloud Development" (default in cloud systems).
Create class ZCL_FIRST_CLOUD implementing if_oo_adt_classrun (code example).
Try "SELECT FROM vbak" — the syntax check rejects it. Replace it with I_SalesOrder.
Run with F9.

✅ CHECKPOINT: you know what ABAP Cloud means and can write a first compliant class.

Code example

ABAP Code

" ===== A first ABAP Cloud class (language version: ABAP for Cloud Development) =====CLASS zcl_first_cloud DEFINITION PUBLIC FINAL CREATE PUBLIC.  PUBLIC SECTION.    INTERFACES if_oo_adt_classrun.        " console output in ADT (F9)ENDCLASS. CLASS zcl_first_cloud IMPLEMENTATION.  METHOD if_oo_adt_classrun~main.     " Released CDS view instead of table VBAK    SELECT SalesOrder, SalesOrganization, TotalNetAmount, TransactionCurrency      FROM i_salesorder      WHERE SalesOrganization = '1010'      ORDER BY SalesOrder DESCENDING      INTO TABLE @DATA(orders)      UP TO 5 ROWS.     " Released class instead of sy-uname / sy-datum    DATA(user)  = cl_abap_context_info=>get_user_technical_name( ).    DATA(today) = cl_abap_context_info=>get_system_date( ).     out->write( |User { user }, date { today }| ).    out->write( orders ).  ENDMETHOD.ENDCLASS. " ===== Rejected by the ABAP Cloud syntax check =====" SELECT * FROM vbak ...                      -> table not released" CALL FUNCTION 'BAPI_SALESORDER_GETLIST' ... -> function module not released" WRITE: / 'Hello'.                            -> list output not allowed" SUBMIT zreport.  CALL TRANSACTION 'VA03'.   -> not allowed" DATA(u) = sy-uname.                          -> use cl_abap_context_info

Real project scenario

A company's S/4HANA upgrade took nine months, mostly to adapt about 4,000 custom objects that read SAP tables and called internal function modules. For new development after the upgrade, the architecture board mandated ABAP Cloud for all new extensions.
Two years later, the next upgrade needed only small adjustments to the classic legacy objects; the roughly 300 new ABAP Cloud objects built on released APIs worked unchanged. The difference convinced management to fund a gradual migration of the most critical legacy extensions.

Common mistakes

Thinking ABAP Cloud only matters for public cloud.
Reading SAP tables because "the data is there".
Using sy-uname/sy-datum instead of cl_abap_context_info.
Writing reports with WRITE output for new development.
Ignoring the API state shown in ADT.
Using SE80 instead of ADT.

Best practices

Use ABAP for Cloud Development for all new extensions where possible.
Check the API state of every SAP object before using it.
Build transactional apps with RAP and read data via released CDS views.
Use console classes for technical tests.
Run ATC cloud checks continuously.

Interview angle

Questions: "What is ABAP Cloud?", "What does clean core mean for developers?", "What is a released API?"
Strong answer: ABAP Cloud is the clean-core development model: ABAP for Cloud Development language version, only released SAP APIs (CDS, RAP BO interfaces, classes), RAP and CDS as models, ADT tooling, enforced by syntax checks and ATC. It applies to BTP ABAP, S/4HANA Cloud and — for developer extensibility — private cloud and on-premise. Give concrete replacements: I_SalesOrder for VBAK, cl_abap_context_info for sy-uname.

Practice this lesson

Quick check

1. What is the typical released replacement for reading table VBAK in ABAP Cloud?

2. In ABAP for Cloud Development, how should code read the current user name?

3. Which statement is allowed in ABAP for Cloud Development?

Interview questions

1. What is ABAP Cloud, and what changes for a developer compared to classic ABAP?

Answer it in your own words first, then compare.

2. Describe how you would build a new custom approval app on S/4HANA in a clean-core way.