Object Release State in Cloudification Repository Viewer for Clean Core Extensibility

Object Release State in Cloudification Repository Viewer for Clean Core Extensibility
Estimated read time 11 min read

Introduction

The updated Clean Core Extensibility whitepaper was introduced in August 2025 by SAP as an evolution of the 3-Tier Extensibility concept. This updated the 3-Tier Extensibility to a more detailed assessment of classic ABAP extensions based on the clean core level concept, allowing you as SAP customers and partners stepwise transformation to clean core at your own pace.

While using external APIs in your ABAP custom code, one of the first things to check as per the updated level concept is the release state of that API in the Cloudification Repository Viewer. The release state tells you how stable the object is, what contractual guarantee SAP provides for it, and how your ATC checks will treat any usage of it. Getting this right is important because it directly affects your clean core compliance and your upgrade readiness.

SAP categorizes all objects in the Cloudification Repository Viewer into five distinct states. Each state carries a specific meaning for your custom code, and knowing the difference will help you make better decisions when selecting or replacing APIs.

The Five Release States in the Cloudification Repository Viewer

Here is what each state means in practice and what you should do when you encounter it.

Released

A Released API is one that SAP has formally published with a stability contract. Backward compatibility is guaranteed across upgrades, so you can build on these objects with confidence. Released APIs correspond to clean core Level A.

Level A objects are 100% Cloud compliant, 100% Clean core, can be achieved On-Stack, Side-by-Side or Hybrid.

If you are starting new development, Released APIs are your first choice. They represent the safest and most future-proof option available to you.

Deprecated

A Deprecated API was once Released but SAP is now phasing it out. It still functions today, but it has a planned end of life. SAP recommends that you do not start any new development on it.

If your existing code already uses a Deprecated object, that code is treated as clean core Level B and flagged as Priority 3 in ATC checks. Make sure to identify the successor API in the Cloudification Repository or the SAP Business Accelerator Hub and plan your migration. The sooner you move away from a Deprecated API, the less remediation work you will face when the object reaches its end-of-life date.

Classic API

Classic APIs are well-known, time-tested objects such as BAPIs and RFC-enabled function modules that SAP product experts nominated before a formal release process existed. They do not carry a formal stability contract, but they are upgrade stable and widely used across the SAP ecosystem.

Classic APIs correspond to clean core Level B and are flagged as Priority 3 in ATC checks. Keep in mind that while these objects are stable in practice, they do not carry the same forward-compatibility guarantee as Released APIs. Use them when no Released alternative is available and check the Cloudification Repository Viewer for the availability of the Released APIs as successors to Classic APIs.

Not to be Released

An API marked as Not to be Released is one that SAP has explicitly decided is not intended for external use. Any exemption for using such an object must include a migration plan toward a Released API.

These objects correspond to clean core Level C depending on the context and are flagged as Priority 2 in ATC checks. If you encounter this state, treat it as a signal to find a supported alternative as quickly as possible.

No API

An object classified as No API has no API contract whatsoever. Objects classified as noAPI must not be used, creates maximum technical debt.

This state is flagged as Priority 1 in ATC checks and must be addressed at the highest priority. If you find a noAPI object in your custom code, replacing it with a Released API must be your immediate next step.

Why Some APIs Are Listed as Both Released and Classic or Not to be Released and Classic

You may come across a scenario in the Cloudification Repository Viewer where the same API appears under both the Classic API and Released API categories or Not to be Released and Classic. This is a valid situation and worth understanding, because it can cause some confusion at first glance.

 

Take the CDS view I_EARMARKEDFUNDSDOCUMENTITEM as an example. If you check this object in the Cloudification Repository Viewer for the 2022 SP0 release of SAP Cloud ERP Private, it is listed only as a Classic API. When you switch to the 2025 FPS01 release, it appears as both Classic API and Released API.

 

 

What this tells you is that I_EARMARKEDFUNDSDOCUMENTITEM was formally Released in the 2025 FPS0 release of SAP Cloud ERP Private.

Both statuses are equally valid for this object. It carries the historical stability of a Classic API and now also has a formal stability contract as a Released API. In this case, the clean core status will be Level A as Released API will take the precedence and ATC check will not give any message.

Similarly, take the Class CL_HTTP_UTILITY as an example. If you check this object in the Cloudification Repository Viewer for the 2022 SP0 release of SAP Cloud ERP Private, it is listed only as a Classic API. When you switch to the 2025 FPS0 release, it appears as both Classic API and Not to be Released, with a successor.

Both statuses are equally valid for this object. It carries the historical stability of a Classic API and now also has a formal stability contract as a Not to be Released, with a successor.

In this case, the clean core status will be Level B as Classic API will take the precedence and ATC check will give a Priority 3 message. You are recommended to move to the successor API in this case.

This is why it is recommended to check the Cloudification Repository Viewer against the specific release you are working with.

Conclusion

The Cloudification Repository Viewer continues to grow with each release as SAP adds more objects and updates their states. Use it as your starting point before selecting any API in your custom code. Checking the release state upfront will save you significant remediation work during upgrade cycles and help you stay clean core compliant from day one.

We will continue to share updates on clean core extensibility as the tooling and API landscape evolves. In the meantime, refer to the Cloudification Repository Viewer and the SAP Business Accelerator Hub for the latest state of the objects relevant to your development.

 

