ALM Kaffeekränzchen III – ChaRM, warum, weshalb, wieso? – Teil 2

Die Technik hinter ChaRM

Im ersten Teil haben wir uns allgemeinen Themen gewidmet. In diesem zweiten Teil unserer Sommerblog-Serie geht es um die Technik des ChaRM.

Technik

Technisch betrachtet ist der ChaRM eine Legierung bestehend aus dem CRM OneOrder, dem Post Processing Framework (PPF), dem Aufgabenplan des Schedule Managers (SCMA – da der Hauptentwickler aus dem HR Bereich kam, hat er dieses dort sehr beliebte Werkzeug zum Starten von Reports mitgebracht) und dem Transport Management System (TMS mit CTS) mit einer Prise SMSY/LMDB und IBase/Configuration Items.

Grundgerüst

Am Grundgerüst hat sich in diesen fünfzehn Jahren nichts Wesentliches geändert.

Status getriebener Workflow

Der Transport Workflow wird durch Statuswechsel realisiert. Die Statuswerte werden nicht direkt über das Statusfeld ausgewählt, sondern über PPF-Aktionen gesetzt, die beim Sichern die „Methode“ HF_SET_STATUS verwendet.

Welcher Status wann gesetzt werden kann, entscheiden wiederum sogenannte „Scheduling/Start Conditions“ des PPF Frameworks. Alle diese PPF Elemente arbeiten mit konstanten Status-Werten, was eine Änderung des Statusschemas sehr mühsam macht.

Bisher befanden wir uns noch ziemlich im CRM Standard. ChaRM spezifisch ist hingegen das ChaRM Framework.

ChaRM Framework

Zu jedem gesetzten Status gibt es eine Liste von ChaRM „Aktionen“ und „Konsistenzprüfungen“, die bei Fehler eine Meldung generieren und eventuell den Statuswechsel abbrechen.

Ein Beispiel: Beim Statuswechsel eines Änderungsdokuments auf ToBeTested wird zuerst die Aktion „CLEAR_EMPTY“ ausgeführt, die alle leeren Aufgaben und Transporte beseitigt, danach wird die Aktion „COPY_ALL_ENH“ ausgeführt, die die Stückliste des „echten“ Transports in einen frisch erzeugten Transport of Copies (ToC) kopiert, diesen exportiert und in das Testsystem importiert. Überprüft wird, ob alle Aufgaben freigegeben sind (eine Bedingung) und ob der ToC fehlerfrei in das QA-System importiert wurde (ein Ergebnischeck).

Anfangs gab es nur eine Liste von Aktionen gefolgt von den Konsistenzprüfungen. Letztere haben aber einen doppelten Charakter. Einige sind Bedingungen für Aktionen, andere überprüfen das Ergebnis von Aktionen. So begannen viele Anwender, zusätzliche Status anzulegen, um feinzutunen. Also hat SAP die spätere Ausführungszeit von Aktionen eingeführt (d.h. die Aktion wird nach den Prüfungen ausgeführt). Schließlich wurde das Ganze mit der späteren Ausführungszeit von Prüfungen abgerundet, womit auch der Erfolg der späten Aktionen überprüft werden kann.

Die Hoffnung, dass dieses wackelige vierschichtige Gebilde mit dem neuen Datenmodell zu 7.2 vereinfacht wurde (1. Ausführungsbedingung → 2. Aktion → 3. Ergebnischeck) hat sich leider nicht erfüllt.

Aufgabenplan-Reports

Die richtige Arbeit wird durch spezialisierte Reports ausgeführt, die alle mit dem Präfix „/TMWFLOW/SCMA_“ im aktiven Aufgabenplan startbereit sind und die intern über den Funktionsbaustein /TMWFLOW/TASK_START1 aufgerufen werden.

Man kann diese Aufrufe, deren Parametrisierung und die Meldungen der Laufzeit im Assignment Block „Application Log“ sehen.

Zwei Arbeitsweisen

Seit Ersteinführung gibt es zwei Varianten, den ChaRM zu leben: Projekt- und Phasen-orientiert mit der Normaler Änderung (SDMI/SMMJ) und als Menge von Einzeländerung mit dem Hotfix (SDHF/SMHF).

Diese zwei Arbeitsweisen unterscheiden sich durch die Art des Imports: Erstere (Projekt) importiert immer mit dem tp Befehl „IMPORT PROJECT ALL“ alles, was für ein ChaRM Projekt in der Import Queue bereitsteht, letztere (Hotfix) mit dem tp Befehl „IMPORT SUBSET“ genau die Transporte, die zu dem Hotfix gehören.

Da der Hotfix Transporte aus der richtigen Reihenfolge herausreißt, werden diese bei Projekt- und Phasen-Orientierung nur „vorab“ importiert, d.h. sie warten weiterhin auf den finalen Projekt-Import, um diesmal mit Einhaltung der richtigen Reihenfolge importiert zu werden. Außer: man will es nicht, weil man nur in Einzeländerungen denkt (s.u.), und daher statt der Aufgabenplanvariante SAP0 (Hotfix als Vorabimport) die Variante SAP1 verwendet, die nur finale Importe kennt.

Hotfix

Da der Hotfix der Mentalität der Einzeländerung entspricht (s.u.), war er sehr beliebt, doch er war auch sehr teuer, denn jeder Hotfix legt einen eigenen Aufgabenplan mit Präfix H an, der aus hunderten von Tabelleneinträgen besteht. Oft war das, als ob man mit einem Panzer die Zeitung holte. Seitdem die normale Änderung (SMMJ) sich in eine dringende verwandeln kann, sollte man ihn meiden und nur in der Test oder Go-Life Phase (s.u.) einsetzen, denn er ist sehr gefährlich, da er beim Statuswechsel auf ToBeTested den originalen Transport freigibt. Wehe wenn er zu lange in diesem Status verfault: Man riskiert schnell einen Downgrade durch einen Überholer.

Normale Änderung

Die normale Änderung ist hingegen sehr komfortabel und sicher. Für die funktionalen Tests innerhalb des Dokuments (Status ToBeTested) wird das QA System nur durch ToCs (s.o.) beliefert, der originale Transport bleibt änderbar, bis der Tester sein OK gibt. Zweiter Vorteil der ToCs: Sie befüllen nicht die Import Warteschlange des Folgesystems mit Vormerkungen. Erst wenn der Tester sein OK gibt, wird der echte Transport freigegeben und in das QA System importiert, und damit in das Belieferungssystem vorgemerkt.

Wenn man in diesen Vorgang nicht manuell eingreift, kann nichts schief gehen.