Software components in ABAP Cloud: who can call whom

Anyone who starts writing ABAP Cloud code in S/4HANA soon runs into a message such as "The use of Class ZCL_... is not permitted" when calling an existing Z class. The common reaction is to convert the called class to ABAP Cloud as well. Often that does not help: the error remains. The explanation lies in a little-discussed concept, the software component.

What a software component is

A software component is a set of packages that forms a delivery unit: it is versioned, installed and updated as a block. S/4HANA itself is made of them. Under System → Status, in the list of installed components, you see names such as SAP_BASIS (the technical foundation), SAP_ABA and S4CORE (the S/4HANA core), each with its own version and support package level.

The company's code also lives in software components:

• every package belongs to exactly one software component, and every object belongs to a package. The hierarchy is software component → package → object;
• Z packages are, by default, in the HOME component, which exists in every system for customer development. Many companies have all their Z code there without ever having thought about it;
• the company can create its own software components, for example one for new code and another for legacy code, and choose which one each package belongs to;
• in SAP BTP ABAP Environment, each software component corresponds to a Git repository, which makes the idea of a "delivery unit" more visible.

For those coming from other languages, the closest analogy is a module: a boundary around a set of code that says what belongs to it. In classic ABAP, this boundary made almost no difference day to day. In ABAP Cloud, it decides who can call whom.

Where the ABAP Cloud "label" lives

The language version appears in three places, and each has its own role:

The software component is configured by system administration (in S/4HANA, through the report RSMAINTAIN_SWCOMPONENTS) and has two characteristics: whether it is transportable or local, and which language version it accepts.

The default software component for Z objects is usually HOME, which is "Standard ABAP", that is, unrestricted.

The rule: who can call whom

An object in Standard ABAP can call anything: the rule only applies to objects in ABAP Cloud. For them, what decides is the software component of the called object:

The surprising detail: the rule applies even when the called object is already ABAP Cloud. An ABAP Cloud class in another software component, without C1, remains inaccessible. And the opposite also holds: a Standard ABAP object with C1 can be called by ABAP Cloud code from another software component. That is exactly how a wrapper works.

There is one exception documented by SAP: Software Component Relations, which allow an ABAP Cloud software component to use objects from another ABAP Cloud software component without releasing each of them. The documentation does not say from which S/4HANA on-premise release the feature is available. Without a configured relation, the rule in the table applies.

C1 enables use, it does not clear the debt

The C1 release is a contract: the object can now be used by ABAP Cloud code from other software components, and whoever releases it commits to making no incompatible changes to it. 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 (see API release contracts: what C0, C1, C2, C3 and C4 guarantee). The release changes nothing about the object's own findings. A wrapper with C1 that reads an SAP table still has the Level C finding.

And calls between Z objects never generate a finding in the Clean Core check: it only evaluates the use of SAP objects. This has an important consequence:

• an ABAP Cloud object stays at Level A even when it calls, in the same software component, a Standard ABAP Z object at Level C;
• the debt exists, but it lives in the neighbor, and does not show up in the Level A object.

Why put ABAP Cloud code in its own software component

If ABAP Cloud code sits in an unrestricted software component, together with legacy code, it can call any old Z object without a contract. The result is a Level A with hidden dependencies.

With ABAP Cloud code in a software component that only accepts ABAP Cloud, every dependency on legacy code requires an object with C1. Each dependency becomes an explicit, reviewed and visible contract, and the debt is concentrated in the wrappers. This is also the guidance in SAP's ABAP Extensibility Guide: ABAP Cloud code in an ABAP Cloud software component, classic code in HOME or in a classic software component.

SAP used to organize this in the former three-tier model. Since August 2025 it talks about Levels A to D and about "ABAP Cloud development" and "classic ABAP development", but the separation into tiers is still a practical way to organize software components:

Within tier 2, only the class that actually calls SAP needs to be Standard ABAP. The wrapper's interface can be ABAP Cloud in the same software component, and the dashboard shows a single object outside Level A per wrapper.

Three practical precautions

• The ABAP Cloud readiness variant (ABAP_CLOUD_READINESS) anticipates the rule. Run on a standard object, it flags calls to Z objects in another software component without C1, which would prevent the conversion. Calls within the same software component and to objects with C1 do not appear.
• Changing a package's software component requires the objects to already be in ABAP Cloud, when the new software component only accepts ABAP Cloud. Convert first, change the software component afterwards.
• Revoke C1 before deleting a released object that nobody uses. If it is deleted with the contract still active, the release record is orphaned and the transport request containing the deletion cannot be released. If someone uses the object, the way to go is to mark it as deprecated, with a successor.

To see how a wrapper uses this rule, read Wrappers in Clean Core: the debt is concentrated, not removed. To understand why Level A requires ABAP Cloud, read Why a program with a classic screen stops at Level B.

Sources

• SAP, Extend SAP S/4HANA in the cloud and on premise with ABAP based extensions (ABAP Extensibility Guide), version 2.3, August 2025, chapter 5.
• SAP Help, ABAP Development Tools, Released APIs and Software Component Relations.
• Tests of calls between software components in SAP S/4HANA 2025 (SAP_BASIS 816), with classes in the HOME component, in an ABAP Cloud-only software component and in LOCAL.