Transport dependencies: why imports fail or break production in the wrong order

Where transport dependencies come from

In the Change and Transport System (CTS), a change is moved between systems as a transport request. Real changes rarely fit into a single request: a program change can depend on a new data element, a table field, a class or customizing that was released in a different request.

Dependencies typically arise when:

• dictionary objects (domains, data elements, tables, structures) are changed in one request and used in another;
• a development is split across several developers and requests;
• a correction is released before the change it corrects;
• customizing and workbench changes of the same feature are transported separately.

What goes wrong

• A request is imported before its predecessor: activation or generation errors (return code 8) occur in the target system.
• Only part of a feature is imported: the import succeeds technically, but the program fails at runtime because an object is missing or outdated.
• An older version of an object overwrites a newer one because requests are imported out of sequence.

How to check before importing

1. List the objects of each request and the objects they reference.
2. Determine which other open requests contain those referenced objects.
3. Check the import queue order against these dependencies.
4. Check whether the same object appears in several requests and which version is expected to win.

Software collections in cloud landscapes have the same problem at another level: an exported collection must contain everything its items depend on.

ERP Preflight's Transport Dependency Analyzer builds this dependency graph from exported transport data and reports missing predecessors and order conflicts with evidence. See Release & Transport.