Introduction
In this blog, I am going to show how to use the ASAPIO Integration Add-on Clean Core Check as a proactive safeguard to ensure Clean Core compliance – without manually researching released objects, SAP Notes, or successor APIs.
The idea behind the Clean Core Check is simple: whenever a payload or outbound object is defined, the framework validates whether the used tables or objects are released for usage in SAP S/4HANA (especially in cloud-ready or clean core scenarios). If not, it automatically suggests alternative released CDS views.
In short: instead of discovering during an upgrade that a table like VBAK is not released, you detect it during design time – and receive a proposal such as I_SALESDOCUMENT as successor.
This approach requires the ASAPIO Integration Add-on and is particularly relevant in S/4HANA environments where unreleased objects must be avoided.
Why Clean Core matters
SAP’s Clean Core strategy aims to:
Reduce modification footprint Prevent direct access to non-released database tables Ensure upgrade stability Enforce usage of released APIs and CDS views
Many classical SAP tables (e.g. VBAK, VBKD, VEDA) are technically available but not released for direct usage in S/4HANA Cloud or Clean Core compliant developments.
Using them in custom extraction logic or event payloads creates technical debt and upgrade risk.
This is exactly where the ASAPIO Clean Core Check comes into play.
Example: Payload with classic SD tables
Let’s assume we defined a Sales Order payload in the ASAPIO Payload Designer (transaction /ASADEV/DESIGN).
We add the following tables:
VBAK – Sales Document Header VBPA – Partner Data VEDA – Contract Data VBKD – Business Data
The payload is configured and released.
Now, instead of discovering issues during a system conversion or ATC run, we execute the Clean Core Check directly in the Payload Designer.
Running the Clean Core Check
Inside the Payload Designer, simply click on the Clean Core Check button in the toolbar.
The framework evaluates all tables and objects used in the payload definition.
What happens here?
The system detects that VBAK, VBKD, and VEDA are not released objects It checks SAP’s released API model It proposes I_SALESDOCUMENT as an alternative CDS View It flags objects not listed in released content (e.g. VBPA)
This happens instantly.
Enabling the Clean Core Check
Before the Clean Core Check can be executed, the corresponding repository configuration must be maintained.
The check relies on the ASAPIO Clean Core repository, which contains the metadata about released and non-released SAP objects as well as successor CDS views.
To activate and configure the check properly, follow the official documentation:
https://asapio.com/docs/designer/?asl_highlight=clean&p_asid=1#use_clean_core_checks
Refactoring to released CDS views
After the Clean Core Check result, the next step is straightforward:
Remove the unreleased tables from the payload Replace them with the suggested CDS view Re-map the required fields
In our example, instead of selecting from VBAK directly, we use CDS View I_SALESDOCUMENT.
Benefits:
Released API contract Semantic layer abstraction Upgrade stability Cloud readiness Compliance with Clean Core guidelines
The payload can now be executed without violating SAP’s release strategy.
Summary
The ASAPIO Clean Core Check provides:
Immediate detection of non-released tables Automatic suggestion of released CDS alternatives Support for SAP Clean Core strategy Reduced upgrade risks Faster development cycles
Instead of reacting to ATC findings during system conversion, developers can proactively design compliant payloads from the beginning.
It shifts Clean Core validation directly into the design phase.
In other words:
Configuration-driven integration, now also Clean Core compliant.
Let me know if you would like to see a deeper technical walkthrough or how the check is implemented internally in the Add-on.
Introduction In this blog, I am going to show how to use the ASAPIO Integration Add-on Clean Core Check as a proactive safeguard to ensure Clean Core compliance – without manually researching released objects, SAP Notes, or successor APIs. The idea behind the Clean Core Check is simple: whenever a payload or outbound object is defined, the framework validates whether the used tables or objects are released for usage in SAP S/4HANA (especially in cloud-ready or clean core scenarios). If not, it automatically suggests alternative released CDS views. In short: instead of discovering during an upgrade that a table like VBAK is not released, you detect it during design time – and receive a proposal such as I_SALESDOCUMENT as successor. This approach requires the ASAPIO Integration Add-on and is particularly relevant in S/4HANA environments where unreleased objects must be avoided. Why Clean Core matters SAP’s Clean Core strategy aims to: Reduce modification footprint Prevent direct access to non-released database tables Ensure upgrade stability Enforce usage of released APIs and CDS views Many classical SAP tables (e.g. VBAK, VBKD, VEDA) are technically available but not released for direct usage in S/4HANA Cloud or Clean Core compliant developments. Using them in custom extraction logic or event payloads creates technical debt and upgrade risk. This is exactly where the ASAPIO Clean Core Check comes into play. Example: Payload with classic SD tables Let’s assume we defined a Sales Order payload in the ASAPIO Payload Designer (transaction /ASADEV/DESIGN). We add the following tables: VBAK – Sales Document Header VBPA – Partner Data VEDA – Contract Data VBKD – Business Data The payload is configured and released. Now, instead of discovering issues during a system conversion or ATC run, we execute the Clean Core Check directly in the Payload Designer. Running the Clean Core Check Inside the Payload Designer, simply click on the Clean Core Check button in the toolbar. The framework evaluates all tables and objects used in the payload definition. What happens here? The system detects that VBAK, VBKD, and VEDA are not released objects It checks SAP’s released API model It proposes I_SALESDOCUMENT as an alternative CDS View It flags objects not listed in released content (e.g. VBPA) This happens instantly. Enabling the Clean Core Check Before the Clean Core Check can be executed, the corresponding repository configuration must be maintained. The check relies on the ASAPIO Clean Core repository, which contains the metadata about released and non-released SAP objects as well as successor CDS views. To activate and configure the check properly, follow the official documentation: https://asapio.com/docs/designer/?asl_highlight=clean&p_asid=1#use_clean_core_checks Refactoring to released CDS views After the Clean Core Check result, the next step is straightforward: Remove the unreleased tables from the payload Replace them with the suggested CDS view Re-map the required fields In our example, instead of selecting from VBAK directly, we use CDS View I_SALESDOCUMENT. Benefits: Released API contract Semantic layer abstraction Upgrade stability Cloud readiness Compliance with Clean Core guidelines The payload can now be executed without violating SAP’s release strategy. Summary The ASAPIO Clean Core Check provides: Immediate detection of non-released tables Automatic suggestion of released CDS alternatives Support for SAP Clean Core strategy Reduced upgrade risks Faster development cycles Instead of reacting to ATC findings during system conversion, developers can proactively design compliant payloads from the beginning. It shifts Clean Core validation directly into the design phase. In other words: Configuration-driven integration, now also Clean Core compliant. Let me know if you would like to see a deeper technical walkthrough or how the check is implemented internally in the Add-on. Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
