Describing Types of Transport Requests

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

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

In a two-system landscape. ATO is used for managing transport requests of key user extensibility 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 S/4HANA Public Cloud. This will allow customers to control the process and selectively transport configuration, key user extensions, and developments with the same approach.

The pre-configuration that has been 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 is done in the development system and also captured in transport requests.

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 Software Collection (ATO): in this tool, developers can create collections of extensibility objects (items) and export them.

• 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:

  • A list of all transport requests

  • Details of the transport requests

    • List of contained objects and keys

    • Search capability for object (name)

    • Navigation to SSCUI (IMG activity)

    • Export log (errors, actions, …)

• 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. It provides:

  • List of all transport requests

  • Details of the transport requests

    • List of contained objects

    • Search capability for object (name)

    • Transport log (errors, actions, …)

  • Actions: Import and Forward (from T to P system)

Transportable Objects

There are three categories of transportable objects.

1. Customer Development

• 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.

2. Key-user Extensibility

• Includes ABAP language version 2 development objects and customizing packaged as 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 is able to do a late transport creation and release. So separation from transports is possible.

3. Business Configuration

• 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. Especially 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:

Note

ATO_TRANSPORT_TYPE is added as transport request attribute SAP_ATO_TRANSPORT_TYPE to the transport request.

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.

Note

<SID> is the system ID of the development system that was provided by SAP.

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 default transport request 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 useful 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 workbench transport requests are locked. That means the object can't be changed on any other workbench transport request. Users that want to change the object need to be assigned a task on the same workbench transport request. For customizing transport requests, there is no locking.

If necessary, you can reassign a change from one transport request to another. 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. During export, the Export Software Collection generates a transport request to transport your changes. 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 ends with showing Devin a summary list – and says that he does not have to read through this list right now...

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