Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 3 of 5

Packages, software components and transports

10 min

Listen to this lesson

0:00 / 8:04

Every ABAP object lives in a package. Packages group related objects, carry a transport layer, and, through package interfaces and use access, can control who may use what. Packages in turn belong to a software component, the unit that is versioned and delivered together. Get this structure right and transports, ownership and testing all become easier. Get it wrong and you spend go-live weekend chasing an object nobody can move.

Software componentThe delivery unit: for example SAP’s own components, HOME for classic customer code, or a component created for ABAP Cloud development
Structure packageTop-level package of the component; holds no objects itself
Development packagesWhere objects live, for example ZCMC_SD for order-to-cash enhancements
ObjectsClasses, CDS views, tables, behavior definitions, service bindings
Transport requestCarries changed objects from CMD to CMQ to CMP
From software component down to the object, and how changes travel.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-101

Classic systems: packages, layers and the transport system

In SAP S/4HANA Private Edition and on-premise, custom objects sit in Y or Z packages (or a registered namespace). Each package has a transport layer that defines the route its changes take, and changes are recorded in transport requests through the Change and Transport System (CTS). A request contains one task per developer; developers release their tasks, then the request is released and imported along the route. Local objects in $TMP never leave the system, which is why nothing a tester relies on should ever be built there.

A transport request is open while developers work, frozen once released, and then imported along the route CMD to CMQ to CMP.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-101

At Contoso, converted order-to-cash enhancements live in package ZCMC_SD in the standard customer software component. For new ABAP Cloud work, Kenji asked Sam to create a separate software component, ZCMC_CLOUD, whose packages use the language version ABAP for Cloud Development. That keeps the clean, upgrade-stable code visibly apart from converted classic code, and lets the ATC apply stricter rules there. The exact setup steps for a Private Edition system vary by release, so Sam follows SAP's developer extensibility guide for 2025.

SAP BTP ABAP environment: software components and gCTS

In the SAP BTP ABAP environment, SAP's documentation describes the software component as the container that organizes and transports your development. You create it with the Manage Software Components app; it gets a structure package of the same name, and you create sub-packages of type Development for your objects. The default component ZLOCAL works like $TMP: local and non-transportable. Transport between systems uses git-enabled CTS (gCTS) under the hood, and you import a component into test and production systems through the same app.

In the BTP ABAP environment, released transports land in a git-based repository and test systems pull the whole software component from it.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-101
Rule (BTP ABAP environment)Why it matters
Objects cannot be moved between software componentsPlan the layout before developers start; moving later means recreating objects
Objects in one component are not usable from another by defaultExpose functionality through released APIs, or declare a software component relation
Avoid cyclic dependencies between componentsLifecycles stay independent; put shared reuse code in a foundation component
ZLOCAL is local onlyNothing in ZLOCAL reaches test or production, so never test business scenarios from it

Software component rules SAP documents for the BTP ABAP environment.

  1. Will this object ever need to reach CMQ or CMP?Yes → a transportable development package · No → $TMP (classic) or ZLOCAL (BTP)
  2. Is it new ABAP Cloud code?Yes → a package in the ABAP Cloud software component (ZCMC_CLOUD) · No → the classic package for its area (ZCMC_SD)
  3. Will other components call it?Yes → design a released API (C1) for it · No → keep it internal to its package
  4. Does it belong to a separate lifecycle?Yes → consider its own software component · No → a sub-package is enough
Choosing where a new object belongs.
The Sign-Off Table · thesignofftable.com/academy/sap-abp-101

What would you do?

Luis is planning the cutover and asks Kenji why the transport list for CMP contains a request with only two objects, both in ZCMC_CLOUD, while all the converted code travels in large requests. Which answer helps Luis most?

Key points
  • Objects live in packages; packages belong to software components.
  • In classic systems, CTS requests and tasks carry changes along the transport route.
  • $TMP (classic) and ZLOCAL (BTP) are local and never reach test or production.
  • In the BTP ABAP environment, objects cannot move between software components; plan the layout first.
  • Keeping ABAP Cloud code in its own component makes clean-core work visible and testable.

Check your understanding · not graded

Lesson check

  1. 1. What happens to an object stored in $TMP when the request route runs from CMD to CMQ?

  2. 2. In the SAP BTP ABAP environment, which app creates a software component?

  3. 3. Why does SAP advise against cyclic dependencies between software components?

  4. 4. Why did Contoso put new ABAP Cloud code in a separate software component?