Wrappers in Clean Core: the debt is concentrated, not removed
When SAP offers no released replacement, a wrapper isolates the non-released usage in a single place. How it affects the debt, when it pays off and when it does not.
Not every SAP function module or table has a released replacement. For these cases, SAP's own recommendation for those following Clean Core is the wrapper: a company object that encapsulates the non-released usage behind a released contract. Programs start using the wrapper, and the non-released usage stays in a single place.
It is a good tool, as long as you understand what it does to the debt.
What a wrapper is
A wrapper does not rewrite SAP's logic: it only passes calls through. The logic is still that of the original function module or table, and the behavior does not change. What changes is that, instead of dozens of programs calling the internal function module, they all call the wrapper, and only the wrapper calls the function module.
| Type | When to use it | What it looks like |
|---|---|---|
| SAP function module | The function module has no released replacement and several Z objects call it | A released interface and a class that calls the original function module, passing everything through |
| SAP class | The class is not released, has no released successor, and several Z objects call its methods | A released interface and a class that instantiates the original class and passes the calls through, only for the methods the Z objects use |
| SAP table | Several Z CDS views read the same table and SAP names no released successor | A CDS view with the table's fields, with the same names and no filter |
The debt moves
The wrapper still uses what is not released, so the finding moves to it: a table wrapper sits at Level C, like any CDS view that reads an SAP table. The gain lies in the objects that start using the wrapper, which no longer have the finding.
That is why the math is simple:
- with a single object using it, the debt only moves, and the wrapper does not pay off;
- from two onwards, the debt goes down: ten programs that called the same internal function module become a single finding, in the wrapper.
When the wrapper is created, the first switch does not reduce the debt: it only moves it. Each object that starts using it afterwards reduces it.
When not to build a wrapper
- When SAP names a released successor. In that case, switching to the successor is the way to go: it removes the finding for good.
- When the function module depends on its caller. If the body of the function module checks which parameters were supplied, passing everything through may not be equivalent to omitting them, and the wrapper would change the behavior.
- When the Z object inherits from an SAP class or implements an SAP interface. Here the link is the structure of the object itself, not a call, and there is nothing to pass through: the way forward is the released alternative, when there is one, or keeping it as it is.
- When the goal is to hide the problem. A wrapper that adds its own logic on top of SAP is no longer a wrapper: it becomes a new Z object, with new logic, to be maintained.
Why release the wrapper
A wrapper is usually released with the C1 contract. Without it, ABAP Cloud code in another software component cannot use it, and it would lose its reason to exist: paving the way to Level A. Within the same software component, the call works without a contract, but the dependency stays hidden. The release is also a commitment to those who use it: the wrapper must not change in an incompatible way. For a Z object, that commitment is enforced by the API compatibility check in ATC, with a snapshot of the API taken beforehand, not by activation, as shown in API release contracts: what C0, C1, C2, C3 and C4 guarantee. The rule of who can call whom, and why it depends on the software component, is described in Software components in ABAP Cloud: who can call whom.
The wrapper is the bridge between the code that exists today and ABAP Cloud. Used in the right place, it concentrates the problem in a known spot, monitored by the ATC, and frees the rest of the code to stay clean. To understand how each object's level is calculated, read How SAP Cloud ALM calculates Clean Core debt.