Steuerung des Importverhaltens durch Flags

von Thomas Erdösi

Die Bedeutung der Importqueue im SAP Change- und Transport-System (=SAP CTS) wird leider immer wieder unterschätzt. Oft wird sie mangels besseren Wissens als eine einfache Liste betrachtet, welche die zum Import anstehenden Aufträge in der gewünschten Reihenfolge enthält. Hierbei wird jedoch übersehen, dass die Importqueue neben den Aufträgen und ggf. deren Zielmandanten auch zusätzliche Statusinformationen sowie Steuerungsdaten für die Durchführung der Importe enthält, welche bei der Durchführung von Importen immer wieder aktualisiert werden. Folglich ist die Überraschung oft groß, wenn eine z.B. per Skript aufgebaute Importqueue am Ende nicht das Ergebnis des Originals liefert oder eine fehlerhafte Importreihenfolge in den nachfolgenden Systemen verursacht.
Um diese Seiteneffekte verstehen zu können, müssen wie die in der Importqueue gespeicherten Informationen etwas genauer unter die Lupe nehmen:
Zunächst stellt die Importqueue eine Art To-Do Liste dar, welche die noch zu importierenden Aufträge für ein bestimmtes SAP System enthält. Die Reihenfolge der Einträge entspricht der Reihenfolge des Exports aus dem vorhergehendem SAP System bzw. der Reihenfolge des Imports in das vorhergehende System (bzw. den vorhergehenden Mandanten). Werden alle Aufträge in der vorgegebenen Reihenfolge importiert, so sollte das Zielsystem nach dem Import exakt den gleichen Softwarestand besitzen, wie das entsprechende Quellsystem (bzw. der entsprechende Quellmandant). Hierbei wird vorausgesetzt, dass alle Aufträge des Quellsystems aufgrund des Setups der Transportwege für alle zu beliefernden Mandanten in die Importqueue des Zielsystems aufgenommen werden und dass keinerlei manuellen Veränderungen der Importqueue erfolgen.
Jeder Eintrag in der Importqueue ist durch seine ID (TRKORR) und seinen Zielmandanten eindeutig identifiziert. Jede Kombination von TRKORR und Zielmandant kann nur genau einmal in der Importqueue vorkommen. Ist die erweiterte Transportsteuerung nicht aktiv, so entfällt das Feld für den Zielmandanten. Dieser muss vor jedem Import manuell angegeben werden. Ein derartiges Setup kann nur dann sinnvoll und ohne manuelle Zusatzaufwände funktionieren, wenn lediglich ein Zielmandant existiert.
Zusätzlich zu den Aufträgen enthält die Importqueue ein Feld für Flags, welche das Importverhalten steuern. Im Gegensatz zu Unconditional Modes wirken sich diese Flags lediglich auf einen bestimmten Importqueue-Eintrag und nicht auf den gesamten Importvorgang aus. Einige dieser Flags können auch manuell (z.B. über "tp modbuffer") gesetzt werden, in der Regel erfolgt das setzen der Flags jedoch implizit durch das Transportsteuerungsprogramm "tp".
Die in der Importqueue hinterlegten Flags können in der Importqueue-Ansicht mit Hilfe des Menüpunkts "Bearbeiten -> Mehr anzeigen" sichtbar gemacht werden. Die Zeichen in dem Feld UMO (welches entgegen der Beschreibung keine echten Uncoditional Modes enthält) haben folgende Bedeutung:

