«Der Mensch ist ein Gewohnheitstier»,

wusste schon Gustav Freytag . Wenn wir aufstehen, erwarten wir die Pantoffeln immer an derselben Stelle neben dem Bett, damit wir sie, ohne hinzuschauen anziehen können. Gross ist die Verwirrung, wenn der Fuss plötzlich in der Leere tappt. Zuerst ärgerlich, dann der Panik verfallend, suchen wir barfuss die Pantoffeln, um schliesslich die Ursache für ihr Verschwinden zu entdecken: Der Hund hat sie entführt und knabbert jetzt genüsslich daran.

Dies ist ein Blog, keine Doku!

Und genau dies passiert immer wieder mit der Focused Build «Defect Correction» (DC) S1TM. Plötzlich sind die gewohnten Aktionen verschwunden. In Panik rennt der Entwickler oder die Entwicklerin quasi barfuss zum Focused Build und ChaRM Experten, und fragt vorwurfsvoll, was diesmal schon wieder kaputt gegangen ist. Warum kann man nicht die Defect Correction wie bisher auf «Erfolgreich getestet» setzen? Warum wird man in der Arbeit behindert?

Aber in Wirklichkeit ist das Fehlen der Aktionen kein Bug, sondern ein Feature. Dieses Verhalten ist sogar dokumentiert.

Nun ja, jedes Mal, wenn ein Entwickler Doku liest, wird ein Baum im Amazonas gerettet – hier kann man die Häufigkeit dieses Phänomens erahnen:

Ibama from Brasil, CC BY 2.0, via Wikimedia Commons

Da diese Panikszene ziemlich oft vorkommt, möchte ich mit diesem Blog etwas zur Aufklärung des Sachverhalts beitragen. Da ein Blog keine Doku ist, wird er auch von Entwicklern gelesen werden! Oder?

Einakter «Testen ist nicht immer gleich Testen»

Der Einfachheit halber zeigen wir das Schema eines Wasserfall-Projekts. Während das Release in der Phase «Prepare» ist, wird auf Work Package (WP) Ebene im Konsolidierungssystem (QA) getestet. Dies sind die Single Functional Tests (SFT – gemäss der Focused Build Methodology testen die Entwickler selbst die erwünschte Funktionalität) und die Acceptance Tests (AT).

Legt das Release Management den grossen Schalter um (Handover to Release), wird das gesamte Release in das Preproduction-System weitergeschoben. Hier erfolgen jetzt die grossen Integrations- und Regressionstests (FIT und RT) durch Business-User. Denn es soll dem Business bewiesen werden, dass das nächste Release in sich konsistent und korrekt ist, und dass das Release keine bereits vorhandene Funktionalität kaputtmacht.

Szene I: Der gewohnte Gang

Das Projekt befindet sich in der langen Realisierungsphase, das Release ist monatelang im Status «Prepare», die Entwicklung arbeitet fleissig an der Implementierung der Requirements.

Die Work Items (WI) eines Work Packages sind einzeln getestet worden und für korrekt befunden. Nun wird das Work Package selbst getestet (Single Functional Test, Acceptance Test).

Der Test der Work Packages erfolgt im QA-System. Findet man jetzt einen Fehler, der eine Korrektur benötigt, kann man dem WI keinen weiteren Transport hinzufügen, denn aus dem Status «Successfully Tested» kommt das WI nicht mehr zurück.

Nein, man muss aus dem WP heraus eine Defect Correction (DC) anlegen, um einen Transport für die Korrektur zu erhalten. Dabei wechselt das WP in den Status «In Repair».

Seit Monaten konnte man innerhalb der DC entscheiden, ob der Fehler beseitigt wurde oder ob er immer noch vorhanden ist, indem man routiniert die entsprechende Aktion aus dem «Action» Button auswählte.

Wird die Korrektur bestätigt, so kehrt das WP automatisch in den Status «To Be Tested» zurück – hoffentlich zum letzten Mal.

Szene II: Huch, wo sind meine Pantoffeln – äh – Aktionen?

Endlich erreicht das Release den wichtigen Meilenstein des Endes der Entwicklung, das Release Management setzt das Release in den Status «Test». Das Test-Management tritt ins Rampenlicht und startet die vorbereiteten Testpläne, deren Testpakete die zugeordneten Business ExpertInnen, Key User, TesterInnen abarbeiten.

Wenn diese einen Fehler entdecken, so müssen sie direkt aus dem Testschritt heraus einen Focused Build Defect (S1DM) anlegen. Entscheidet die Entwicklung während der Bearbeitung des Defects, dass eine Korrektur notwendig ist, um den Fehler zu beheben, so legt sie aus dem Defect heraus die bekannte Defect Correction an, die wie bisher neue und änderbare Transporte für die Korrekturen anbietet.

Steht die Defect Correction zum Testen an, so wandert automatisch die Hand zum «Action» Button, um die Testentscheidung auszuführen, doch – Schreck lass nach! – der «Action» Button ist plötzlich leer! Die Defect Correction zeigt uns plötzlich die kalte Schulter, obwohl der Status derselbe wie immer ist.

