Management Summary: Denkt nicht nach, sondern lasst die ChaRM-Maschine laufen!

Es besteht ein jahrzehntelanger Konflikt zwischen der Art und Weise, wie SAP ABAP Transporte konzipiert und wie die SAP-Kunden sie handhaben wollen. ChaRM versucht, mit sanftem Druck den SAP Standard durchzusetzen, ist aber im Laufe der Jahre im Sinne der Kundenwünsche flexibler geworden. Doch damit öffnen sich tückische Fallen, in die ein SAP-Kunde stolpern kann.

Hier möchte ich den Konflikt beleuchten und die gefährlichsten Fallen aufdecken.

Das ABAP Transportsystem

Nicht manuell eingreifen

Seitdem es R/3 gibt, seit mehr als 30 Jahren also, hadern Entwickler:innen und Customizer:innen mit dem ABAP Change and Transport System (CTS).

Sie betrachten sich als Handwerker oder sogar Künstler und denken prinzipiell in Einzeländerungen, an denen sie liebevoll lange herumwuseln. Wenn schliesslich das kunstvoll getriebene Werkstück fertig ist, wird es in einen Transport verpackt, und wie ein Paket soll dann dieser Einzel-Transport an das Produktivsystem übergeben werden, damit es vom Operating importiert werden kann – natürlich sofort.

Doch leider für die Künstler folgt das CTS einem industriellen Paradigma: Das CTS ist wie ein Fliessband, in dem alles, aber auch wirklich alles, was per automatischer Aufzeichnung auf das Band kommt, in derselben Reihenfolge in das Produktivsystem transportiert werden muss.

Idealerweise geschieht dies automatisiert mit dem ChaRM.

Attribution I Cory M. Grenier, CC BY-SA 2.0, via Wikimedia Commons

Denn SAP, als Hersteller von Software, hat das CTS für eigene Zwecke entwickelt. Das Hauptziel des CTS ist eine konsistente Transportlandschaft. Eine Transportlandschaft ist nur dann konsistent, wenn Entwicklung, QA, eventuell PreProd und Produktion den gleichen Software-Stand haben.

Daher gilt die goldene Regel, um Chaos zu vermeiden: kein manuelles Eingreifen!

CTS – Die goldene Regel

Die Hauptregel ist also: Exportreihenfolge == Importreihenfolge

Der Transportauftrag – ein Zwitter

Während der Entwicklung und dem Customizing sammelt das CTS jede Änderung in Transportaufträgen. Es werden dabei nur die Schlüssel der geänderten Objekte aufgezeichnet, nicht die Objekte selbst, die Inhalte also.

Dies ist wichtig zu verstehen, denn deswegen ist es irrelevant, in welcher Reihenfolge die Transportaufträge angelegt werden, ebenso irrelevant ist es, in welcher Reihenfolge die Objekte aufgezeichnet werden – solange der Transportauftrag änderbar ist.

Erst bei der Freigabe (Export) des Transportauftrages liest das System (Kernel-Programme tp und R3trans) anhand jener Schlüssel die Datenbank und speichert den ausgelesenen Inhalt in eine Archivdatei auf Betriebssystemebene.

Somit haben die exportierten Inhalte den Stand eingefroren, den sie zum Zeitpunkt des Exports besassen.

Ein freigegebener Transportauftrag ist also gleichzeitig eine Sammlung von Schlüssel in der Datenbank und ein nicht mehr änderbares Archiv auf Betriebssystemebene.

Ein freigegebener Transportauftrag ist deswegen nicht mehr änderbar.

Werden die Objekte im Entwicklungssystem später erneut geändert, dann werden dieselben Schlüssel in einen neuen Transportauftrag aufgezeichnet. Bei Freigabe (Export) wird diese neuere Transport-Archivdatei die aktuellste Version der Objekte enthalten.

Downgrade und Überholer

Da jeder Transportauftrag zeitabhängige Inhalte hat, ist es von entscheidender Bedeutung, dass der ältere Transportauftrag zuerst importiert wird, und der neuere danach.

Die Downgrade Protection versucht, genau diese Fliessband-Reihenfolge zu erzwingen, indem der spätere Import des älteren Transportauftrags verhindert wird. Das Überschreiben der neueren Version eines Objektes mit einer älteren wird Downgrade genannt, der ältere Transportauftrag hat damit den neueren überholt.

