Detection of overtakers

Basics

The sequence of transport requests in an import queue usually depends on when the transport requests where released for export. When a request is released and exported, it is placed at the end of the queue of the consolidation target, usually a quality assurance system, depending on the consolidation route. This means that transports with older developments can be found at the beginning of a queue and more recent developments are located at the end.

If a request A_m is imported into a system at position P(A_m) in the queue, which contains objects that are completely or partially contained in a request A_n at position P(A_n) in the queue that has not yet been imported, and P(A_n) < P(A_m) is valid, request A_m is an overtaker of A_n and A_n is a missing predecessor for A_m. For example, A_n could be a request that is handled within a release and A_m contains a correction that is coordinated within the framework of maintenance work outside a release.

When A_m is imported before A_n, the newer object versions from A_m will be overwritten, which is normally not desired or intended and can lead to inconsistencies.

Identification of overtaking requests

When importing transport requests into a target system using a Conigma import container, overtakers are automatically identified by default and automatically added to the transport scope. For identification, a potential overtaking candidate A_u must meet the following criteria, where M is the set of all transports included in the import scope of the import container:

• A_u is not included in M

• A_u is already imported in the target system as a preliminary import (set I flag or yellow triangle in the import queue)

• A_u overlaps with a request A_k from M and for the queue positions P(A_k) < P(A_u) applies

• A_u overlaps with an already identified overtaker A_iu and for the queue positions P(A_ui) < P(A_u) applies

• The overlapping objects of A_u are not completely contained in a request A_r from M, where P(A_u) < P(A_r)

To ensure that an overtaker can be re-imported if necessary, transport requests are usually imported as preliminary imports by Conigma.

I and F flags

As mentioned above, transport requests are always imported as preliminary imports. You can do this by using the option "Leave transport request in queue for further import" or by setting the unconditional mode "I" or I flag. If a transport request can be re-imported, that is, if the I flag is set, an F flag is set on the transport request in the subsequent queues. Setting the F flag is done by the SAP standard coding and not by Conigma. The F flag indicates that the request might not be at its final position in the queue, as it can be re-imported into the previous queue and then drops to the end of the queue.

Example:

An object O is changed several times in the development system and is contained in two unimported transport requests A_n and A_m in the queue of the quality assurance system. Request A_n is at position P(A_n) and request A_m is at position P(A_m), where P(A_n) < P(A_m). If request A_m is now imported into the quality assurance system as a preliminary import, it is forwarded to the queue of the succeeding system and placed at the end of the queue at position F_i. Now, request A_n is imported via Conigma and A_m is automatically recognized as an overtaker and re-imported again. Without the F flag in the queue of the subsequent system, the following would happen: Request A_n is forwarded to the queue of the subsequent system and placed at the end, assigning it the position F_j > F_i. This means that request A_m is located above the request A_n in the queue of the subsequent system. If request A_m is imported first and then A_n, A_m is no longer recognized as overtaker of A_n => downgrade. If request A_n is imported first and then A_m, A_n would be wrongly identified as overtaker of A_n => downgrade.

The F flag causes the following to happen: Request A_n is forwarded into the queue of the subsequent system and placed at the end, where it is assigned the position F_j > F_i. Since A_m is included in the scope of the import as an overtaker and is being re-imported, A_m is moved to the end of the queue of the subsequent system. Now F_k > F_j > F_i applies for the new position and a correct sequence is guaranteed.