Resolving Transport Dependencies

Adam wants to know, if there are transport dependencies – and how they are handled.

Carl explains that there are two main categories: overtaking and transport dependencies.

Now, Carl explains the two categories to Adam in more detail:

Overtaking describes the following situation:

• You release a transport request A
• You release a transport request B. In this transport request, an object is contained that is already in transport request A
• You import transport request B before A, the object is changed to the latest state of release of transport request B
• You import transport request A, the object is changed back to the state of the release of transport request A

The transport management avoids overtaking for the same objects. If an object is recorded in multiple transport requests, the system enforces you to import the transport requests either together or in the right order (order of release). For customizing objects, an overtaking check is implemented per customizing object.

In urgent cases, you can overrule the overtaking check by manual deselection of the listed dependency. This should only be done in exceptional situations as this can lead to import errors and inconsistencies in the import system due to the missing dependencies.

If you have overruled the overtaking check, the selected transport request is imported again at its correct import position. This process is called preimport.

Object Dependencies describes the following situation:

• You release a transport request A
• You release a transport request B. In this transport request, an object is contained that uses an object that is contained in transport request A.
• You import transport request B before A – due to a dependency to transport request A, the import runs into an error

Object dependency checks are executed during export. Dependencies of objects that can be detected by the system are analyzed.

Object Dependencies Within Developer Extensibility: Dependencies are analyzed by the Transport Organizer based on the where-use index. If dependencies are found to objects that have never been exported, you have to merge transport requests, move objects between transport requests, or release the transport requests in the right order so that dependencies are resolved.

Object Dependencies Within Key User Extensibility: Dependencies are analyzed by the Export Software Collection app. If dependencies are found, you have to merge collections or move objects between collections so that dependencies are resolved.

Object Dependencies Between Key User Extensibility and Developer Extensibility: Extensibility and developer extensibility objects are developed in different ABAP language versions (ABAP for Cloud Development and ABAP for Key Users), and are separated by default. This means, for developer extensibility, you can’t use extensibility objects and vice versa. However, there are some exceptions:

• You can release developer extensibility objects for use in key user apps. These objects can be used by key user apps.
• Custom fields that are added to SAP structures and CDS views by the key user can be used in developer extensibility.

During export, the dependencies between key user objects and developer extensibility objects are analyzed. During import, you have to import the dependent transports together or in the correct order.

Exports with dependencies to local development objects are blocked during export.

Object Dependencies Between Business Configuration and Key User Extensibility: In some cases, business configuration refers to extensibility, however, extensibility does not equal business configuration. For example, form templates are extensibility objects created with Adobe Forms Designer. They can be referred to as business configuration, for example rules for finding the right form template for a country, a site, a customer group, and so on. Another example for a reference from business configuration to extensibility are custom fields that can be used in business configuration rules. You must import the respective extensibility and business configuration transport together to avoid errors in the business process.

During import, the Import Collection app allows you to import dependent transports together or in the right order.

Object Dependencies Between Business Configuration and Developer Extensibility: If you create your own business configuration apps (C tables) and create and transport content for it, the transport with the table (or its latest changes) must be transported before the business configuration content.

Object Dependencies Within Business Configuration: When releasing a transport request, the release process checks the foreign key relation between configuration tables as follows:

• The system fetches the transport request and receives the foreign key connections from the data dictionary for all table contents in the transport request. That means the system reads the foreign key related data of these tables and fields and selects the tables from the foreign key connections.
• The consistency of foreign key connections is checked in the source system as well as remotely in the Test and Production system, provided that these systems are already set up.
• From the foreign key connection consistency, you can derive the incompleteness of the transport request and receive information that is required to get a complete set of transport requests.

Carl reminds Adam that there are not only dependencies between customer transport requests – but also between SAP upgrades and customer transport requests.

Carl explains that an SAP upgrade works as follows:

Software upgrade starts in the Test system. After the Test system upgrade (release n+1), the Development and Production system are still on the old release (release n).

When the Test system is upgraded and Development and Production systems are still on the old releases:

You can release customizing and developer extensibility transports and import them into the Test system.

For key user extensibility transports, you can’t import the transports into the Test system, but you can directly forward them to the Production system.

After a certain period of time, for example three weeks, the Development and Production system are upgraded to n+1. At this point in time, you may not be able to import older key user extensibility transports that were created on release n.

Now, Carl explains this in more detail:

The import behavior for transports from release n to n+1 is described in the following table:

Note

You can't import a transport created on release n into release n+2 and higher, which means that you have to recreate the transport in the Development system. However, it is not possible to recreate CBC transports. In this case, you have to create a support incident.

Note

Export, import, and forward are not possible while the system is being prepared for upgrade. Preparation for upgrade normally begins a few days before the actual upgrade is performed.