ABAP Cloud Part 7: Released APIs and Release Contracts

📌 KEY POINTS
✅ An object is usable in ABAP Cloud only if it is released for the right contract.
✅ C1 = use in cloud development / key user apps; C0 = extend; C2 = remote API; C3 = configuration content; C4 = use in AMDP.
✅ Deprecated APIs still work for now but have a successor — plan the switch.
💡 You can release your own objects (e.g. tier 2 wrappers) under C1 in ADT.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 1–6 kept saying "released". This part explains exactly what that means.

━━━━━━━━━━━━━━━━━━━━
▶ 1. VISIBILITY IS NOT PERMISSION
In a private cloud or on-premise system you can technically see and even call almost everything. In ABAP for Cloud Development, the compiler allows only objects released for the required use. The release status is part of the object's API state.

━━━━━━━━━━━━━━━━━━━━
▶ 2. THE RELEASE CONTRACTS

• C0 — Extend: the object may be extended (e.g. CDS views or tables that allow extension fields, BAdIs/enhancement points for extensions). SAP keeps extension points stable.
• C1 — Use System-Internally: the object may be used in ABAP Cloud code (and/or key user apps) in the same system. Most released CDS views, classes and RAP BO interfaces carry C1.
• C2 — Use as Remote API: the object is a stable remote interface, e.g. an OData or SOAP service, for side-by-side scenarios.
• C3 — Manage Configuration Content: for content used in configuration scenarios.
• C4 — Use in ABAP-Managed Database Procedures and Functions: the object may be accessed in AMDP.

Each contract defines which changes SAP may make: for C1, for example, SAP will not remove released elements or make incompatible changes to them.

━━━━━━━━━━━━━━━━━━━━
▶ 3. API STATES

• Released — use it.
• Deprecated — still released, but a successor exists; ADT shows a warning and the successor. Migrate before it is removed.
• Not released — not usable in ABAP Cloud (compiler error).

In ADT: open the object → Properties → API State; or look at the "Released Objects" tree in the Project Explorer.

━━━━━━━━━━━━━━━━━━━━
▶ 4. FINDING RELEASED APIS

• ADT Project Explorer → Released Objects (by type).
• SAP Business Accelerator Hub (api.sap.com).
• Cloudification Repository for successors of classic objects.

━━━━━━━━━━━━━━━━━━━━
▶ 5. RELEASING YOUR OWN OBJECTS
You can release your own objects:

• C1 for tier 2 wrappers so ABAP Cloud code can call them.
• C1/C0 for reusable components shared across teams (with stable interfaces).

In ADT: object Properties → API State → Add release contract; choose visibility (use in cloud development, key user apps). Once released, you commit to compatibility — treat it like a public API.

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

1. Open I_SalesOrder in ADT → Properties → API State: see the contracts.
2. Browse Released Objects for a class you need (e.g. number range, HTTP).
3. Release your wrapper ZCL_PR_REQUISITION_WRAPPER for C1 (use in cloud development).
4. Call it from an ABAP Cloud class — the syntax check now accepts it.

✅ CHECKPOINT: you understand release contracts and can publish your own stable APIs. RAP ABAP Cloud series complete.

Developers in a private cloud project argued that "we can see the table in SE11, so we may use it". The ABAP Cloud syntax check disagreed, and some developers started moving code to Standard ABAP to avoid the errors.
The architect explained release contracts with ADT's API State view, created a short list of commonly needed released objects, and released three tier 2 wrappers under C1 for real gaps. Code stayed in ABAP Cloud, and when SAP deprecated one API later, ADT showed the successor, and the switch took an afternoon.

• Equating technical visibility with permission.
• Confusing C1 (local use) with C2 (remote API).
• Ignoring deprecation warnings until removal.
• Releasing own objects without committing to compatibility.
• Moving code to Standard ABAP to bypass release checks.

• Check API state and contract before using any SAP object.
• Use ADT Released Objects, the Accelerator Hub and the Cloudification Repository.
• Migrate deprecated APIs to successors early.
• Release your own wrappers and reusable components deliberately (C1), with stable interfaces.
• Document released own objects and their consumers.

Questions: "What are release contracts?", "What does C1 mean?", "How do you release your own object for ABAP Cloud?"
Strong answer: release contracts define allowed usage and SAP's stability promise: C0 extend, C1 use system-internally (ABAP Cloud/key user), C2 remote API, C3 configuration content, C4 use in AMDP; API states include released, deprecated (with successor) and not released; own objects such as tier 2 wrappers are released via ADT API State (C1, use in cloud development), making their interface a contract.