ALM Kaffekränzchen I – mit tp und die bösen Überholer

Wie das ABAP Transportsystem funktioniert 

Seit SAP 1992 mir R/3 das ABAP Transportsystem aus der Taufe hob, herrschen einige Unklarheiten wie es tatsächlich funktioniert. 

Der Änderungsantrag 

Ein offener, änderbarer Änderungsantrag (Transport Request, TR) ist nichts anderes als eine Stückliste. Die automatische Aufzeichnung von Änderungen fügt die Schlüssel der geänderten Objekte (Artefakte neuerdings) in ein paar Tabellen (siehe View E071V und Tabelle E071K), nicht aber die Objekte selbst. Die Haupt-Programm-ID ist „R3TR“, sie besitzt über 1000 unterschiedliche Objekte, die teilweise eigene Sonderlocken beim Transport beinhalten oder das Transportsystem sogar auf den Kopf stellen (zum Beispiel generieren „Condition Techniques“ Tabellen im Zielsystem) – ich beneide nicht die Entwicklerinnen des tp!  

Übrigens, die Kürzel „LIMU“ und „TABU“ gehen auf glorreiche R/2 Zeiten zurück: SAPLIMU war das Assemblerprogramm für Workbench-Objekte und SAPTABU das PG, das die SAP.ATAB pflegte, die generische Tabellendatei. 

Daher ist das Änderungsdatum eines offenen TRs rein dokumentarisch und hat keine technische Bedeutung. Und die Sperren sorgen dafür, dass jede weitere Änderung in keinem anderen TR aufgezeichnet werden wird. 

Spannend wird es erst, wenn man einen TR freigibt. Dabei wird das Betriebssystemprogramm tp aufgerufen, das mit Hilfe vom Programm R3trans gemäß der Schlüssel die Objekte in der gerade aktiven oder aktuellen Version in eine Datei auf Platte kopiert. Der TR ist ab jetzt nicht mehr änderbar, und es werden zwei Zeitstempel gesetzt (SAP tut immer alles doppelt) 

Übrigens, die TR Export History existiert, sie ist nur sehr gut versteckt: Transaktion STMS_QUEUES 

Ab jetzt ist so ein TR eine Zeitbombe, denn er enthält die Objekte im Stand des Exportzeitpunkts. Je länger man mit dem Import in das Folgesystem wartet, desto gefährlicher wird es. Denn es gilt die eiserne Regel: Die Import-Reihenfolge muss identisch sein wie die Export-Reihenfolge. Sonst drohen sogenannte Überholer (SAP spricht hier auch von „Downgrade“), also jüngere TRs mit denselben Objekten, die vor dem älteren TR importiert wurden. Wenn jetzt irgendwann der ältere TR doch importiert wird, dann überschreibt er mit seinem älteren Stand den neueren.  

Selten, dass man das will. 

Wie arbeitet tp wirklich? 

Ein Import besteht aus vielen einzelnen Schritten: Grob gesagt, die Stückliste wird Importiert, dann (wir konzentrieren uns auf Workbench-TRs, die sind spannender) werden die DDIC Objekte importiert und generiert, dann erst erfolgt der Hauptimport, schließlich werden im Rahmen der After-Import-Methoden die Objekte syntaktisch überprüft und generiert. 

Man kann dies sehr schön in der Transport-History sehen: STMS_IMPORT -> Menü -> Goto -> Import History. Wenn man in der Import History Menü -> Extras -> Personal Settings aufruft und in dem Settings-Pop-Up das Flag „Display All Import Steps“ einschaltet: 

dann kann man die einzelnen Schritte und deren Return-Code sehen: 

Wenn man mit dem Cursor auf die kleinen Buchstaben klickt, erhält man in der Nachrichtenleiste die Kurz-Beschreibung des Schrittes. Am Interessantesten sind „H Dictionary Import“ und „I Main Import“. Der Gesamt-Returncode in der „einfachen“, zusammenfassenden History-Liste ist übrigens ein errechneter, der ist nirgendswo gespeichert. Nur die Einzelschritte haben einen Returncode. Dieser errechnete Gesamt-RC wird dann von tp in die Importqueue eingetragen. 

Viele denken nun, dass wenn tp mehrere TRs gleichzeitig importiert, dass er dann für jeden TR einzeln in der Reihenfolge der Import Queue diese Import-Schritte durchführt, so als ob man jeden TR einzeln markieren und einzeln importieren würde. 

Dem ist aber nicht so. 

Was der tp beim Import von mehreren TRs auf einmal macht, ist in Wirklichkeit genau anders herum. Zuerst führt er für alle TRs in einem Aufruf den Import der Stückliste durch, dann für alle TRs in der Liste den Import der DDIC Objekte und deren Generierung, dann für alle TRs den Hauptimport und schließlich für alle TRs den Syntaxcheck und die Generierung. 

Und: All diese Schritte werden nur ausgeführt, wenn sie neu sind. Wenn sie bereits ausgeführt wurden, werden sie für den jeweiligen TR übersprungen. 

Der entscheidende Vorteil bei dieser Technik: Ist ein TR mit RC=8 „rot“, so steht er automatisch weiterhin für den Import an. 

Dies wird über den tp-Parameter REPEATONERROR gesetzt (STMS_DOM -> Selektion System) 

Wenn man jetzt einen Korrektur-Transport nachliefert, so muss man beide, den fehlerhaften und den neuen TR gleichzeitig im selben Schritt importieren. tp wird alle Schritte (Stückliste, DDIC, Hauptimport) nur für den neuen durchführen, da sie ja für den fehlerhaften alten bereits durchgeführt wurden. Der neue TR wird dabei Objekte des älteren mit der hoffentlich korrigierten Version überschreiben. Da der letzte Schritt (Syntax-Check und Generierung) für den alten noch nicht erfolgreich durchgeführt wurde, wird er nachgeholt, der alte TR wird damit (hoffentlich) „grün“. 

Und denkt daran: Der ChaRM (und damit auch Focused Build) sorgen automatisch für dieses korrekte Verhalten. 

Viel Spass beim Nachvollziehen der Theorie bei euch im System und bis zum nächsten Kaffeekränzchen.