With a little help from my ChaRM

Ich habe bereits die Vorzüge einer ChaRM-Einführung in diesem Blog durchdekliniert. Auch hier gilt: je mehr man stur das Maschinenband laufen lässt – ohne manuell einzugreifen!! – desto besser lebt man.

Aber nicht immer ist das Herumfummeln in dem Fliessband die Ursache für Ärger und Stress. Es reicht auch eine gut gemeinte, jedoch unzulängliche Architektur.

Problematisch wird es nämlich, wenn man auf der einen Seite Projekt und Wartung sauber trennen möchte, aber auf der anderen Seite die Empfehlungen dieser Blog-Reihe ignoriert und beide, Projekt und Wartung, in eine einzige Systemlandschaft zwingt, weil man die Kosten zusätzlicher SAP ABAP Systeme scheut.

Auf den Präsentationsfolien sieht alles schön ordentlich aus, doch in der Praxis scheppert es gewaltig.

Was passiert hier?

Da beide einen eigenen Zyklus und einen eigenen Aufgabenplan besitzen, gehören deren Transporte unterschiedlichen CTS-Projekten; es gibt keinen gemeinsamen Import, denn der ChaRM importiert nur pro Zyklus und nicht Zyklus-übergreifend.

Wartungskorrekturen gehen in der Regel viel schneller in die Produktion als die langsamen, phasengesteuerten Projektänderungen.

Attribution  II Radosław Drożdżewski (Zwiadowca21), CC BY-SA 4.0, via Wikimedia Commons

Wird daher dasselbe Objekt sowohl durch die Projektarbeit als auch durch eine Fehlerkorrektur in der Wartung geändert, so kann es leicht passieren, dass ein Wartungs-Transport die Projekt-Transporte überholt, die nur in das Testsystem importiert wurden, aber noch nicht in das Produktivsystem.

Hier haben wir ein schönes Beispiel aus dem realen Leben. Eine wichtige kundeneigene Klasse für den Vertrieb wurde von fünf verschiedenen Entwickler:innen im Rahmen von drei Änderungsdokumenten geändert:

TR	Export	Import QA	Import PreProd	Owner	Change	Status	CTS Project
DEVK922007	23.07.24 12:51	23.07.24 17:10	23.07.24 17:16	USR1	602542	TR to Retesting	DEV_P03
DEVK922158	30.07.24 12:54	30.07.24 17:10	30.07.24 17:16	USR2	602542	TR to Retesting	DEV_P03
DEVK922389	14.08.24 14:49	14.08.24 17:11	–	USR3	851879	Being Corrected	DEV_P05
DEVK922591	14.08.24 17:01	14.08.24 17:01	14.08.24 17:16	USR1	602542	TR to Retesting	DEV_P03
DEVK922725	16.08.24 11:18	16.08.24 12:11	16.08.24 12:16	USR4	602542	TR to Retesting	DEV_P03
DEVK921089	19.08.24 18:01	19.08.24 18:01	19.08.24 18:31	USR5	602490	TR to Retesting	DEV_P03

Blaue Schriftfarbe: Projekt (DEV_P03), rote Schriftfarbe Wartung (DEV_P05), die in einer 4-Systemlandschaft koexistieren. In der Tabelle sieht man sehr schön, wie der ältere Wartungstransport DEVK922389, da zu einem anderen Zyklus gehörig, den jüngeren Projekttransport DEVK922591 überschrieben hat.

Auch gab es Abhängigkeiten zwischen den Transporten, der Wartungstransport enthielt die Implementierung einer Methode, auf die sich spätere Projekttransporte bezogen. Resultat: RC=8.

Und da Wartung und Projekt wie in einem Reissverschluss miteinander verzahnt sind, ist es nicht möglich, eine sinnvolle Reihenfolge für den Go-Live zu etablieren. Eine Situation zum Haare-Ausreissen!

Attribution  III Caravaggio, Public domain, via Wikimedia Commons

In solchen wirren Fällen bleibt nur noch die «Jungbrunnenmethode» übrig.

