9.4Bloom · AnNot started

The Decoupling Cockpit

Reading depth

What you'll learn

The Decoupling Cockpit generates Z-namespace wrappers mirroring a standard internal API so future SAP changes only touch the wrapper, not every caller.

  • Generates Z-namespace wrapper objects mirroring a standard internal API's signature.
  • Callers use the wrapper; only the wrapper touches SAP standard.
  • Future SAP changes touch one wrapper, not every call site.

When custom code calls a standard internal API that is not released, every future SAP change to that API is a potential break, scattered across however many call sites you have. The Decoupling Cockpit attacks this by generating wrapper objects in your own Z namespace that mirror the standard internal API's signature exactly. Your code then calls the wrapper, and the wrapper alone calls SAP — so if SAP changes the internal API later, you adjust one wrapper instead of hunting through dozens of callers.

The workflow is deliberate and repeatable: scan the code for the direct calls into standard internals, generate a Z-namespace wrapper class whose signature matches the SAP API, rewrite the caller to use the wrapper instead of the standard object, and then mark that wrapper as the decoupled boundary so it is clearly the single point of future migration. The wrapper is not cleaner code in itself — it is a chokepoint that localises the blast radius of SAP changes.

The senior value is that this converts an unbounded, code-wide coupling problem into a bounded, one-object one. It does not make a non-released API released, and it does not remove the underlying risk; it concentrates that risk at a documented boundary you control, which is precisely the move you want when a clean rewrite to a released API is not yet possible.

Key points

  • Generates Z-namespace wrapper objects mirroring a standard internal API's signature.
  • Callers use the wrapper; only the wrapper touches SAP standard.
  • Future SAP changes touch one wrapper, not every call site.
  • Workflow: scan → generate wrapper → rewrite caller → mark the decoupled boundary.
  • It localises risk at a controlled boundary; it does not make the API released.

Examples

One wrapper, many callers protected

The cockpit scans for direct calls to an unreleased standard class, generates zcl_*_wrapper mirroring its signature, rewrites all callers to the wrapper, and marks it the decoupled boundary — so a later SAP change is a one-object fix.

Source notes: clean-core-curriculum §9.4

Ask Claude

Build a prompt from this lesson + your question and open a fresh Claude chat with it pre-filled — handy for adapting a before/after pattern to your own object.