The software-component boundary
What you'll learn
The 'ABAP for Cloud Development' restriction is set per software component and applies to all of it — isolate legacy code in its own component behind a released interface.
- The API restriction applies to the whole software component — no mixing.
- Isolate unavoidable classic code in its own component behind a released interface.
- Cross-component calls obey the consumer's release contract.
Custom code lives in a software component (for example a customer-defined one, or HOMEAPP). Two attributes matter: the layer/stack (HOME means it stays on this system; LOCAL packages are not transportable) and the API restriction. When the component is set to 'ABAP for Cloud Development,' the entire component is restricted — you cannot mix restricted and unrestricted code inside one component.
A common architecture uses one software component for the cloud-clean ABAP Cloud code and a separate classical component for unavoidable classic-ABAP leftovers (for example classic print-workbench forms), with a hard, released interface class between them.
Cross-component access is gated by the consumer's release contract: if your component is restricted, it can only reach the other component through released objects. The boundary is therefore the place where you decide and document what is exposed.
Key points
- The API restriction applies to the whole software component — no mixing.
- Isolate unavoidable classic code in its own component behind a released interface.
- Cross-component calls obey the consumer's release contract.
- The component boundary is where you declare and document what's exposed.
Examples
ZCLEAN (ABAP Cloud) holds the new code; ZCLASSIC holds the legacy form logic; a released interface class is the only door between them.
Source notes: clean-core-curriculum §1.5
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.