For most SAP S/4HANA implementations, ABAP test cockpit (ATC) runs directly in the development system.
A developer activates an object or releases a transport task, ATC runs locally against the configured check variant, and findings appear in the result browser. This is the default model, and for many organizations, it’s the right one, provided the configuration behind it is correct.
Getting the configuration correct is where most organizations fall short, but not because they haven’t tried to configure ATC. The real culprit is that the gap between a configured ATC and a correctly configured ATC for clean core governance isn’t obvious until something tells you it’s wrong. The following sections address setup, how to recognize when setup is wrong, and then how to connect the correctly configured checks to the transport workflow.
The clean core level checks are available in SAP S/4HANA 2023 and 2025, but available doesn’t mean ready to use. On SAP S/4HANA 2023, the starting point is SAP Note 3565942. On both releases, that note alone isn’t sufficient. Systems below SAP S/4HANA 2023 can’t run these checks on-premise at all, which is the scenario where central ATC in SAP BTP becomes the only path to clean core level analysis. Understanding where a system sits against these thresholds is the first architectural question to answer before designing the ATC governance model.
Tip: After implementing SAP Note 3565942, run the note analyzer in SAP Note 3627152 before treating the ATC configuration as complete. The note analyzer identifies all dependent and correction notes required to make the clean core checks fully functional. A system where the primary note shows as fully implemented but the note analyzer hasn’t been run may still be producing incomplete or incorrect findings. This is the most common reason clean core level checks appear to be working but aren’t reporting correctly.
Implementing SAP Note 3565942 is necessary, but not sufficient. The note has manual steps associated with it, and those steps must be completed for the Cloudification Repository integration to function. The check variant must have the classicAPIDataSource parameter populated in the attributes of the Usage of APIs check under the Clean Core category. This parameter takes the URL of SAP’s object classifications JavaScript Object Notation (JSON) file hosted on GitHub. On SAP S/4HANA 2025, the releasedAPIDataSource parameter correctly defaults to checkedSystem, pulling released API information from the local system rather than GitHub. This assumes the note analyzer in SAP Note 3627152 has been run and all dependent notes are correctly applied. On a system where the note analyzer hasn’t been run, verify this behavior before treating the variant as correctly configured.
Both parameters are visible in the ATC Check Details panel in ADT when the Usage of Released APIs check is selected (see the figure below). The classicAPIDataSource URL must point to the objectClassifications_SAP.json file in SAP’s abap-atc-cr-cv-s4hc repository. Without it, the check runs, but classic API classifications aren’t evaluated correctly.
Note: Organizations in environments where GitHub access is restricted can’t use the standard Cloudification Repository URL directly. SAP delivers program SYCM_API_CLASSIFICATION_MANAGR to upload the classic API classification file locally. Run this program and provide the local filename as the value of the classicAPIDataSource check parameter in the check attributes.
A misconfigured or outdated ATC variant doesn’t fail in an obvious way. The checks run, findings are generated, and the result browser fills with results. The problem is that the results reflect the wrong framework. An organization running the old three-tier checks will see data elements and domains flagged as Priority 1 errors. Under the current clean core extension level framework, Data Dictionary (DDIC) object types, including data elements and domains, are explicitly excluded from findings. They don’t have an API release status that maps to the Level A through Level D classification. Seeing them in the Priority 1 results is the tell.
In a planning review session with TnX Manufacturing’s development leads, data elements were appearing as Priority 1 errors in the initial ATC run. The architecture team recognized the pattern immediately. A team running current clean core checks doesn’t see data elements at Priority 1. That observation prompted the question: Had the note analyzer been run after the note implementation? It had not. When the team ran the clean core note analyzer (SAP Note 3627152), additional missing notes surfaced.
Once those notes were applied and the Cloudification Repository URLs were correctly populated in both URL fields of the check attributes, the findings changed. Objects that had been generating Priority 1 errors under the old three-tier framework dropped to their correct classification under the current level model. The remediation backlog that had looked alarming was smaller and more accurately scoped than it had appeared.
TnX’s response was to make the clean core note analyzer check a recurring step in their ATC governance process and run it whenever SAP releases a new support package or when the architecture team becomes aware of updates to the clean core check stack. SAP updates SAP Note 3627152 when new or corrected checks are released, and the clean core note analyzer is the only reliable way to confirm the system has picked up those changes. A governance process that runs the note analyzer once at setup and never again isn’t a governance process.
With the correct checks in place, the next configuration decision is whether and how to connect ATC to the transport workflow. The transport gate is activated in Transaction ATC under Basic Settings by setting Object checks at request or task release to globally activated (see figure below). Once active, ATC runs automatically when a transport request is released and blocks the release if findings above the configured priority threshold are present.
SAP’s best practice recommendation is to block on Priority 1 and Priority 2 findings. This means Level D patterns (prohibited techniques and nonrecommended objects) and Level C patterns (internal SAP objects) are both blocking by default. Level B findings (classic APIs) produce Priority 3 information messages that aren’t blocking under this configuration. That threshold reflects the governance intent: Level D is never acceptable without a documented exception, Level C requires a conscious decision, and Level B is tracked but not blocked because classic APIs, while not ideal, carry a lower compliance risk profile.
Tip: By default, ATC blocking applies at transport request release, not task release. A developer can release individual tasks within a request without triggering ATC. SAP Note 2495410 adds task-level checking as an option. To configure it, go to Transaction SE03, select Global Customizing under Administration, set Object checks at request or task release to globally activated, and then check Task under Object checks (if activated) at release of. This adds overhead to every task release, so consider whether the governance benefit justifies the impact on developer workflow before enabling it in a large program.
Before moving to custom check design, let’s consider one point on scope. This post has focused on ATC governance for on-premise SAP S/4HANA and SAP S/4HANA Cloud Private Edition development. The same governance discipline applies to ABAP development in the SAP BTP ABAP environment. The ABAP Cloud language version enforced by the compiler handles clean core compliance automatically in that context. What it doesn’t handle is organization-specific standards: naming conventions, restricted patterns, or internal architectural rules. Those require a custom variant approach, configured and maintained in the SAP BTP system rather than in the on-premise landscape. An organization that governs ABAP development on-premise but leaves SAP BTP ABAP development ungoverned, has a gap.
An outdated ATC setup produces results that look just as convincing as a correct one, which makes it easy to trust findings that are steering your remediation work in the wrong direction. Keeping the checks accurate is ongoing work for your architecture team, with the note analyzer rerun each time SAP updates the clean core checks. If nobody has reviewed your check variant since the initial implementation, open your most recent ATC results and look for data elements flagged at Priority 1. Finding them means your backlog is probably sized against the wrong framework.
Editor’s note: This post has been adapted from a section of the book Clean Core for SAP: Extensibility and Upgrade Stability for SAP S/4HANA by Smitha Banda and Vani Krishnamoorthy. Smitha is a senior business development manager at SAP and the head of the SAP BTP practice for North America. Vani is a chief architect at SAP with more than two decades of experience.
This post was originally published 9/2026.