Zwei der drei Änderungsdokumente, eins für Wartung und eins für Projekt wurden wieder im Status so zurückgesetzt, dass zwei Transportaufträge angelegt werden konnten, einen innerhalb des Wartungszyklus, den anderen innerhalb des Projektzyklus.

In beide Transporte wurde die Stückliste aller involvierten Transportaufträge kopiert und sie wurden praktisch gleichzeitig freigegeben; beide wurden dann am selben Wochenende live gesetzt. Da beide Transporte bei Freigabe den identischen jüngsten Stand enthielten, und da beide Transporte die jüngsten und letzten in der Import Queue des Produktivsystems waren, war jetzt deren Reihenfolge egal.

Doch dies funktioniert leider nur, wenn man so schnell handelt, dass keine weiteren Änderungen an den Objekten bereits vorgenommen wurden, die erst eine Tester-Freigabe benötigen würden.

Fazit:

Nie, niemals nie einen Wartungszyklus und einen Projektzyklus in ein und derselben Transportlandschaft führen, sondern entweder für Korrekturen die Vorabfunktionalität bei Work Items anwenden, oder zwei Transportlandschaften mit Retrofit etablieren.

Exkurs: Transporte Entkoppeln

Attribution V Uri-Levy, CC BY-SA 3.0, via Wikimedia Commons

Ein Lieblingssport der Entwickler:innen und Customizer:innen ist das fröhliche Umschichten der Arbeitspakete, sprich: der Änderungsdokumente.

Neue Änderungsdokumente werden angelegt, alte sollen gelöscht werden, was aber nicht geht, also sollen sie wenigstens zurückgezogen werden. Doch dies funktioniert nur, wenn diese Änderungsdokumente keine oder nur leere Transportaufträge besitzen.

Hat jedoch das Änderungsdokument Transportaufträge, die nicht leer sind, so müssen diese vorher umgehängt werden.

Umhängen eines änderbaren Transportes

Ein direktes Umhängen per drag&drop gibt es nicht.

Zuerst muss man den Transportauftrag von seinem Änderungsdokument entkoppeln, erst dann kann man ihn dem anderen Änderungsdokument zuordnen.

Beide Tätigkeiten verbergen sich im „More“ Menü des Transport Management Blocks:

In Focused Build sind diese Aktionen sichtbarer:

Transportauftrag Entkoppeln

Nach der Entkopplung ist der Transport aus der ChaRM Verwaltung verschwunden. Er hat auch die Verbindung zum CTS Projekt verloren. Eine Spur der vergangenen Zugehörigkeit bleibt aber noch (neben der ID des alten Änderungsdokuments im Kurztext)

Transportauftrag zuordnen

Wir koppeln den einsamen Transport an einen Urgent Change an, der zu einem anderen Zyklus gehört. Der Transport erhält jetzt ein neues, anderes CTS Projekt:

Und die ChaRM Verwaltung verzeichnet jetzt den Transport unter dem Aufgabenplan des Urgent Changes:

Wenn man den BAdI /TMWFLOW/ASSIGN_TRANS_DESC_UPD aktiviert hat (IMG «BAdI: Change Description after Assign Transport Request to Change Document»), dann wird die ID des neuen Änderungsdokumentes in den Transportauftrags-Kurztext eingetragen, siehe SAP Hinweis 2849745 «Rename transport request when reassigning to a new change»

Entkoppeln eines freigegebenen Transportes

Spoiler: Es geht nicht.

Im Standard wird diese Aktion nur im Status „Development“ angeboten, in allen anderen Status ist der Menü-Eintrag inaktiv:

Wir sind schlau und ändern das Customizing, um die Aktion beim Status E0009 „TestedOK“ doch zu erlauben:

Und es geht doch!

Da aber diese Aktivität sich äusserster Beliebtheit erfreut, habe ich den Report /BLUWRKS/TRANSPORT_DELETE geschrieben, der Änderungsdokumente von bereits freigegebene Transportanträgen befreit:

E voila:

Das Änderungsdokument kann jetzt endlich zurückgezogen werden.

Dieser Report geht weg wie warme Semmeln, wie man hier in München sagen würde.

Übrigens, bei Aufgabenplänen mit Central CTS kann man auch bereits freigegebene Transportaufträge umhängen, doch cCTS ist ziemlich langsam und daher unbeliebt.