Gates on ABAP transports

The cheapest place to stop a bad ABAP change is before it leaves the development system. Two SAP tools do most of the work there: the ABAP Test Cockpit (ATC), which runs static checks such as syntax, performance, security and clean core checks, and ABAP Unit, the built-in framework for developer tests. ABAP's own programming guidelines recommend integrating the ATC check directly into transport release and making sure an ATC run covers all involved objects with no messages before release.

ATC on transport release

ATC is configured centrally in transaction ATC. Its settings determine the global check variant, which checks run and with which priorities, and how release of transport requests behaves. With the transport check activated, the system runs ATC in the background on the objects in the request when it is released, and a request with blocking findings cannot be released. In the Transport Organizer's global settings (SE03), object checks can be switched on for request release and, optionally, for task release; one SAP Press guide notes that task-level checking comes with SAP Note 2495410 and adds overhead to every task release. A commonly recommended threshold blocks priority 1 and 2 findings and lets priority 3 through as information.

ABAP Unit in the gate

ABAP Unit tests can run on their own from the development tools and as part of an ATC run: the check variant can include ABAP Unit under dynamic tests, so failing unit tests become ATC findings. That turns developer tests into a release gate without a separate tool. Two practical points matter. First, unit tests must be fast and isolated, using test doubles for database access and dependencies, or they make the release slow and flaky. Second, ABAP Unit runs in development and test systems, not in production.

Legacy code: baselines and exemptions

Turning on a blocking gate in a mature system creates a problem: existing code has thousands of old findings, and every developer who touches an old program inherits them. ATC addresses this with a baseline, which suppresses the recorded findings for as long as each finding itself is unchanged, even when other lines of the same object are edited (new findings, and findings in statements a developer changes, are reported again), and with exemptions, which approve a specific finding with a justification. Both keep the gate focused on new problems, but neither should become permanent. Treat the baseline like a set of exemptions: review it every release, give each part of it an owner and an expiry date, and expect it to shrink. The exemption process should have a named approver, a reason and an expiry, with exemptions kept narrow and time-boxed (see sap-abp-204), so neither exemptions nor the baseline accumulate silently.

For clean core, SAP S/4HANA 2023 and 2025 provide ATC checks that classify code by the clean core levels, including checks on the use of released and classic APIs. A clean core check variant can run in the same release gate, so new code that uses non-released objects is flagged before it reaches quality. See sap-abp-301 for the levels themselves.