Lesson 2 of 5
Check variants for quality, security, performance and readiness
9 min
Listen to this lesson
A check variant decides what the ATC looks for. It is a named selection of checks, with their parameters, maintained with the Code Inspector (transaction SCI) in classic systems and referenced in the ATC configuration as the global variant for runs and transport checks. Choosing variants well is the most important ATC decision a team makes: too few checks and the gate is meaningless, too many and developers drown in noise and learn to ignore it.
SAP-delivered and custom variants
SAP delivers variants for common purposes, and most teams build their own on top. SAP's ABAP for Cloud Development cheat sheet uses ABAP_CLOUD_READINESS; SAP PRESS guidance on clean core setup names ABAP_CLOUD_DEVELOPMENT_DEFAULT; SAP's BTP documentation mentions SLIN_SEC as an SAP-delivered variant you can reference; and conversion projects use SAP's S/4HANA readiness variants, which community guides name by release, so check the exact name in your system. A custom variant can combine these with your own rules, raise or lower priorities, and exclude checks that do not fit your codebase.
| Contoso variant | Purpose | Applied to | Gate |
|---|---|---|---|
| ZCMC_CLOUD_DEV | ABAP Cloud rules, security, performance basics | Software component ZCMC_CLOUD | Blocks priority 1 and 2 |
| ZCMC_CLASSIC_DEV | Robustness, security, performance for converted code | Classic packages such as ZCMC_SD | Blocks priority 1 and 2 on new findings |
| ZCMC_S4_READINESS | SAP S/4HANA readiness during the conversion | Remote runs against ED1 custom code | Report only |
| ZCMC_CLEAN_CORE | Clean core level classification with the checks Usage of APIs and Allowed Enhancement Technologies | All custom code, monthly | Report only |
Contoso’s ATC variants (illustrative names).
Tuning a variant
- Start from an SAP-delivered variant for the purpose.
- Run it on a representative package and count findings by check.
- For each noisy check, decide: fix the code, lower the priority, or exclude the check, and record why.
- Agree with the release manager which priorities block.
- Version the decision: note the variant change in the change record so results stay comparable.
Variants also need an owner. At Contoso, Kenji owns the development variants and Sam owns their technical setup, but changes go through the same change process as code: a short request stating what changes and why, a trial run on a representative package, and a note in the release record. ABAP Unit can be part of the picture too, because the ATC can run unit tests along with static checks; teams that do this get one result per request that covers both rules and behavior. Whether you include unit tests in the gate variant or run them separately, make sure the evidence for each request shows both.
What would you do?
Sam proposes switching on every available check in the transport gate variant for converted code the week before Mock 2, "to be safe". Kenji expects thousands of new blocking findings. What is the better approach?
- A check variant is the set of checks ATC runs; maintain variants with Code Inspector (SCI) in classic systems.
- Use separate variants for cloud development, classic development, readiness and clean core reporting.
- SAP delivers variants such as ABAP_CLOUD_READINESS; confirm names in your release.
- Grow a variant only as fast as the team can act on its findings.
- Record variant changes so trends stay comparable.
Check your understanding · not graded
Lesson check
1. Which transaction maintains check variants in a classic system?
2. What is the main risk of a gate variant with every check switched on?
3. Which variant fits a monthly report on clean core levels?
4. Why announce changes to a check variant?