Ein Tools-Release-Upgrade oder ein Sprung von 9.1 auf 9.2 wird in dem Moment als "erfolgreich" abgenommen, in dem die neue Umgebung den Login besteht. Das ist der einfache Teil. Der schwierige Teil — und der Teil, der die späten Post-Go-Live-Überraschungen erzeugt, vor denen jede JDE-Installation irgendwann Angst bekommt — ist die JD Edwards EnterpriseOne UBE-Output-Validierung für Upgrade-Tests. Die Trial Balance, die um einen Cent vom Baseline-Wert abweicht, das Invoice Register, das Kundennamen in einer leicht anderen Reihenfolge druckt, der Period Close, der korrekt summiert, aber den nachgelagerten Konsolidierungsfeed bricht, weil zwei Spalten ihre Position getauscht haben: Das sind die Fehler, die drei Wochen im PD-Betrieb sichtbar werden, wenn die Personen, die sie hätten finden können, bereits im nächsten Projekt sind.

Die Lösung ist nicht mehr Aufwand oder mehr Tester; die Lösung ist eine strukturierte Vergleichspipeline, die dieselbe UBE mit denselben Inputs auf dem alten Release und dem neuen Release ausführt, die Outputs normalisiert und dem Team in Minuten sagt, welche Jobs unverändert sind, welche aus bekannten Gründen abweichen und welche aus Gründen abweichen, die untersucht werden müssen.

Was "derselbe Output" nach einem Upgrade wirklich bedeutet

Die erste Falle in jedem Upgrade-Testprojekt ist, "derselben Output" als binäre Prüfung zu behandeln. Das ist fast nie der Fall. Ein UBE-PDF, das im Header des Baseline-Laufs "Run Date: 2024-09-15" enthielt, enthält im Ziellauf "Run Date: 2024-09-22", und ein naiver Byte-Level-Diff markiert jede Seite als unterschiedlich. Dasselbe gilt für den JOBNBR-Header, den gedruckten Benutzernamen, den Servernamen auf dem Deckblatt und die Seitenzahlen, die sich verschieben, wenn eine Datenzeile auf einer anderen Seitengrenze umbricht.

Nützlicher Output-Vergleich behandelt Abweichungen in drei Kategorien. Kategorie eins ist erwartet und ignorierbar — Datumsangaben, Jobnummern, Serverkennungen, Generierungszeitstempel. Kategorie zwei ist erwartet und beabsichtigt — Änderungen, die das Upgrade einführen soll, etwa eine neue Spalte durch ein Application Update oder ein umbenanntes Feld nach einem Spec Merge. Kategorie drei ist unerwartet — alles, was das Upgrade nicht berühren sollte, jetzt aber anders aussieht.

Die einzige Aufgabe der Validierungspipeline ist, jeden Output mit hoher Sicherheit in eine dieser drei Kategorien zu schieben. Kategorie eins wird durch Normalisierungsregeln gelöst, die vor dem Vergleich angewendet werden. Kategorie zwei wird durch ein Known-Changes-Register gelöst, das vom Team gepflegt wird. Kategorie drei ist das, was der Regression Report sichtbar macht und was das Team tatsächlich untersuchen muss.

Die Baseline aufbauen, bevor das Upgrade-Fenster schließt

Eine Baseline, die erst erfasst wird, nachdem das Upgrade bereits begonnen hat, ist überhaupt keine Baseline. Die erste Disziplin besteht darin, die Quellumgebung zu sperren — typischerweise PYPrototype environment — die JDE-Teststufe, in der promoteter Code gegen eine produktionsnahe Datenkopie getestet wird, bevor er nach PD verschoben wird. Der natürliche Ort für Baseline-UBEs, weil die Daten der Produktion ähneln. mit einer Kopie aktueller Produktionsdaten — und jede in-scope UBE mit sorgfältig konservierten Inputs darauf auszuführen. Die PDF-Outputs gehen in einen versionierten Ordner; Tabellen-Outputs, bei denen UBEs in F*-Tabellen schreiben, statt nur PDFs zu erzeugen, werden mit Zeilenzählungen, Summenprüfungen und einem Hash der relevanten Spalten gesnapshottet.

