The importance of the import queue in SAP Change and Transport Systems (SAP CTS) is regrettably underestimated time and again. Due to a lack of more in-depth knowledge, it is often considered as a simple list containing pending transports for import in the desired sequence. However, this overlooks the fact that as well as the transports and, where necessary, the target clients, the import queue also contains additional status information and control data for carrying out imports, which are continually updated throughout the import process. It therefore comes as a surprise when, for example, an import queue assembled using a script does not produce the same result as the original, or causes an incorrect import sequence in the subsequent systems.
In order to understand these side-effects, we must examine more carefully what sort of information is saved within the import queue.
Initially, the import queue constitutes a kind of to-do list that comprises the transports still to be imported for a particular SAP system. The sequence of the entries corresponds to the sequence of the export from the previous SAP system, or in other words the sequence of the import in the previous system (or the previous client). If all of the transports are imported in the prescribed sequence, then after the import the target system should have exactly the same software status as the corresponding source system (or the corresponding source client). Due to the setup of the transport routes for all the clients to be supplied in the import queue of the target system, this is dependent upon all of the transports in the source system being incorporated into the target system, and no manual changes being made to the import queue.
Each entry in the import queue can be clearly identified by its ID (TRKORR) and its target client. Every combination of TRKORR and target client can only appear precisely once in the import queue. If extended transport management is not activated, then the field for the target client is not applicable. This must be specified manually before each import. Such a setup can only be worthwhile and efficient if just one target client exists.
In addition to the transports the import queue also contains a field for flags, which control the import process. In contrast to unconditional modes, these flags only have an impact on specified import queue entries and not simply the entire import process. Some of these flags can also be set manually (e.g. via “tp modbuffer”), but this is generally done implicitly through the transport control programme “tp”.
The flags deposited in the import queue can be made visible in the import queue view by selecting “Edit -> Show more”. The characters in the UMO field (which, contrary to the description, does not contain any genuinely unconditional modes) have the following meanings:
But what are these flags actually needed for? The aim here essentially is to prevent undesired side effects during an import into several clients, in which the client-dependent part of the transport is only imported once, and to minimise or entirely eliminate difficulties with the sequence of overtakers. This issue would go far beyond the usual scope, to the effect that I will shortly publish a separate article on the matter.
Last but not least, the import queue also contains restart information in the form of return codes that are specific to certain import steps. With the help of this information, a cancelled import can be continued upon restart from the step it had previously reached, meaning it is not necessary to repeat all of the import steps. It is nevertheless possible to force a complete repeat by using unconditional mode “1” or an I flag.
This blog entry provides comprehensive insight into the subject. Next time you take a look at the import queue, don’t just think about the sequence of the transports, but also bear in mind the additional control information, since this can significantly influence the actual scope of the import as well as the position of each individual transport in the queue!