Hätten wir die anfangs referenzierte Dokumentation gelesen (aber echte EntwicklerInnen lesen keine Doku!), so wüssten wir, nach etwas Blättern, dass:

Es heisst, der Tester oder die Testerin muss nicht die Defect Correction, sondern den vorgelagerten Defect bestätigen, nur so wird die Defect Correction automatisch aus ihrem Status «Transport to Retesting» befreit.

Dieses abweichende Verhalten der Defect Correction S1TM, wenn sie aus einem Testschritt heraus über einen Defect erzeugt wurde, muss beim Start der Testphase Teil des Trainings sein. So vermeidet man unnötige Aufregung.

Backstage

Da dies ein technischer Blog ist, will ich kurz zeigen, woher dieses schillernde Verhalten der Defect Correction herrührt.

PPF-Aktion mit Bedingungen

Status-Wechsel werden im ChaRM (und Focused Build ist ein ChaRM mit Korsett und Rüschen) per PPF-Aktionen (Post Processing Framework) durchgeführt.

Schauen wir uns mal in Transaktion CRMC_ACTION_DEF «Aktionsprofil Definieren» eine der zwei Aktionen an, die beim Testen einer DC angeboten werden, zum Beispiel die PPF-Aktion «Confirm Defect Correction with Transport»:

Diese Aktion setzt bei Ausführung den Status S1TMHEAD E0012 «Confirmed»:

Es reicht aber nicht, dass eine PPF-Aktion definiert ist; sie muss nämlich auch eingeplant werden, sonst ist sie nicht ausführbar und wird nicht im «Action» Menü angeboten.

Die Einplanung wird mit der sehr langsamen und sperrigen Transaktion CRMC_ACTION_CONF «Aktionsprofil Konfigurieren» eingerichtet.

Diese Einplanung ist üblicherweise mit einer Einplanungsbedingung geknüpft:

Erst wenn die Bedingung erfüllt ist, taucht die Aktion im «Action» Menü auf, damit der Anwender sie auswählen und ausführen kann.

So sieht die Einplanungsbedingung in dem etwas eigenwilligen Regel-Editor aus:

Die Aktion «Confirm Defect Correction with Transport» wird nur dann angeboten, wenn der aktuelle Status S1TMHEAD E0004 «Transport to Retesting» ist (++ ist eine Wildcard), der Vorgang fehlerfrei ist, und (!) der Parameter DOCUMENT_ASSIGNED nicht gesetzt ist! CONFIRM_ALLOWED ist ein zusätzlicher bedingender Parameter.

Die meisten Parameter in diesem Parameter-Container, die in dieser Bedingung ausgewertet werden, stammen aus dem gerade aktiven «Business Object», hier BUS2000116 «Service». Man erkennt sie am Präfix «&CRM Service Process.». Diese werden automatisch zur Laufzeit gefüllt.

Übrigens, das «S», das automatisch der Kurzbeschreibung der Transportaufträge vorangestellt wird, die durch den ChaRM/FB erzeugt werden, stammt aus diesem «Service».

Man kann aber zusätzliche eigene Parameter definieren, die muss man aber selbst durch eigenes Coding befüllen.

Die Technik hinter den Bedingungen

Dieses Befüllen eigener, zusätzlicher Parameter geschieht in einer Implementierung des Business Add-Ins (BAdI) CONTAINER_PPF. Für die Pflege von BAdIs ist die Transaktion SE18 zuständig.

Hier die entscheidende Implementierung von Focused Build (SE18 -> Menü Implementation -> Overview):

Wir betreten jetzt das Innerste der Maschine, nämlich die FB Implementierung:

Das Vorgehen ist ziemlich linear.

Existiert im Container, der von der Einplanungsbedingung ausgewertet wird, ein bestimmter Parameter, wird die dazugehörige Methode aufgerufen, die freundlicherweise genauso heisst und die den Wert des Parameters bestimmt.

• DOCUMENT_ASSIGNED() liest die direkte Verknüpfung zu einem Vorgängerbeleg, und falls ein Defect S1DM mit dem aktuellen Vorgang verknüpft ist, wird ‚X‘ als Wert eingetragen.
  Damit wird die Einplanungsbedingung nicht erfüllt, und die Aktion wird also nicht angeboten. Anders gesagt: ist die Defect Correction ein Folgebeleg eines Defects, dann kann man sie nicht direkt bestätigen.
• CONFIRM_ALLOWED() schliesst eine Lücke.
  Sie geht rekursiv die Belegflusskette rückwärts, und falls hier ein Defect S1DM gefunden wird, wird ein Leerzeichen gesetzt, wodurch die Einplanungsbedingung ebenfalls nicht angeboten wird.
  Man kann also nicht mogeln, indem man zwischen dem Defect und der Defect Correction eine andere Vorgangsart schaltet.
  Wobei ich mich frage, ob dann die Automatik immer noch funktioniert, also ob die Bestätigung des Defects die Defect Correction ebenfalls bestätigt. Ich schätze, dieser Fall tritt äusserst selten auf, daher habe ich ihn nicht ausprobiert.

Ich hoffe, das schillernde Verhalten der Focused Build Defect Correction S1TM ausreichend erhellt zu haben und so die Verwirrung entwirrt zu haben.

Danke für die Lektüre