Describing Types of Transport Requests

In a meeting with Devin, Carl explains what kind of development can be done in SAP S/4HANA Cloud Public Edition and what tools are used:

In SAP S/4HANA Cloud Public Edition, customers can use a two or three-system landscape and transport changes across these SAP systems. Besides extensibility, Adaption Transport Organizer (ATO) will be used as a common import UI for custom development; business configuration (client-specific and cross-client) imports. In a two-system landscape, ATO techniques will be utilized even at export for certain export processes. ATO is used for managing key user extensibility transport requests from the Test system to the Production system.

In a three-system landscape, the ATO orchestrates the transport requests for developer extensibility (Embedded ABAP development), key-user extensibility, and Business Configuration for SAP S/4HANA Cloud Public Edition. This will allow customers to control the process and selectively transport configuration, key user extensions, and developments with the same approach.

The pre-configuration activated using Central Business Configuration (CBC) will be captured in transport requests in the Development system. The transport behavior of a table or view is defined in the transport settings of the single maintenance object (SOBJ). Business Configuration (BC) fine-tuning, extensibility, and developer extensibility are done in the development system and captured in transport requests.

As discussed, the unified transport approach uses a combination of tools:

• Transport Organizer in Eclipse (ADT) for managing workbench transports for developer extensibility: in this tool, developers can create, manage (for example, merge, change the owner, …), and release workbench transport requests for developer extensibility.

• Fiori App Export Customizing Transports is used by a project lead/content expert for managing and exporting a transport request. It displays customizing transport requests, their project assignment, and piece list (client-specific objects only). Here, customizing transport requests can be released. It provides:

• Fiori app Export Software Collection (ATO): In this tool, developers can create collections of extensibility objects (items) and export them.

• Fiori app Import Collection (ATO): The Import Collection Fiori UI is used for importing extensibility transports and BC transports. It has been enhanced to allow customers to import customizing and developer extensibility (workbench) transports into the T or P system.

There are three categories of transportable objects.

• Includes ABAP language version 5 (and above) development objects (code, ABAP dictionary (DDIC), ABAP Core Data Services (CDS), User Interface (UI), ....) .

• Is performed in ABAP Development Tools using development business catalogs.

• Allowlist is defined by the ABAP Allowlist for language version 5 (and above).

• Development objects are transported using workbench transport requests.

• Includes ABAP language version 2 development objects and customizing packaged as an ATO object.

• Is performed in Fiori UIs using extensibility business catalogs.
• Allowlist is defined by the ABAP Allowlist for language version 2.

• ATO has a change recording and can do a late transport creation and release. So separation from transports is possible.

• Includes client-specific and cross-client customizing.

• Performed via an open cloud-enabled Implementation Guide (IMG) using configuration business catalogs.

• Allowlist is defined by the SAP business catalogs of type configuration.
• Transported using customizing transport requests for client-specific customizing.
• Transported using workbench transport requests for cross-client customizing.
• Cross-client business customizing must be handled as customizing, not as ATO objects

The ensure an isolated test for all three categories of transportable objects, tests must be performed in a separate Test system. This helps to isolate finished configuration/development from unfinished configuration/development, especially for cross-client objects. Only the import in a separate Test system is a real test for the import in the subsequent Production system. Mainly because only when importing, the after-import methods (AIM) and the software change task list execution are executed.

Now, Devin wants to know from Carl what kind of transport requests exist:

In the following, Carl explains some abbreviations:

The system classifies transport requests automatically according to their use case by setting one of the following values for the SAP_ATO_TRANSPORT_TYPE attribute:

• Developer extension: DEV
• Key user extensions: EXT
• Business configuration deployed from SAP Central Business Configuration: CBC
• Client-specific fine-tuning: BC
• Cross-client fine-tuning: CCC

Then Carl shows Devin a list of the different types:

Again, Carl explains some abbreviations and details:

The technical types of transport requests are:

• W = Customizing
• K = Workbench
• T = Transport of Copies

Each transport request has a transport target. The target can be:

• Empty: Only changes are recorded. Changes are not available for import in the Test system, even if the transport request got released. Such transport requests are called local transport requests. For example, if you develop in software component ZLOCAL.
• /<SID>_ATO/: Used for workbench transport requests. After the workbench transport request is released, changes can be imported into the Test system.
• /<SID>_CUS/: Used for customizing transport requests. After the customizing transport request is released, changes can be imported into the Test system.

Carl reminds Devin that there is the default transport request – and explains some details:

When you create a customizing transport request from the Export Transport Customizing app, the transport category of the customizing transport request is set to default. If a user has a task for the transport request, the transport request is suggested to the user for change recording, whenever they perform a change. There can only be one open default customizing transport request at a time. Once the default customizing transport request is released, a new one can be created for configuration changes. Instead of recording changes to the default customizing transport request, you can also create new customizing transport requests from the change recording dialog. The transport category of such customizing transport requests is manual. The number of customizing transport requests isn't restricted. A manual customizing transport request may be helpful if you need to transport a change to the test and production tenant urgently and can't wait for others to finish their configuration activities. The transport category of the customizing transport request is the value of the SAP_CUS_TRANSPORT_CATEGORY attribute. Possible values are:

• DEFAULT_CUST: default (client-specific) customizing transport request
• DEFAULT_CUSY: default cross-client customizing transport request
• MANUAL_CUST: manual (client-specific) customizing transport request
• MANUAL_CUSY: manual cross-client customizing transport request

Objects that are recorded on the workbench transport requests are locked. That means the object can't be changed on any other workbench transport request. Users who want to change the object must be assigned a task on the same workbench transport request. For customizing transport requests, there is no locking.

You can reassign a change from one transport request to another if necessary. However, we do not recommend removing a change from a transport request without assigning it to another one. This may result in import errors or incomplete deletions in the Test or Production system.

You do not record key user extensions on transport requests. You create an extension in one of the key user apps and assign the extension to a software collection in the Export Software Collection app. The Export Software Collection generates a transport request to transport your changes during export. However, this is hidden from you.

The following rules apply:

• Transport requests for developer extensibility, key user extensibility, and business configuration are separated

• Content can't be mixed

• Transport requests of the different categories can't be merged

• During import, transport requests of different categories can be imported together

Transport requests can have dependencies. In this case, the Import Collection app enforces that dependent transports are imported together.

Carl shows Devin a summary list and says he does not have to read through this list right now...

Transport Management Summary – the following tables give you an overview of transport management in a three-system landscape:

Fore more information, please check SAP Help Portal – Transport Management Summary.