Die Liste der in-scope UBEs ist selbst ein Deliverable. In einer typischen mittelgroßen Installation umfasst der vollständige UBE-Katalog 300 bis 700 Jobs, aber die in-scope Liste für Upgrade-Validierung ist deutlich kleiner — die 40 bis 80 Reports, die das Business tatsächlich regelmäßig ausführt, plus die standardmäßigen Finanz- und Operations-Reports, die den Period Close treiben. Die Regel, die ich anwende: Jede UBE, die in F986110 innerhalb der letzten 90 Tage mit einem erfolgreichen Lauf erscheint, ist in scope; alles Ältere ist entweder dormant oder durch einen anderen Mechanismus ersetzt, und das Team sollte es bestätigen, bevor es hinzugefügt wird.

Das Input-Set für jede UBE ist der Teil, der am häufigsten übersprungen wird. Eine UBE hat Processing Options, Data-Selection-Kriterien und datumsgetriebenes Verhalten. Der Baseline-Lauf muss alle drei exakt erfassen — Processing Options als versioniertes PO-Template gespeichert, Data Selection in eine Datei serialisiert und das Systemdatum über das "as of"-Datum der UBE fixiert, wenn unterstützt. Ohne diese Disziplin kann ein "anderer" Output drei Monate später einfach ein anderer Input sein, und die Validierung erzeugt kein brauchbares Signal.

Outputs normalisieren, damit der Diff etwas bedeutet

Normalisierung ist das, was eine funktionierende Validierungspipeline von einem Rauschgenerator unterscheidet. Die Pipeline muss sowohl Baseline- als auch Ziel-Outputs durch denselben Satz von Regeln transformieren, bevor irgendein Vergleich läuft. Die Regeln sind nicht exotisch; sie werden einfach regelmäßig übersehen.

Für PDF-Outputs entfernt die Standardnormalisierung den Cover-Page-Header, also Run Date, JOBNBR, User und Server, entfernt Seitenzahlen, kollabiert wiederholte Leerzeichen und ersetzt das gedruckte Systemdatum überall dort, wo es erscheint, durch ein festes Token. Bei einem regulierten Output, bei dem das Deckblatt selbst relevant ist — Payroll-Register, Steuerformulare, Audit-Reports — wird das Deckblatt vom Body-Diff ausgeschlossen und separat gegen einen kleineren Satz von Regeln verglichen, den die Auditoren akzeptieren.

Für Table-Output-UBEs, die in F-Tabellen schreiben, bedeutet Normalisierung, die Output-Tabelle auf die Spalten zu projizieren, die tatsächlich den Business-Zustand darstellen. Audit-Spalten wie USER, PID, JOBN, UPMJ, UPMT und TDAY werden vom Diff ausgeschlossen, weil sie zwischen Läufen immer unterschiedlich sind und in diesem Kontext keine Business-Bedeutung tragen. Die verbleibenden Spalten werden vor dem Hash in eine kanonische Reihenfolge sortiert, damit eine UBE, die dieselben Zeilen in einer anderen physischen Reihenfolge schreibt, was nach einer Indexänderung passieren kann, trotzdem denselben Hash ergibt.

Die Normalisierungsregeln selbst liegen in einer einzigen Konfigurationsdatei, die im Upgrade-Projekt eingecheckt ist. Zwanzig Regeln decken ungefähr 90% der UBEs in einer typischen Installation ab; zehn weitere werden normalerweise für UBEs benötigt, die ungewöhnlich formatierte Outputs erzeugen, etwa Custom Letters, EDI-Dateien oder Payroll Calculation Reports. Die Kosten für das Schreiben der Regeln zahlen sich beim ersten Lauf gegen ein Zielrelease aus, wenn der Diff lesbar statt überwältigend ist.

Den Vergleich ausführen und den Diff triagieren

Wenn die Baseline erfasst und die Normalisierungsregeln definiert sind, ist der eigentliche Vergleich der einfachste Teil der Pipeline. Ein Skript — normalerweise 200 bis 400 Zeilen Python oder Shell — iteriert die in-scope UBE-Liste, holt das Baseline-Artefakt für jede UBE, holt das Zielartefakt, wendet Normalisierung an und führt den Diff aus. Das Ergebnis ist ein strukturierter Report: eine Zeile pro UBE, Spalten für Status (match / known-difference / regression), Diff-Größe und ein Link zur Side-by-Side-Ansicht für menschliche Prüfung.