I Auftrag nochmals importieren (gesamt):
Der Import des Auftrags wird komplett neu gestartet, ohne dass überprüft wird, ob der Import bereits durchgeführt wurde. Dieses Flag wird normalerweise nur durch die Verwendung des Unconditional Modes "0" gesetzt.
J Auftrag nochmals importieren (nur mandantenabhängig):
Der Import des Auftrags wird komplett neu gestartet, ohne dass überprüft wird, ob der Import bereits durchgeführt wurde. Allerdings werden beim Import nur die mandantenabhängigen Inhalte des Auftrags berücksichtigt. ABAP-Coding und Dictionary Elemente werden beim Import mit dem J-Flag ignoriert. Dieses Flag wird normalerweise nur durch die Verwendung des Unconditional Modes "0" und bei Belieferung aus einem Mandanten des selben Systems gesetzt oder beim import in mehrere Mandanten des selben Systems gesetzt.
Wird ein Auftrag innerhalb eines Imports (SUBSET oder IMPORT ALL) in mehrere Zielmandanten importiert, so wird für alle Mandanten außer dem ersten Importmandanten implizit das J-Flag gesetzt. Diese Verhalten ist nicht übersteuerbar.
F Der Auftrag befindet sich auf eine vorläufigen Position in der Importqueue:
Der Auftrag ist im Vorgängersystem (bzw. Vorgängermandant) noch nicht abschließend (grüner Haken), sondern nur als "Überholer" (gelbes Dreieck) importiert. Jeder weitere Import im Vorgängersystem (bzw. Vorgängermandant) sorgt dafür, dass der Auftrag an das Ende der Importqueue "zurückfällt", sprich hinten wieder angehängt wird. Wird der Auftrag im Vorgängersystem (bzw. Vorgängermandant) abschließend importiert, so wird das F-Flag in der Importqueue des Folgesystems gelöscht. Dieses Flag sollte stets in Kombination mit dem I oder J-Flag stehen.
D SPAM Tag:
Wird mit der Option "tag=SPAM" gesetzt. Diese Funktion wird nur von der Transaktion SPAM benutzt.
N Keine Belieferung:
Der Auftrag wird nach dem Import nicht in die Importqueue der Folgesysteme (bzw. Folgemandanten) übernommen.
Q Fehlende SAP QA Genehmigung ignorieren
V Der zur Importqueue hinzugefügter Auftrag mit I- oder J-Flag wurde bereits importiert und wird daher auch ohne Returncode entsprechend angezeigt.

Dieses Flag wird nicht in der Importqueue gespeichert, sondern zu Laufzeit über das Unterprogramm CHECK_PRELIMINARY_IMPORT im Funktionsbaustein TMS_TP_SHOW_BUFFER ermittelt. Die zugrundeliegende Logik Ist folgende:
Bei erweiterter Transportsteuerung (CTC=1) wird ein passender Eintrag (TRKORR/CLIENT) in der Tabelle E070TC gesucht, andernfalls wird ein passender Eintrag (TRKORR) in der Tabelle E070 gesucht. Wird dieser Eintrag gefunden, so wird das V-Flag hinzugefügt. Daher ist zu beachten, dass nach einer Umstellung von CTC=0 auf CTC=1 die vor der Umstellung durchgeführten Transporte nicht erkannt werden. Als Workaround kann im diesem Fall bei Verwendung von Conigma CCM die Ermittlung des Importstatus aus der Importhistorie aktiviert werden.
X USER Tag:
Kann mit der Option "tag=X" gesetzt werden.

Doch wozu werden diese Flags nun benötigt? Im Wesentlichen geht es hier darum, unerwünschte Seiteneffekte beim Import in mehrere Mandanten zu unterbinden, indem der mandantenabhängige Teil eines Auftrags nur einmal importiert wird und die Reihenfolgeproblematik bei Überholern zu minimieren oder ganz auszuschließen. Dieses Thema würde jedoch den Umfang sprengen, so dass ich hierzu in Kürze einen gesonderten Artikel veröffentlichen werde.
Zu guter Letzt enthält die Importqueue auch Wiederaufsetzinformationen im Form von Importschritt-spezifischen Returncodes. Mit Hilfe dieser Informationen kann ein abgebrochener Import bei einem Neustart mit dem abgebrochenen Importschritt fortgesetzt werden und muss nicht alle Importschritte wiederholen. Die vollständige Wiederholung kann jedoch durch den Unconditional Mode 1 oder das I-Flag erzwungen werden.
Dieser Blog-Eintrag stellt die Thematik umfassend dar. Denken Sie beim nächsten Blick in die Importqueue nicht nur an die Reihenfolge der Aufträge, sondern behalten Sie auch die zusätzlichen Steuerinformationen im Auge, denn diese können sowohl den tatsächlichen Umfang des Imports als auch die Positionierung der einzelnen Aufträge in der Folgequeue maßgeblich beeinflussen!

Zurück