Introduction
This blog is the first in a short series about extension and API stability in S/4HANA. In this post I’ll explain release contracts (also known as stability contracts) — what they are, why SAP uses them, and how they affect the objects you work with every day.
A Release Contract is a classification that indicates how stable a repository object is and how it can be used or extended. It’s SAP’s formal promise that certain objects will remain stable across upgrades. The goal is to strike a balance: on one hand, SAP keeps the system flexible so development can continue; on the other, key technical elements are kept stable so consumers don’t need to rewrite code after every upgrade.
To provide those guarantees, SAP defines different stability/release contracts (C0, C1, C2, …). Each contract describes the intended scope of use — for example, whether something is intended as a safe extension point, a stable in-system API, or a remote API for external callers.
Stability Contracts
C0 : Contract for Extensions
C1 : Contract for System Internal Use
C2 : Contract for Remote API Use
C3 : Manage Configuration Content
C4 : Use in ABAP Managed Database Procedure ( Not covered in this blog )
Let us look at how these Contracts apply to comman repository Objects.
CDS Views : CDS views are one of the most common repository objects you’ll come across in S/4HANA. SAP uses release contracts to make clear whether a CDS view can be extended, consumed inside the system, or even exposed to the outside world.
C0 – Extend
A C0 contract means the CDS view can be safely extendedThere are two main ways to extendKey user Extensibility : add your own custom fields (or sometimes even make standard fields available) using the Custom Fields app in FIORI.Developer Extensibility : Use ABAP Development Tools (ADT) to create a CDS view extension. This lets you add fields or annotations to the view in a controlled way.The promise here is that the structure of the view won’t change in a way that breaks your code across upgrades.
C1 – System Internal Use
A C1 contract means the CDS view is a stable API for internal consumption.
You can safely use a C1 released CDS in :Key user Extensibility : For Analytical Queries, Custom CDS ViewsDeveloper Extensibility : In Custom ABAP code in ABAP Cloud or S/4 HANA Cloud.In both cases, the base CDS view provides stable “anchors” where your extensions will survive upgrades.
C2 – Remote APIs
Sometimes the data in a CDS view isn’t just needed internally, but also by external systems.
In those cases, SAP exposes the CDS via an OData service (or other service binding).When a CDS view is published for remote consumption, it carries a C2 contract. This ensures the external API is technically stable for side-by-side or third-party integrations.
Database Tables : Database tables are the lowest-level repository objects in the system. In Practice SAP most often delivers these with C3 ( Manage Configuration Content ).
Tables can also be prepared by the provider for C0 ( Developer Extensibility ) using specific Annotation and release state settings – but this is an opt-in decision design. Most standard tables are not exposed this way , because SAP prefers that extensions happen via CDS views.
The release contract you’ll find for tables is C3 – Manage Configuration Content.
C3 – Manage Configuration Content
A C3 contract means the table is intended for storing configuration data (for example, customizing or setup values).With C3, SAP promises that the persistence and structure of the table will remain stable so that tools can reliably export, import, or transport configuration across systems.Why Not C0 or C1 for tables ?No C1: Tables are not meant to be consumed directly in ABAP Cloud development. If you need business data, you should always go through a released CDS viewC0 possible but rare : SAP does allow tables to be released with C0 if explicitly enabled by the provider (using annotations), but most delivered tables are not. Instead, SAP recommends CDS views or the Custom Fields app for extensibility.
Behavior Defination ( RAP Business Object ) : Behavior definitions describe what you can do with a business object in RAP (the RESTful ABAP Programming Model) — things like creating, updating, deleting, running validations, or triggering actions.
Unlike CDS views, most SAP-delivered behavior definitions are released with C1 (System-Internal Use). A C0 contract for behavior definitions is technically possible (the framework supports it if the provider enables extension anchors), but in practice it is rare. You should always check the API State in ADT to see what’s allowed.
C1 – System Internal Use
A C1 contract means the business object is safe to consume inside the system, but not open for developer extensions. You Can :Call the BO’s actions and operations in your own ABAP Cloud code.Bind the BO to a Fiori Elements app and use it in your custom applications.Rely on its structure to remain stable across upgrades.
Conclusion
This blog focused on SAP-delivered objects and how SAP marks their stability (C0–C3): CDS views (C0 for extension, C1 for in-system use, C2 for remote APIs), behavior definitions (generally C1 for consumption; C0 only if explicitly enabled), and database tables (commonly C3 for configuration; tables can also be prepared for C0, but that is opt-in).. Although there are other blogs that go deep into specific object types, this post is meant as a pre-read to give you the holistic view. And if you want to actually find released objects and their contracts, the magic lies in the System Library in ADT — and how you configure the tree.
IntroductionThis blog is the first in a short series about extension and API stability in S/4HANA. In this post I’ll explain release contracts (also known as stability contracts) — what they are, why SAP uses them, and how they affect the objects you work with every day.A Release Contract is a classification that indicates how stable a repository object is and how it can be used or extended. It’s SAP’s formal promise that certain objects will remain stable across upgrades. The goal is to strike a balance: on one hand, SAP keeps the system flexible so development can continue; on the other, key technical elements are kept stable so consumers don’t need to rewrite code after every upgrade.To provide those guarantees, SAP defines different stability/release contracts (C0, C1, C2, …). Each contract describes the intended scope of use — for example, whether something is intended as a safe extension point, a stable in-system API, or a remote API for external callers.Stability Contracts C0 : Contract for Extensions C1 : Contract for System Internal Use C2 : Contract for Remote API Use C3 : Manage Configuration Content C4 : Use in ABAP Managed Database Procedure ( Not covered in this blog )Let us look at how these Contracts apply to comman repository Objects.CDS Views : CDS views are one of the most common repository objects you’ll come across in S/4HANA. SAP uses release contracts to make clear whether a CDS view can be extended, consumed inside the system, or even exposed to the outside world.C0 – ExtendA C0 contract means the CDS view can be safely extendedThere are two main ways to extendKey user Extensibility : add your own custom fields (or sometimes even make standard fields available) using the Custom Fields app in FIORI.Developer Extensibility : Use ABAP Development Tools (ADT) to create a CDS view extension. This lets you add fields or annotations to the view in a controlled way.The promise here is that the structure of the view won’t change in a way that breaks your code across upgrades. C1 – System Internal UseA C1 contract means the CDS view is a stable API for internal consumption.You can safely use a C1 released CDS in :Key user Extensibility : For Analytical Queries, Custom CDS ViewsDeveloper Extensibility : In Custom ABAP code in ABAP Cloud or S/4 HANA Cloud.In both cases, the base CDS view provides stable “anchors” where your extensions will survive upgrades. C2 – Remote APIsSometimes the data in a CDS view isn’t just needed internally, but also by external systems.In those cases, SAP exposes the CDS via an OData service (or other service binding).When a CDS view is published for remote consumption, it carries a C2 contract. This ensures the external API is technically stable for side-by-side or third-party integrations. Database Tables : Database tables are the lowest-level repository objects in the system. In Practice SAP most often delivers these with C3 ( Manage Configuration Content ).Tables can also be prepared by the provider for C0 ( Developer Extensibility ) using specific Annotation and release state settings – but this is an opt-in decision design. Most standard tables are not exposed this way , because SAP prefers that extensions happen via CDS views.The release contract you’ll find for tables is C3 – Manage Configuration Content.C3 – Manage Configuration ContentA C3 contract means the table is intended for storing configuration data (for example, customizing or setup values).With C3, SAP promises that the persistence and structure of the table will remain stable so that tools can reliably export, import, or transport configuration across systems.Why Not C0 or C1 for tables ?No C1: Tables are not meant to be consumed directly in ABAP Cloud development. If you need business data, you should always go through a released CDS viewC0 possible but rare : SAP does allow tables to be released with C0 if explicitly enabled by the provider (using annotations), but most delivered tables are not. Instead, SAP recommends CDS views or the Custom Fields app for extensibility. Behavior Defination ( RAP Business Object ) : Behavior definitions describe what you can do with a business object in RAP (the RESTful ABAP Programming Model) — things like creating, updating, deleting, running validations, or triggering actions. Unlike CDS views, most SAP-delivered behavior definitions are released with C1 (System-Internal Use). A C0 contract for behavior definitions is technically possible (the framework supports it if the provider enables extension anchors), but in practice it is rare. You should always check the API State in ADT to see what’s allowed.C1 – System Internal UseA C1 contract means the business object is safe to consume inside the system, but not open for developer extensions. You Can :Call the BO’s actions and operations in your own ABAP Cloud code.Bind the BO to a Fiori Elements app and use it in your custom applications.Rely on its structure to remain stable across upgrades. ConclusionThis blog focused on SAP-delivered objects and how SAP marks their stability (C0–C3): CDS views (C0 for extension, C1 for in-system use, C2 for remote APIs), behavior definitions (generally C1 for consumption; C0 only if explicitly enabled), and database tables (commonly C3 for configuration; tables can also be prepared for C0, but that is opt-in).. Although there are other blogs that go deep into specific object types, this post is meant as a pre-read to give you the holistic view. And if you want to actually find released objects and their contracts, the magic lies in the System Library in ADT — and how you configure the tree. Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
