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

Lesson 3 of 5

Developer extensibility and software components

9 min

Some requirements need real code: a validation that calls several released APIs, a custom application built with the ABAP RESTful Application Programming Model, a background job. In the public edition this is developer extensibility: ABAP Cloud development in the development tenant, using ABAP Development Tools (the Eclipse-based IDE) and only released SAP APIs, extension points and objects. Because the interfaces are released and stable, SAP's goal is that this code survives the twice-yearly upgrades without adaptation.

Software component ZCUSTOM_DEVELOPMENTThe transportable software component for customer development in the development tenant
PackagesSubpackages of ZCUSTOM_DEVELOPMENT, for example one per change area such as fleet sales
Development objectsCDS views, behavior definitions, classes, service definitions and bindings
Workbench transport requestsRecord changes to the objects; released in the Transport Organizer of ABAP Development Tools
Import CollectionRequests appear in the test tenant for import, then are forwarded to production
How developer extensions are organized and moved. The software component decides whether anything can be transported.
The Sign-Off Table · thesignofftable.com/academy/sap-rel-202

Software components: transportable or local

In ABAP Cloud, a software component is the top-level container for development and the unit that defines how objects travel. In the public edition development tenant, transportable customer code belongs in the software component ZCUSTOM_DEVELOPMENT. There is also ZLOCAL, a local software component for experiments, whose objects are recorded in local requests with no transport target and never leave the development tenant.

The trap is real enough that SAP has a knowledge base article about it (3404200). A developer releases a request in ABAP Development Tools and cannot find it in the test tenant's Import Collection app. The cause: the package was created in ZLOCAL, or without a superpackage and without a transport layer, so the request is local. The fix is to create the package again as a subpackage of ZCUSTOM_DEVELOPMENT (the recommended option), or with that software component and transport layer YDEV, and then reassign the objects. Packages cannot be moved, objects cannot be moved from a transportable component to ZLOCAL or between transportable components, and some object types have extra restrictions when moved.

ZCUSTOM_DEVELOPMENTZLOCAL
PurposeCustomer development that goes to test and productionLocal experiments and prototypes
RequestsWorkbench requests with a transport targetLocal requests, no target
Appears in Import CollectionYes, after releaseNever
Objects can later move to the otherNoYes, to a transportable package, with restrictions
Transportable and local software components in the development tenant.
The Sign-Off Table · thesignofftable.com/academy/sap-rel-202

Releasing from ABAP Development Tools

Developers record changes on workbench transport requests, which several developers can share and which can carry documentation describing the change. The Transport Organizer view in ABAP Development Tools is where they release tasks and then the request. Once released, the request appears in the test tenant's Import Collection app, alongside customizing transports and software collections. Before release, the developer should have run ABAP Unit tests and the ABAP Test Cockpit checks that the project requires, because once the request is imported the only way to change it is a new request.

  1. Create packageSubpackage of ZCUSTOM_DEVELOPMENT, assigned to a workbench request
  2. DevelopReleased APIs only; objects recorded on the request
  3. Developer checksABAP Unit tests and the agreed static checks pass
  4. Release in ADTTasks, then the request, in the Transport Organizer view
  5. Import into testRequest appears in Import Collection; administrator imports it
  6. Test and forwardIntegration and acceptance tests; then forward and import into production
The developer extension path from package to production.
The Sign-Off Table · thesignofftable.com/academy/sap-rel-202

Dependencies across vehicles

Developer and key-user content often depend on each other. A RAP application might read the fleet contract number custom field, which arrives in a software collection; a custom logic implementation might call a class from the development tenant. The rule is simple and familiar: what is used must arrive before what uses it. In the working example, Luis plans each release as a bundle: the customizing transports, the software collection and the workbench requests that belong together are imported into test together, tested together and forwarded together.

What would you do?

In the working example, a developer released a workbench request in ABAP Development Tools yesterday, but the administrator cannot find it in Import Collection in the test tenant. What should Luis ask first?

Key points
  • Developer extensions use ABAP Cloud in the development tenant, with released APIs only.
  • Transportable code belongs in ZCUSTOM_DEVELOPMENT; ZLOCAL is local and never transported.
  • A request missing from Import Collection is usually a local request; recreate the package correctly and reassign objects.
  • Release workbench requests in the Transport Organizer of ABAP Development Tools after unit tests and checks.
  • Bundle dependent customizing, collections and workbench requests and move them together.

Check your understanding · not graded

Lesson check

  1. 1. Which software component holds transportable customer development in the public edition development tenant?

  2. 2. Where are developer extension transport requests released?

  3. 3. A released request never appears in Import Collection. What is the usual cause?

  4. 4. What kind of APIs may developer extensions in the public edition use?