ALM Kaffeekränzchen IV – ChaRM Transport Risks – Missing Transport und die Transport-History

Die strenge Nanny

Kennt Ihr das noch aus Eurer Jugend, als eine viel zu strenge Aufsichtsperson die gesamte Welt als einen einzigen Haufen von Risiken betrachtete und Euch das Ausgehen verbieten wollte? Mit dem Erfolg, dass Ihr an kein einziges Risiko mehr geglaubt habt?

Der ChaRM hat diese panische Haltung übernommen und riskiert, in dieselbe Falle des Fehlalarms zu tappen. Auf der anderen Seite: Vielleicht lieber eine Alarmierung zu viel, als eine zu wenig? 
Das richtige Mass, muss wohl jeder für sich selbst definieren.

Fehlalarm

“Transport Risiken“: Diesen Spalte gibt es im Assignment Block „Landscape“ eines Change Dokuments:

Hui! Ein gelbes Warndreieck! Da schau her! Als gewissenhafte Change Manager fühlen wir uns in die Pflicht genommen und wir untersuchen sofort das gemeldete Risiko. Bei intensivem Hinschauen mit der Lupe entdecken wir, dass die „1“ die typische blaue Farbe für Links hat, also spitzen wir die Maus, damit wir diesen winzigen Absprungpunkt treffen. Und siehe da! Es öffnet sich ein Pop-Up:

Ach so. Jetzt sind wir aber enttäuscht. Ist doch klar, dass der Transport „fehlt“. Denn er steht ja erst zum Import an, „To be Imported“ sagt sein Transport-Status. Dieser banale Sachverhalt erinnerst stark an den Spruch über den Maréchal de La Palice, dass wenn er nicht bereits tot wäre, er noch am Leben sein würde.

Doch wie werden diese „fehlenden“ Transporte genau ermittelt? Da diese Funktionalität ursprünglich für das Quality Gate Management gebaut wurde, befindet sich die SAP Hilfe zu den «Risiken» dort. Trotzdem tauchen immer wieder Fragen auf, daher soll hier eine vertiefende Ergänzug gegeben werden.

Wie entsteht die Zahl “Missing Transports”?

Die ChaRM Haupt-Verwaltungstabelle ist die /TMWFLOW/TRORD_N. Zunächst werden alle Transporte eines Change Dokuments (oder eines Zyklus), die den Status „Freigegeben“ haben, identifiziert.

Jetzt fängt der ChaRM für jedes Import-System eines Transport-Tracks an, in der zweiten wichtigen Tabelle, der /TMWFLOW/TRACK_N, zu untersuchen, ob für die vorhin identifizierten Transporte exakt soviele Einträge mit Step I wie Import und einem der Status S (Success), W(Warning) oder R (Repaired) vorhanden sind.

Diese Tabelle spiegelt den Inhalt der Transport-History (TPALOG) des verwalteten Systems wieder. Falls sich Unstimmigkeiten zwischen der ChaRM Tracking Tabelle und der realen Transport History des verwalteten Systems eingeschlichen haben, kann man mit diesen zwei Funktionen des Change Admin Cockpit den aktuellen Stand in dem Solution Manager erneuern:

Falls also tatsächlich Transporte gefunden wurden, die in dieser Tracking Tabelle noch nicht als importiert oder repariert gelten, wird noch kurz geschaut, ob sie im Vorgängersystem, falls es ein solches gibt, importiert worden sind.

Wenn ja, dann gilt dieser Transport als fehlend. Wenn er aber auch im Vorgängersystem fehlt, wird er hier ignoriert, denn der Transport wird bereits beim Vorgänger-System als fehlend angegeben.

Eine besondere Rolle spielen Transporte von Kopien (ToC) bei Normal Changes (SMMJ) bei einem Konsolidierungssystem (das erste System, das auf das Quell-System folgt, üblicherweise das QA-System). Hier wird nämlich korrekterweise immer nur der letzte, jüngste ToC auf erfolgreichen Import überprüft.

Fehlerhaft importierte Transporte, also solche mit dem Return-Code größer oder gleich 8, werden ebenso aus der Menge gelöscht, denn diese erhalten einen eigenen Eintrag unter den „Fehlerhaften“ („Transport Error“), siehe Kapitel 2.1 unten.

Damit dieser zarte Mechanismus auch nach einer Systemkopie (System Refresh) funktioniert, muss man die Schritte 2 a ii aus Hinweis 2259615„ChaRM/QGM: Correct Procedure of Refreshing a System Managed by a SAP Solution Manager System“ befolgen.

Pädagogische Kosmetik

Wir können die Berechnung der „fehlenden“ Transporte nicht verändern, aber wir können entscheiden, welche Fälle tatsächlich ein „gelbes“ Warndreieck verdienen und welche nicht.

Es gibt nämlich im Customizing die Möglichkeit, die Anzeige des „Risk-Status“ zu beeinflussen.

Zunächst müssen wir den standard Eintrag für die grüne Led klonen, damit der Schlüssel nicht länger als zehn Zeichen ist:

Danach ersetzen wir für alle Status, bei denen es selbstverständlich ist, dass der Import fehlt, die Warnung mit unserer neuen grünen Led, wobei wir auch die Meldung /TMWFLOW/TRANSPORT 012 „Missing Transports“ mit der Meldung 101 „To Be Imported“ ersetzen:

Abbildung 5 Bei allen Vorabimport Status ist MT grün

Keine Panik

Auf der Titanik.

Und schon entspricht die Anzeige der Realität:

Die grüne LED sagt uns, wir brauchen uns nicht um diese Zeile zu kümmern.

So wissen wir andererseits, dass, wenn doch ein gelbes Warndreieck erscheint, wir dann besser nachschauen sollten.

Weitere Risiken

Zwei Risiken, nämlich „Open Transports“ im Entwicklungssystem und „Transport Error“ in den Import-Systemen sind selbsterklärend, letzterer wurde bereits oben erwähnt.

Synchronization Error

Interessant ist noch der Typ „Synchronization Error“. Er ist ein Sonderfall des „Missing Transport“, der in Landschaften vorkommen kann, die mehr als einen Transport Track haben, also mehr als ein Quell-System mit dazugehörigen Produktivsystem. Beliebt ist zum Beispiel eine Landschaft mit einem ERP Track und parallel dazu einen zweiten Track mit einem Masterdata, oder einem Global Trade System.

Er ensteht folgendermaßen.

Zunächst werden für die jeweiligen Import-Systeme (erneut!) die „Missing Transports“ für beide (wir vereinfachen) Tracks ermittelt. Sind die Transporte des Import-Systems des einen Track vollständig importiert, die des parallelen aber nicht, so werden die nicht importierten Transporte des mangelhaften Tracks als „Synchronization Error“ gezählt und aufgelistet.