Das Known-Changes-Register ist die Datei, die den Report aussagekräftig hält. Für jede UBE, bei der das Upgrade den Output legitim ändert, gibt es einen Eintrag im Register mit dem Grund, etwa "Application Update 23 added column COST-CENTER to R09801 output", und der Diff für diese UBE wird als known-difference statt als regression markiert. Ohne dieses Register produziert jedes Application Update dutzende falsche Regressionen, und das Team beginnt, den Report zu ignorieren — ab diesem Punkt verstecken sich die echten Regressionen im Rauschen.

Die Triage der Regressionsliste erfolgt nach Kritikalität. Finanz-UBEs — Period Close, Trial Balance, A/R Aging, A/P Proof, Tax Reports — werden zuerst untersucht und benötigen eine namentliche Freigabe von Finance, bevor das Upgrade promotet wird. Operative UBEs — Pick Lists, Shipment Confirmations, Work Order Travelers — kommen an zweiter Stelle. Interne Management-Reports kommen zuletzt; einige davon können legitimerweise auf die Post-Upgrade-Woche verschoben werden, wenn das Business schriftlich zustimmt.

Den Kreis schließen: Wann Validierung wirklich abgeschlossen ist

Ein Upgrade-Validierungsaufwand endet, wenn ein Dokument unterschrieben ist, nicht wenn die letzte UBE verglichen wurde. Das Dokument ist eine Regression Summary: Gesamtzahl der UBEs in scope, Anzahl exakt übereinstimmender UBEs, Anzahl der UBEs, die nach Known-Changes-Anpassungen übereinstimmen, Anzahl untersuchter Regressionen und deren Lösungen sowie eine explizite Liste der UBEs, die für Post-Upgrade-Follow-up zurückgestellt wurden, mit dem Business Owner, der jede Zurückstellung akzeptiert hat.

Die Unterzeichner sind nicht das Entwicklungsteam. Es sind die Business Owner der betroffenen Prozesse — Finance für Finanzreports, Operations für operative Reports, HR für Payroll, falls sie in scope ist. Das Entwicklungsteam bereitet das Dokument vor und erzeugt die Evidenz; das Business unterschreibt, dass es das Ergebnis akzeptiert. Ohne diese Unterschrift ist die Validierung unvollständig, egal wie viele UBEs verglichen wurden.

Die von der Pipeline erzeugten Artefakte — Baseline-Outputs, Ziel-Outputs, Normalisierungsregeln, Known-Changes-Register, Diff-Reports — werden für die Lebensdauer des Upgrade-Projekts plus den typischen Audit-Horizont archiviert, normalerweise sieben Jahre für Finanzoutputs. Wenn ein Auditor zwei Jahre später fragt: "Woher wussten Sie, dass R09801Post General Ledger — die standardmäßige JDE-UBE, die Batch-Journalbuchungen von F0911 nach F0902 bucht. Auf den meisten Installationen die am stärksten validierte UBE, weil das Financial Reporting davon abhängt. vor und nach dem Upgrade dieselben Periodensummen erzeugt hat?", ist die Antwort ein Ordner, keine Erinnerung.

Die letzte operative Disziplin besteht darin, die Pipeline so weit zu automatisieren, dass sie für jedes kumulative Application UpdateDas Continuous-Delivery-Format von Oracle für JDE 9.2, das Standardobjektänderungen zwischen großen Tools-Release-Zyklen bündelt. Jedes davon ist ein eigenes Mini-Upgrade, das von derselben Validierungspipeline profitiert. erneut ausgeführt werden kann, nicht nur für das große Upgrade alle drei Jahre. Eine Pipeline, die beim ersten Mal drei Monate Bauzeit kostet und danach eine Woche Laufzeit, ist der Unterschied zwischen einer upgrade-freundlichen Installation und einer, bei der jede Tools-Release-Entscheidung zu einer Vorstandsdiskussion über Risiko wird.

Mehr zum Umfeld finden Sie in den verwandten Artikeln zu UBE-Checkpoint- und Restart-Patterns, zum Scoping von Tools-Release-Upgrades und zu F986110-Archivierungsstrategien, die die operative Ebene abdecken, auf der diese Validierungspipeline sitzt. Das technische Projektportfolio auf dieser Website dokumentiert zwei produktive Validierungssuiten, aus denen die hier beschriebenen Muster entstanden sind.