{"id":37430,"date":"2024-10-01T13:12:31","date_gmt":"2024-10-01T11:12:31","guid":{"rendered":"https:\/\/www.blue.works\/?p=37430"},"modified":"2025-10-22T15:12:27","modified_gmt":"2025-10-22T13:12:27","slug":"alm-kaffeekraenzchen-vii-charm-fb-defect-correction","status":"publish","type":"post","link":"https:\/\/www.blue.works\/de\/alm-kaffeekraenzchen-vii-charm-fb-defect-correction\/","title":{"rendered":"ALM Kaffeekr\u00e4nzchen VII: ChaRM & Focused Build Defect Correction (S1TM)"},"content":{"rendered":"\n

\u00abDer Mensch ist ein Gewohnheitstier\u00bb,<\/h1>\n\n\n\n

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\u00f6nnen. Gross ist die Verwirrung, wenn der Fuss pl\u00f6tzlich in der Leere tappt. Zuerst \u00e4rgerlich, dann der Panik verfallend, suchen wir barfuss die Pantoffeln, um schliesslich die Ursache f\u00fcr ihr Verschwinden zu entdecken: Der Hund hat sie entf\u00fchrt und knabbert jetzt gen\u00fcsslich daran.<\/p>\n\n\n\n

Dies ist ein Blog, keine Doku!<\/h2>\n\n\n\n

Und genau dies passiert immer wieder mit der Focused Build \u00abDefect Correction\u00bb (DC) S1TM. Pl\u00f6tzlich 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 \u00abErfolgreich getestet<\/em>\u00bb setzen? Warum wird man in der Arbeit behindert?<\/p>\n\n\n\n

Aber in Wirklichkeit ist das Fehlen der Aktionen kein Bug, sondern ein Feature. Dieses Verhalten ist sogar dokumentiert<\/a>.<\/p>\n\n\n\n

Nun ja, jedes Mal, wenn ein Entwickler Doku liest, wird ein Baum im Amazonas gerettet \u2013 hier kann man die H\u00e4ufigkeit dieses Ph\u00e4nomens erahnen:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Ibama from Brasil, <\/em>CC BY 2.0, via Wikimedia Commons<\/em><\/a><\/p>\n\n\n\n

Da diese Panikszene ziemlich oft vorkommt, m\u00f6chte ich mit diesem Blog etwas zur Aufkl\u00e4rung des Sachverhalts beitragen. Da ein Blog keine Doku ist, wird er auch von Entwicklern gelesen werden! Oder?<\/p>\n\n\n\n

Einakter \u00abTesten ist nicht immer gleich Testen\u00bb<\/h1>\n\n\n\n

Der Einfachheit halber zeigen wir das Schema eines Wasserfall-Projekts. W\u00e4hrend das Release in der Phase \u00abPrepare\u00bb<\/em> ist, wird auf Work Package (WP) Ebene im Konsolidierungssystem (QA) getestet. Dies sind die Single Functional Tests (SFT – gem\u00e4ss der Focused Build Methodology testen die Entwickler selbst die erw\u00fcnschte Funktionalit\u00e4t) und die Acceptance Tests (AT).<\/p>\n\n\n\n

Legt das Release Management den grossen Schalter um (Handover to Release<\/em>), 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\u00e4chste Release in sich konsistent und korrekt ist, und dass das Release keine bereits vorhandene Funktionalit\u00e4t kaputtmacht.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Szene I: Der gewohnte Gang<\/h2>\n\n\n\n

Das Projekt befindet sich in der langen Realisierungsphase, das Release ist monatelang im Status \u00abPrepare\u00bb<\/em>, die Entwicklung arbeitet fleissig an der Implementierung der Requirements.<\/p>\n\n\n\n

Die Work Items (WI) eines Work Packages sind einzeln getestet worden und f\u00fcr korrekt befunden. Nun wird das Work Package selbst getestet (Single Functional Test, Acceptance Test).<\/p>\n\n\n\n

Der Test der Work Packages erfolgt im QA-System. Findet man jetzt einen Fehler, der eine Korrektur ben\u00f6tigt, kann man dem WI keinen weiteren Transport hinzuf\u00fcgen, denn aus dem Status \u00abSuccessfully Tested\u00bb<\/em> kommt das WI nicht mehr zur\u00fcck.<\/p>\n\n\n\n

Nein, man muss aus dem WP heraus eine Defect Correction (DC) anlegen, um einen Transport f\u00fcr die Korrektur zu erhalten. Dabei wechselt das WP in den Status \u00abIn Repair<\/em>\u00bb.<\/p>\n\n\n\n

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 \u00abAction<\/em>\u00bb Button ausw\u00e4hlte.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Wird die Korrektur best\u00e4tigt, so kehrt das WP automatisch in den Status \u00abTo Be Tested<\/em>\u00bb zur\u00fcck – hoffentlich zum letzten Mal.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Szene II: Huch, wo sind meine Pantoffeln \u2013 \u00e4h – Aktionen?<\/h2>\n\n\n\n

Endlich erreicht das Release den wichtigen Meilenstein des Endes der Entwicklung, das Release Management setzt das Release in den Status \u00abTest<\/em>\u00bb. Das Test-Management tritt ins Rampenlicht und startet die vorbereiteten Testpl\u00e4ne, deren Testpakete die zugeordneten Business ExpertInnen, Key User, TesterInnen abarbeiten.<\/p>\n\n\n\n

Wenn diese einen Fehler entdecken, so m\u00fcssen sie direkt aus dem Testschritt heraus einen Focused Build Defect (S1DM) anlegen. Entscheidet die Entwicklung w\u00e4hrend 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 \u00e4nderbare Transporte f\u00fcr die Korrekturen anbietet.<\/p>\n\n\n\n

Steht die Defect Correction zum Testen an, so wandert automatisch die Hand zum \u00abAction<\/em>\u00bb Button, um die Testentscheidung auszuf\u00fchren, doch – Schreck lass nach! – der \u00abAction<\/em>\u00bb Button ist pl\u00f6tzlich leer! Die Defect Correction zeigt uns pl\u00f6tzlich die kalte Schulter, obwohl der Status derselbe wie immer ist.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

H\u00e4tten wir die anfangs referenzierte Dokumentation gelesen (aber echte EntwicklerInnen lesen keine Doku!), so w\u00fcssten wir, nach etwas Bl\u00e4ttern, dass:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Es heisst, der Tester oder die Testerin muss nicht die Defect Correction, sondern den vorgelagerten Defect best\u00e4tigen, nur so wird die Defect Correction automatisch aus ihrem Status \u00abTransport to Retesting<\/em>\u00bb befreit.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Dieses abweichende Verhalten der Defect Correction S1TM, wenn sie aus einem Testschritt heraus \u00fcber einen Defect erzeugt wurde, muss beim Start der Testphase Teil des Trainings sein. So vermeidet man unn\u00f6tige Aufregung.<\/p>\n\n\n\n

Backstage<\/h1>\n\n\n\n

Da dies ein technischer Blog ist, will ich kurz zeigen, woher dieses schillernde Verhalten der Defect Correction herr\u00fchrt.<\/p>\n\n\n\n

PPF-Aktion mit Bedingungen<\/h2>\n\n\n\n

Status-Wechsel werden im ChaRM (und Focused Build ist ein ChaRM mit Korsett und R\u00fcschen) per PPF-Aktionen<\/a> (Post Processing Framework) durchgef\u00fchrt.<\/p>\n\n\n\n

Schauen wir uns mal in Transaktion CRMC_ACTION_DEF<\/strong> \u00abAktionsprofil Definieren<\/em>\u00bb eine der zwei Aktionen an, die beim Testen einer DC angeboten werden, zum Beispiel die PPF-Aktion \u00abConfirm Defect Correction with Transport<\/em>\u00bb:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Diese Aktion setzt bei Ausf\u00fchrung den Status S1TMHEAD E0012<\/strong> \u00abConfirmed<\/em>\u00bb:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Es reicht aber nicht, dass eine PPF-Aktion definiert ist; sie muss n\u00e4mlich auch eingeplant werden, sonst ist sie nicht ausf\u00fchrbar und wird nicht im \u00abAction<\/em>\u00bb Men\u00fc angeboten.<\/p>\n\n\n\n

Die Einplanung wird mit der sehr langsamen und sperrigen Transaktion CRMC_ACTION_CONF<\/strong> \u00abAktionsprofil Konfigurieren<\/em>\u00bb eingerichtet.<\/p>\n\n\n\n

Diese Einplanung ist \u00fcblicherweise mit einer Einplanungsbedingung gekn\u00fcpft:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Erst wenn die Bedingung erf\u00fcllt ist, taucht die Aktion im \u00abAction<\/em>\u00bb Men\u00fc auf, damit der Anwender sie ausw\u00e4hlen und ausf\u00fchren kann.<\/p>\n\n\n\n

So sieht die Einplanungsbedingung in dem etwas eigenwilligen Regel-Editor aus:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Die Aktion \u00abConfirm Defect Correction with Transport<\/em>\u00bb wird nur dann angeboten, wenn der aktuelle Status S1TMHEAD E0004<\/strong> \u00abTransport to Retesting<\/em>\u00bb ist (++<\/strong> ist eine Wildcard), der Vorgang fehlerfrei ist, und<\/u><\/strong> (!) der Parameter DOCUMENT_ASSIGNED<\/strong> nicht<\/u><\/strong> gesetzt ist! CONFIRM_ALLOWED<\/strong> ist ein zus\u00e4tzlicher bedingender Parameter.<\/p>\n\n\n\n

Die meisten Parameter in diesem Parameter-Container, die in dieser Bedingung ausgewertet werden, stammen aus dem gerade aktiven \u00abBusiness Object<\/em>\u00bb, hier BUS2000116<\/strong> \u00abS<\/em><\/strong>ervice<\/em>\u00bb. Man erkennt sie am Pr\u00e4fix \u00ab&CRM Service Process.<\/em>\u00bb. Diese werden automatisch zur Laufzeit gef\u00fcllt.<\/p>\n\n\n\n

\u00dcbrigens, das \u00abS<\/em><\/strong>\u00bb, das automatisch der Kurzbeschreibung der Transportauftr\u00e4ge vorangestellt wird, die durch den ChaRM\/FB erzeugt werden, stammt aus diesem \u00abS<\/em><\/strong>ervice<\/em>\u00bb.<\/p>\n\n\n\n

Man kann aber zus\u00e4tzliche eigene Parameter definieren, die muss man aber selbst durch eigenes Coding bef\u00fcllen.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Die Technik hinter den Bedingungen<\/h2>\n\n\n\n

Dieses Bef\u00fcllen eigener, zus\u00e4tzlicher Parameter geschieht in einer Implementierung des Business Add-Ins (BAdI) CONTAINER_PPF<\/strong>. F\u00fcr die Pflege von BAdIs ist die Transaktion SE18<\/strong> zust\u00e4ndig.<\/p>\n\n\n\n

Hier die entscheidende Implementierung von Focused Build (SE18 -> Men\u00fc Implementation -> Overview):<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Wir betreten jetzt das Innerste der Maschine, n\u00e4mlich die FB Implementierung:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Das Vorgehen ist ziemlich linear.<\/p>\n\n\n\n

Existiert im Container, der von der Einplanungsbedingung ausgewertet wird, ein bestimmter Parameter, wird die dazugeh\u00f6rige Methode aufgerufen, die freundlicherweise genauso heisst und die den Wert des Parameters bestimmt.<\/p>\n\n\n\n

    \n
  • DOCUMENT_ASSIGNED()<\/strong> liest die direkte Verkn\u00fcpfung zu einem Vorg\u00e4ngerbeleg, und falls ein Defect S1DM mit dem aktuellen Vorgang verkn\u00fcpft ist, wird \u201aX<\/em>\u2018 als Wert eingetragen.
    Damit wird die Einplanungsbedingung nicht<\/strong> erf\u00fcllt, und die Aktion wird also nicht<\/strong> angeboten. Anders gesagt: ist die Defect Correction ein Folgebeleg eines Defects, dann kann man sie nicht direkt best\u00e4tigen.<\/li>\n\n\n\n
  • CONFIRM_ALLOWED()<\/strong> schliesst eine L\u00fccke.
    Sie geht rekursiv die Belegflusskette r\u00fcckw\u00e4rts, 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\u00e4tigung des Defects die Defect Correction ebenfalls best\u00e4tigt. Ich sch\u00e4tze, dieser Fall tritt \u00e4usserst selten auf, daher habe ich ihn nicht ausprobiert.<\/li>\n<\/ul>\n\n\n\n

    Ich hoffe, das schillernde Verhalten der Focused Build Defect Correction S1TM ausreichend erhellt zu haben und so die Verwirrung entwirrt zu haben.<\/p>\n\n\n\n

    Danke f\u00fcr die Lekt\u00fcre<\/p>\n\n\n\n

    <\/p>\n","protected":false},"excerpt":{"rendered":"

    wusste schon Gustav Freytag\u00a0. Wenn wir aufstehen, erwarten wir die Pantoffeln immer an derselben Stelle neben dem Bett, damit wir sie, ohne hinzuschauen anziehen k\u00f6nnen. Gross ist die Verwirrung, wenn der Fuss pl\u00f6tzlich in der Leere tappt. Zuerst \u00e4rgerlich, dann der Panik verfallend, suchen wir barfuss die Pantoffeln, um schliesslich die Ursache f\u00fcr ihr Verschwinden zu entdecken: Der Hund hat sie entf\u00fchrt und knabbert jetzt gen\u00fcsslich daran.<\/p>\n","protected":false},"author":16,"featured_media":37754,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[344],"tags":[336],"class_list":["post-37430","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-alm-kaffeekraenzchen-das-alm-magazin","tag-kaffeekraenzchen"],"acf":[],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/www.blue.works\/wp-content\/uploads\/2024\/10\/Pic01_full-1-scaled.jpg","_links":{"self":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/37430","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/users\/16"}],"replies":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/comments?post=37430"}],"version-history":[{"count":6,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/37430\/revisions"}],"predecessor-version":[{"id":43257,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/posts\/37430\/revisions\/43257"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/media\/37754"}],"wp:attachment":[{"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/media?parent=37430"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/categories?post=37430"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.blue.works\/de\/wp-json\/wp\/v2\/tags?post=37430"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}