​ IntroductionThe updated Clean Core Extensibility whitepaper was introduced in August 2025 by SAP as an evolution of the 3-Tier Extensibility concept. This updated the 3-Tier Extensibility to a more detailed assessment of classic ABAP extensions based on the clean core level concept, allowing you as SAP customers and partners stepwise transformation to clean core at your own pace.While using external APIs in your ABAP custom code, one of the first things to check as per the updated level concept is the release state of that API in the Cloudification Repository Viewer. The release state tells you how stable the object is, what contractual guarantee SAP provides for it, and how your ATC checks will treat any usage of it. Getting this right is important because it directly affects your clean core compliance and your upgrade readiness.SAP categorizes all objects in the Cloudification Repository Viewer into five distinct states. Each state carries a specific meaning for your custom code, and knowing the difference will help you make better decisions when selecting or replacing APIs.The Five Release States in the Cloudification Repository ViewerHere is what each state means in practice and what you should do when you encounter it.ReleasedA Released API is one that SAP has formally published with a stability contract. Backward compatibility is guaranteed across upgrades, so you can build on these objects with confidence. Released APIs correspond to clean core Level A.Level A objects are 100% Cloud compliant, 100% Clean core, can be achieved On-Stack, Side-by-Side or Hybrid.If you are starting new development, Released APIs are your first choice. They represent the safest and most future-proof option available to you.DeprecatedA Deprecated API was once Released but SAP is now phasing it out. It still functions today, but it has a planned end of life. SAP recommends that you do not start any new development on it.If your existing code already uses a Deprecated object, that code is treated as clean core Level B and flagged as Priority 3 in ATC checks. Make sure to identify the successor API in the Cloudification Repository or the SAP Business Accelerator Hub and plan your migration. The sooner you move away from a Deprecated API, the less remediation work you will face when the object reaches its end-of-life date.Classic APIClassic APIs are well-known, time-tested objects such as BAPIs and RFC-enabled function modules that SAP product experts nominated before a formal release process existed. They do not carry a formal stability contract, but they are upgrade stable and widely used across the SAP ecosystem.Classic APIs correspond to clean core Level B and are flagged as Priority 3 in ATC checks. Keep in mind that while these objects are stable in practice, they do not carry the same forward-compatibility guarantee as Released APIs. Use them when no Released alternative is available and check the Cloudification Repository Viewer for the availability of the Released APIs as successors to Classic APIs.Not to be ReleasedAn API marked as Not to be Released is one that SAP has explicitly decided is not intended for external use. Any exemption for using such an object must include a migration plan toward a Released API.These objects correspond to clean core Level C depending on the context and are flagged as Priority 2 in ATC checks. If you encounter this state, treat it as a signal to find a supported alternative as quickly as possible.No APIAn object classified as No API has no API contract whatsoever. Objects classified as noAPI must not be used, creates maximum technical debt.This state is flagged as Priority 1 in ATC checks and must be addressed at the highest priority. If you find a noAPI object in your custom code, replacing it with a Released API must be your immediate next step.Why Some APIs Are Listed as Both Released and Classic or Not to be Released and ClassicYou may come across a scenario in the Cloudification Repository Viewer where the same API appears under both the Classic API and Released API categories or Not to be Released and Classic. This is a valid situation and worth understanding, because it can cause some confusion at first glance. Take the CDS view I_EARMARKEDFUNDSDOCUMENTITEM as an example. If you check this object in the Cloudification Repository Viewer for the 2022 SP0 release of SAP Cloud ERP Private, it is listed only as a Classic API. When you switch to the 2025 FPS01 release, it appears as both Classic API and Released API.  What this tells you is that I_EARMARKEDFUNDSDOCUMENTITEM was formally Released in the 2025 FPS0 release of SAP Cloud ERP Private.Both statuses are equally valid for this object. It carries the historical stability of a Classic API and now also has a formal stability contract as a Released API. In this case, the clean core status will be Level A as Released API will take the precedence and ATC check will not give any message.Similarly, take the Class CL_HTTP_UTILITY as an example. If you check this object in the Cloudification Repository Viewer for the 2022 SP0 release of SAP Cloud ERP Private, it is listed only as a Classic API. When you switch to the 2025 FPS0 release, it appears as both Classic API and Not to be Released, with a successor.Both statuses are equally valid for this object. It carries the historical stability of a Classic API and now also has a formal stability contract as a Not to be Released, with a successor.In this case, the clean core status will be Level B as Classic API will take the precedence and ATC check will give a Priority 3 message. You are recommended to move to the successor API in this case.This is why it is recommended to check the Cloudification Repository Viewer against the specific release you are working with.ConclusionThe Cloudification Repository Viewer continues to grow with each release as SAP adds more objects and updates their states. Use it as your starting point before selecting any API in your custom code. Checking the release state upfront will save you significant remediation work during upgrade cycles and help you stay clean core compliant from day one.We will continue to share updates on clean core extensibility as the tooling and API landscape evolves. In the meantime, refer to the Cloudification Repository Viewer and the SAP Business Accelerator Hub for the latest state of the objects relevant to your development.   Read More Technology Blog Posts by SAP articles 

#SAP

#SAPTechnologyblog

Avatar for

You May Also Like

More From Author