ATC is the gatekeeper now
The ABAP Test Cockpit used to be advice you could ignore. In the clean-core era, it's a gate: ATC checks run in CI, block transports, and decide whether your code ships. Understanding its findings isn't optional anymore.
The good news: most ATC findings come from a small set of repeatable patterns. Learn the common ones and you'll write check-clean code by habit.
The findings you'll see most
1. Obsolete statements. Header lines, TABLES, OCCURS, COMPUTE without intent — the language moved on. The fix is mechanical: modern declarations, inline @DATA, table expressions.
2. Unreleased API usage. Calling function modules, classes, or tables SAP hasn't released. In cloud development this is a hard error. The fix: find the released successor in the API catalog — or raise the gap with SAP instead of routing around it.
3. SQL strictness violations. Missing @ escapes, SELECT * without justification, implicit work areas. Mechanical fixes, every one.
4. Security findings. SQL injection risks from unescaped dynamic input, missing authorization checks, unsafe deserialization. These deserve real attention — they're the findings that prevent actual incidents.
Treat security findings as bugs, style findings as hygiene. Both need fixing, but a SQL injection finding outranks a naming-convention finding in every triage.
Reading a finding properly
Every ATC finding carries three things: the rule violated, the location, and a priority. Click through to the rule documentation before "fixing" — half of all bad fixes come from misunderstanding what the rule actually requires.
Example: a "dynamic SELECT" security finding doesn't mean dynamic SQL is banned — it means the dynamic parts must be validated or escaped. The precise fix beats the panicked rewrite.
Exemptions: the honest escape hatch
Sometimes the rule is wrong for your case — a legacy interface you can't change, a justified dynamic access. ATC supports exemptions with justification:
- Exempt the specific finding, not the whole check.
- Write a real justification — "legacy, will refactor in Q2" beats "needed."
- Set an expiry where the tooling allows. Permanent exemptions rot.
- Get exemptions reviewed. A second pair of eyes catches "exempt because lazy."
An exemption is a documented decision, not a way to silence the tool. If you can't write the justification in one honest sentence, fix the code instead.
Making ATC painless
- Run checks in ADT as you code — the sooner a finding appears, the cheaper the fix.
- Fix the codebase's top-3 findings first. Pareto applies: a few rules generate most findings.
- Put ATC in CI with zero-tolerance for new findings. Legacy findings get a burn-down plan; new code ships clean.
- Share the cheat sheet. When your team hits the same finding five times, document the canonical fix once.
ATC isn't the enemy — it's the reviewer who never sleeps, never gets tired, and catches the things code review misses. Make it your ally early and it stops feeling like a gate.
Which ATC finding haunts your codebase the most? Name it in the comments.