Lesson 3 of 5
Classifying extensions
10 min
Listen to this lesson
Definitions are easy; classifying a real estate is work. After the conversion, Contoso's development system CMD holds about 7,500 custom objects, the ones that survived the pre-conversion cleanup. Kenji's team groups them into extensions: sets of objects that deliver one business capability together, such as "core deposit calculation" or "fleet invoice output". Their first pass produced 240 extensions. This lesson shows how to classify them consistently and defensibly.
The least clean component decides
An extension is only as upgrade-stable as its weakest part. If the fleet invoice output uses released APIs everywhere except one method that reads an SAP table directly, an upgrade that changes that table can still break the invoice. So the working rule is simple: an extension takes the level of its least clean component. One level D usage makes the whole extension level D until it is remediated.
- Group objects into extensionsBy package and business capability; one owner per extension
- Run ATC clean core checksUsage of APIs and Allowed Enhancement Technologies on each extension's objects
- Map findings to levelsEach usage of an SAP object or technique gets a level
- Take the minimumThe extension's level is the lowest level found in any of its objects
- Record and reviewStore level, reason and owner; review borderline cases with the architect
Tooling: ATC and the Cloudification Repository
You do not classify by reading code. The ABAP Test Cockpit (ATC), which SAP calls the key tool for code-level clean core governance, has checks under a Clean Core category. SAP's Cloudification Repository README describes the setup for SAP Cloud ERP Private and on-premise: activate Usage of APIs (Cloudification Repository) in an ATC check variant and point it to SAP's object classification file, either the latest private cloud file or a release-specific one such as the 2025 file. Classic API support needs specific SAP Notes, which the README lists. Since August 2025 the repository also mentions a clean core check Allowed Enhancement Technologies alongside Usage of APIs, which covers how code hooks into SAP rather than which objects it calls; it rates an implicit enhancement, for example, as level D. By default the clean core checks report level B usage with priority 3 (information), level C with priority 2 (warning) and level D with priority 1 (error), so the ATC result already carries the level.
A worked example
| Extension | Components and findings | Level |
|---|---|---|
| Fleet order status app | RAP BO on released CDS views; ABAP Cloud language version; no findings | A |
| Core deposit job | ABAP Cloud logic; calls BAPI_SALESORDER_CREATEFROMDAT2 (classicAPI) through a wrapper | B |
| Fleet rebate calculation | Z_FLEET_REBATE_CALC reads SAP pricing tables directly (internal objects) | C |
| Fleet invoice output | Released APIs except one form routine that reads an internal SAP table | C |
| Sales order save logic | Implicit enhancement in a standard include writing a flag to an SAP table | D |
Five of Contoso's 240 extensions. Note the invoice output: mostly clean, but one internal read sets its level.
Kenji's first full pass came out at 18 extensions at level A, 64 at B, 121 at C and 37 at D. That is typical of a converted ECC estate: most code predates ABAP Cloud, a lot of it reads SAP tables, and a minority uses modifications or implicit enhancements. The numbers are not a grade; they are a map.
- Does any object modify SAP code, use an implicit enhancement or write to an SAP table?Yes → level D · No → next question
- Does any object use an SAP object that is neither released nor a classic API?Yes → level C · No → next question
- Does any object use a classic API?Yes → level B · No → next question
- Does everything use released APIs and extension points?Yes → level A · No → re-check: something was missed
Edge cases
- Shared utilities: a common Z class used by 40 extensions pulls every one of them down if it reads an SAP table. Classify shared components first; fixing one can raise many levels.
- Wrappers: a Tier 2 style wrapper isolates the risk but does not remove it. The extension that relies on it inherits the wrapper's level.
- Dead code: unused objects still show up in ATC. Retire them rather than classify them; the modernization course in this track covers usage analysis.
- Configuration-only changes: Customizing is not an extension; keep it out of the code inventory.
What would you do?
Kenji's team finds that the Z utility class ZCL_CMC_DOC_UTIL, used by 46 extensions, reads two SAP tables directly. Everything else in most of those 46 extensions is level A or B. What should they do with the classification?
- Group objects into extensions by business capability, with an owner each.
- An extension takes the level of its least clean component.
- Use ATC clean core checks with SAP's Cloudification Repository files; record which file you used.
- Classify shared utilities first; they often pull many extensions down.
Check your understanding · not graded
Lesson check
1. An extension uses released APIs everywhere except one method that reads an SAP table directly. What is its level?
2. Which ATC check reads SAP's Cloudification Repository to classify object usages for private cloud?
3. Why should the team record which classification file they checked against?
4. Why classify shared utility classes first?