Lesson 2 of 5
Level definitions
10 min
Listen to this lesson
Each level is defined by the most problematic thing an extension relies on. This lesson walks through the four levels with Contoso examples, then looks at the vocabulary SAP uses to classify individual SAP objects, which is what makes the levels measurable.
Level A: extend with released interfaces
Level A extensions use only publicly released, stable interfaces. On-stack, that is ABAP Cloud: the ABAP for Cloud Development language version, where the compiler and the released-object check allow only released APIs and extension points. Side-by-side, it is an app on SAP BTP calling released public APIs. Key user extensibility, such as custom fields and custom logic in released BAdIs, also counts. Contoso example: the fleet order status app Kenji's team builds with RAP on released CDS views and released APIs.
Level B: classic APIs
Level B extensions meet level A criteria and additionally use classic APIs: SAP objects that are not released for ABAP Cloud but that SAP has classified as well-defined, documented and generally upgrade-stable. Many BAPIs fall here. SAP publishes these classifications in its Cloudification Repository on GitHub; in the object classification file for private cloud, for example, BAPI_SALESORDER_CREATEFROMDAT2 and BAPI_PO_CREATE1 are listed with the state classicAPI, with labels such as remote-enabled or transactional-consistent. Contoso example: the core deposit job that creates follow-up sales orders through BAPI_SALESORDER_CREATEFROMDAT2.
Level C: internal objects
Level C extensions access SAP internal objects that are neither released nor classified as classic APIs: reading an SAP table directly, calling an internal function module, using an internal class. SAP calls these partially compliant and suitable for legacy scenarios; they carry upgrade risk because SAP may change internal objects. To help, SAP's ABAP Extensibility Guide describes a changelog for SAP objects, which you check before each upgrade to spot changes to the internal objects you use. Contoso example: the legacy function module Z_FLEET_REBATE_CALC, which reads SAP pricing tables directly.
Level D: not recommended
Level D covers extensions that use explicitly non-recommended objects, modifications of SAP code, write access to SAP tables or implicit enhancements. SAP calls this the highest risk with significant technical debt: every upgrade or support package can break it, and SPAU adjustment and regression testing follow every time. Contoso example: an implicit enhancement in a standard sales order include that writes a custom flag straight into an SAP table.
| Level | Typical techniques | Contoso example | Upgrade expectation |
|---|---|---|---|
| A | ABAP Cloud, released APIs and BAdIs, key user tools, BTP apps on public APIs | Fleet order status app (RAP) | Should survive upgrades unchanged |
| B | Classic APIs such as classified BAPIs | Core deposit job using BAPI_SALESORDER_CREATEFROMDAT2 | Generally stable; verify in regression |
| C | Reads of SAP tables, internal function modules or classes | Z_FLEET_REBATE_CALC reading pricing tables | Check the changelog and retest affected flows |
| D | Modifications, implicit enhancements, writes to SAP tables | Implicit enhancement writing to a sales table | Expect adjustment work and full regression |
Levels with typical techniques and what each means for the next upgrade.
How SAP classifies objects
Levels become measurable because SAP classifies its own objects. Released objects carry a release contract you can see in ADT (the API state on the object's Properties tab). The Cloudification Repository adds machine-readable lists: released objects, objects in state classicAPI, and objects in state noAPI, often with a named successor to use instead. ATC checks read these lists to tell you, object by object, which level your code's usages fall into.
- Custom code uses an SAP objectFor example, Z_FLEET_REBATE_CALC calls a function module or reads a table
- Look up the object's classificationReleased with a contract, classicAPI, noAPI, or not listed at all
- Map to a levelReleased → A; classicAPI → B; internal or unlisted → C; non-recommended technique or write to SAP table → D
- Follow the successorFor noAPI objects, the classification often names the object to use instead
What would you do?
A developer on Kenji's team needs the open quantity of sales order items in a new report. She can read SAP table VBAP directly, or use a released CDS view that provides the same data. Which choice keeps the report at the best level?
- A: released APIs only. B: plus classic APIs. C: internal SAP objects. D: modifications, implicit enhancements, writes to SAP tables.
- Classic APIs are documented and generally upgrade-stable; SAP lists them in the Cloudification Repository.
- Level C carries upgrade risk; check SAP's changelog for SAP objects before each upgrade.
- Object classifications (released, classicAPI, noAPI with successors) make levels measurable.
Check your understanding · not graded
Lesson check
1. Which level fits an extension that calls a BAPI SAP has classified as a classic API, and otherwise uses released APIs?
2. Which technique places an extension at level D?
3. What does SAP provide to help manage level C risk?
4. In SAP's Cloudification Repository classification file, what does the state noAPI often come with?