Lesson 3 of 5
Released APIs and release contracts
9 min
Listen to this lesson
A released API is a repository object that SAP has classified with a release contract. SAP's keyword documentation defines the contract as the prerequisite for using an object from a restricted language version, ensuring stability of its consistency and compatibility, and notes that SAP checks compliance for its own objects with special ATC checks. In practice: if SAP releases I_Country under a contract, SAP's own development is blocked from changing it incompatibly.
The five contracts
| Contract | SAP’s name | What it guarantees | Typical object |
|---|---|---|---|
| C0 | Extend | Stability at dedicated extension points | A CDS view or table you may extend with fields |
| C1 | Use System-Internally | Stable public interface for use inside the system; optional components may be added later | Released CDS views and classes used by your code |
| C2 | Use as Remote API | Like C1, and external consumers need no adjustment after an upgrade | OData services consumed from outside |
| C3 | Manage Configuration Content | Stable persistence for configuration content; key fields unchanged | Tables behind business configuration tools |
| C4 | Use in AMDP | Stable interface for ABAP-managed database procedures; no changes at all | Objects used inside AMDP methods |
Release contracts as defined in SAP’s ABAP keyword documentation.
Two details matter for testers and reviewers. C1 allows SAP to add optional components later, so code that copies a whole released structure by position can still be surprised; type your variables with the API's own types, as SAP's cheat sheet advises. And a released object can later be deprecated: the API lists in the keyword documentation show the state, Released or Deprecated, and name a successor. Deprecated APIs still work for a while, but new code should use the successor.
- Release NSAP releases a view with C1Contoso’s deposit app reads it, typed with the view’s own types
- Release N+1SAP adds an optional fieldAllowed under C1; Contoso’s code is unaffected because it never relied on the field list by position
- Release N+2SAP deprecates the viewThe API state names a successor; the old view still works
- Next changeContoso moves to the successorKenji’s team checks API states each release and switches during normal work, with tests
Local and remote
SAP Learning distinguishes local APIs, such as released classes and CDS views consumed inside the system by custom code and BAdI implementations, from remote APIs, such as OData or SOAP services for consumers outside, like an app on SAP BTP. Local extension points, mainly BAdIs, are how you plug logic into SAP processes. Contoso's deposit app uses local APIs; a future fleet portal on SAP BTP would use remote ones.
Releasing your own APIs
Contracts are not only for SAP objects. When one of your software components must use objects from another, SAP's BTP documentation recommends exposing them as released APIs, with software component relations as the weaker alternative that grants access without a stability guarantee. Kenji's team releases its core return CDS interface view with contract C1 so a later analytics component can build on it without depending on internals. Releasing your own object is a promise, too: incompatible changes are then flagged by checks.
What would you do?
Kenji's developer finds a released class with contract C1 that does exactly what the deposit app needs, but its API State shows Deprecated with a named successor. What should the developer do?
- A release contract is the prerequisite for using an object from ABAP Cloud.
- C0 extend, C1 use system-internally, C2 use as remote API, C3 manage configuration content, C4 use in AMDP.
- Check API State in ADT; deprecated APIs name a successor.
- Find APIs in the Released Objects tree, the Business Accelerator Hub and the Cloudification Repository.
- Release your own reusable objects (for example C1) instead of exposing internals.
Check your understanding · not graded
Lesson check
1. Which release contract covers use of an object by your own code inside the system?
2. Which contract ensures stability at dedicated extension points?
3. What does SAP list next to a deprecated API?
4. Which source lists SAP’s remote APIs, events and BAdIs by product?