Controlling the import process with flags

by Thomas Erdösi

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:

I Import the transport again (whole):
The import of the transport will be completely restarted without checking whether the import has already been carried out. This flag is usually only set by using unconditional mode “0”.
J Import the transport again (only client-dependent):
The import of the transport will be completely restarted without checking whether the import has already been carried out. However only the client-dependent content of the transport will be considered for import. ABAP coding and dictionary elements will be ignored in imports with a J flag. This flag is generally only set by using unconditional mode “0” and must have been delivered from a client of the same system, but can also be set for an import into several clients of the same system.

If a transport within an import (SUBSET or IMPORT ALL) is imported into several target clients, the J flag will be set implicitly for all clients except the first import client. This process cannot be overridden.
F The transport is in a provisional position in the import queue:
The transport has not yet been concluded (green tick) in the preceding system (or preceding client), but will just be imported as an “overtaker” (yellow triangle). Every further import in the preceding system (or preceding client) ensures that the transport will “drop back” at the end of the import queue, i.e. will rejoin at the back. Should the transport in the preceding system (or preceding client) then be imported, the F flag in the import queue of the subsequent system will be deleted. This flag should always be used in combination with an I or J flag.
Is set using the “tag=SPAM” option. This function is only used by the SPAM transaction.
N No delivery:
After import, the transport will not be accepted into the import queue in the subsequent system (or subsequent client).
Q Ignore a missing SAP QA approval.
V Any transport added to the import queue with an I or J flag has already been imported and will therefore also be displayed without a corresponding return code.

This flag will not be saved in the import queue, but will be determined during runtime by the subprogram CHECK_PRELIMINARY_IMPORT in the TMS_TP_SHOW_BUFFER function module. The underlying logic is as follows:
In extended transport control mode (CTC=1), an appropriate entry (TRKORR/CLIENT) will be sought in Table E070TC, otherwise an appropriate entry (TRKORR) will be sought in Table E070. Should this entry be found, a V flag will be attached. It is worth keeping in mind that after changing from CTC=0 to CTC=1, any transports carried out before the changeover will not be recognised. A possible workaround in such a case is to use Conigma CCM to activate the process of establishing the import status from the import history.
Can be set using the “tag=X” option.

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!

Go back