Von allen Artefakten, die darüber entscheiden, ob ein JD Edwards Upgrade pünktlich ausgeliefert wird, ist das Data DictionaryDie JDE-Metadatenschicht, die jedes Data Item definiert — Alias, Länge, Dezimalstellen, Glossar, Edit Rules. Es ist der Vertrag, auf den sich jede Form, BSFN, UBE und Integration stützt. dasjenige, das in den meisten Upgrade-Plänen unterschätzt wird. Im DD treffen Oracles Änderungen von Release zu Release auf Ihren Custom Code, und eine einzige Änderung der Dezimalstellen eines Standard-Data-Items, die beim Cut-over unbemerkt bleibt, hat schon mehr als einem Finance-Team nach dem Go-live einen Monat Abstimmungsarbeit gekostet.

So arbeite ich mit dem Data Dictionary in einem echten Upgrade: wie der Diff zwischen Source- und Target-Release aufgebaut wird, wie die Custom Items mit 55-69-Präfix inventarisiert werden, die Sie dauerhaft begleiten werden, wie stille Verschiebungen bei Länge und Dezimalstellen erkannt werden, die das RetrofittingDer Prozess, Custom-Änderungen auf einer neuen JDE-Release erneut anzuwenden, nachdem Oracle eigene Änderungen an denselben Standardobjekten geliefert hat. brechen, und wie das Ergebnis validiert wird, bevor sich der erste Benutzer anmeldet.

Warum das Data Dictionary das Upgrade-Artefakt mit der größten Hebelwirkung ist

Jede Form, jede UBE, jede BSFNBusiness Function: kompilierter C-Code, der innerhalb des JDE Call Object Kernels läuft. BSFN-Strukturen werden aus Data-Dictionary-Item-Definitionen aufgebaut, daher erzwingt jede DD-Änderung einen BSFN-Rebuild. in JDE liest aus dem DD, um zu wissen, wie die Spalten der betroffenen Tabelle zu interpretieren sind. Die Daten stehen in der Tabelle; die Bedeutung der Daten steht im DD. Wenn das DD sagt, dass ein Item 15.2 ist (15 Ziffern, 2 Dezimalstellen), und die Tabelle eine Ganzzahl mit impliziten Dezimalstellen enthält, setzt die Anwendung die Dezimalstelle bei der Anzeige wieder an die richtige Position. Ändern Sie die Dezimalstellenanzahl im DD, ohne alles neu zu bauen, was darauf verweist, und dieselbe Datenbankzeile wird plötzlich als 100x oder 1/100x ihres tatsächlichen Werts angezeigt.

Zwischen Releases ändert Oracle tatsächlich DD Items. Längen werden erweitert, wenn sich das Standardprodukt weiterentwickelt (Währungsbeträge, die in älteren Releases 15.2 waren, wurden in einigen Standardtabellen auf 18.2 erweitert). Die Dezimalpräzision ändert sich bei ratennahen Items. Einige Items werden deprecated und durch neue Aliase ersetzt. Nichts davon ist katastrophal, wenn Sie es vor dem Cut-over finden; alles davon ist katastrophal, wenn Sie es danach finden.

Der Hebel liegt darin, dass DD-Analyse im Verhältnis zum Rest des Upgrades günstig ist. Einige klar abgegrenzte Abfragen gegen F9200, F9202, F9203, F9210 auf Source- und Target-Release liefern in Stunden ein vollständiges Bild, nicht in Wochen. Überspringen Sie diese Arbeit, kommen dieselben Stunden später als Produktions-Supporttickets zurück — nur dass die Kosten dann auch das bereits verlorene Vertrauen der Benutzer enthalten.

Der fünfstufige DD-Workflow, den ich in jedem Upgrade ausführe

Der Workflow ist derselbe, egal ob Sie von B9 auf 9.2 oder von 9.2 auf ein zukünftiges Release gehen. Die Volumina ändern sich; die Stufen nicht.

Stufe eins — Baseline-Diff. Exportieren Sie F9200 und F9210 aus Source- und Target-Release in zwei nebeneinanderliegende Schemata. Eine typische JDE-Instanz hat 15.000-20.000 DD Items, davon ungefähr 12.000-15.000 von Oracle geliefert und der Rest custom. Die Diff-Abfrage ist einfach — left join auf FRDTAI/FROMDTAI, Markierung jeder Zeile, in der Länge, Dezimalstellen oder Data Type abweichen — aber die Trefferzahl überrascht. Selbst zwischen zwei aufeinanderfolgenden ESUs auf derselben Release habe ich 50-150 von Oracle gelieferte DD-Änderungen gesehen; zwischen vollständigen Releases liegt die Zahl im niedrigen Tausenderbereich.

Stufe zwei — Custom-Inventar. Jedes Custom DD Item sollte im Alias-Präfixbereich 55-69 liegen. Führen Sie SELECT FRDTAI, FRSY FROM F9200 WHERE FRDTAI BETWEEN '55' AND '69' gegen die Source aus. Ein gesunder Custom-Bestand hat 200-500 Items. Alles über 1.000 ist entweder eine langlebige Umgebung, die bereinigt werden muss, oder ein Hinweis darauf, dass jemand DD Items im falschen Präfixbereich angelegt hat. In jedem Fall wollen Sie das vor dem Upgrade wissen, nicht währenddessen.

Stufe drei — Konfliktscan. Vergleichen Sie das Custom-Inventar mit dem Oracle-Diff. Meistens leben Custom- und Oracle-Items in getrennten Präfixbereichen und es gibt keine Kollision. Die kritischen Treffer sind: Custom Items, die ein Standard-Item kopieren oder erweitern, das Oracle nun geändert hat, und Custom Code (BSFNs, NERs, UBEs), der einen Standard-Alias hard-coded verwendet, dessen Definition sich verschoben hat. Der zweite Fall ist gefährlich, weil das DD Item selbst keine Korrektur braucht — der Code, der es verwendet, braucht sie.

Stufe vier — Retrofit-Plan. Für jeden Konflikt gibt es drei Optionen: den Standard-Alias so beibehalten, wie Oracle ihn jetzt liefert, und Custom Code anpassen; das alte Custom-Verhalten beibehalten und begründen; oder Custom in Standard zusammenführen, wenn Oracle inzwischen eingebaut hat, wofür das Custom Item ursprünglich ergänzt wurde. Jede Option geht mit Aufwandsschätzung und Sign-off eines Functional Owners in den Retrofit-Projektplan. Stufe vier ist Papierarbeit — und genau diese Papierarbeit rettet Sie in den Diskussionen nach dem Go-live.

Stufe fünf — Post-Upgrade-Validierung. Nach dem Upgrade-Lauf, bevor Benutzer sich anmelden: Führen Sie R9202 (Data Dictionary integrity report) auf der Target-Release aus, leeren Sie Caches top-down vom HTML Server bis zu den Enterprise Server Kernels, bauen Sie Specs für alle Custom DD Items neu, die es benötigen. Prüfen Sie stichprobenartig 10-20 hochwertige Items (Beträge auf F4211, F0411, F0911) mit einer Abfrage, die die Tabelle mit F9210 verbindet und bestätigt, dass die Dezimalstellenposition mit dem übereinstimmt, was die Anwendung nun anzeigt.

Die drei von Oracle gelieferten DD-Änderungen, die Upgrades brechen

Von allem, was sich im DD zwischen Releases verschiebt, erklären drei Muster fast jeden Post-Upgrade-Vorfall, den ich gesehen habe.

Die Länge ist gewachsen. Oracle erweitert ein bestehendes Item — typischerweise einen Betrag oder eine Menge — um größere Werte zu unterstützen, die globale Kunden benötigen. Die Tabellenspalte wird entsprechend geändert, Ihre Custom BSFNs, die einen Puffer auf Basis der alten Länge allokieren, kompilieren weiterhin, schneiden aber zur Laufzeit ab. Die Korrektur ist mechanisch, aber vollständig durchzuführen: jede Custom BSFN neu bauen, die auf den betroffenen Alias verweist. Die XREF-Abfrage (SELECT FOOBNM, FOMODNAME FROM F980011 WHERE FOPONM = 'AMOUNT_ALIAS') liefert die Liste. Der Aufwand skaliert mit der Größe des Custom-Bestands — eine kleine Custom-Umgebung benötigt 1-2 Tage; ein stark angepasstes System kann 1-2 Wochen Rebuilds erfordern.

Dezimalstellen haben sich geändert. Das ist der stille Killer. Oracle ändert ein ratennahes Item von 2 Dezimalstellen auf 4 (oder umgekehrt), die Datenbankspalte ändert sich nicht, die Daten ändern sich nicht, aber die Interpretation durch die Anwendung ändert sich. Jeder Bericht, jeder Bildschirm, jeder Export zeigt den Wert nun um den Faktor 100 verschoben. Das Harte daran: Das System wirft keinen Fehler. Die Zahl wird angezeigt, korrekt formatiert, wirkt plausibel. Finance merkt es erst, wenn Summen nicht mehr abstimmen. Nehmen Sie Items mit Dezimaländerungen immer in die Cut-over-UAT mit explizitem Vorher/Nachher-Zahlenvergleich auf — visuelle Prüfung reicht nicht.

Item entfernt. Oracle deprecated einen Alias und liefert einen Ersatz, in der Erwartung, dass Consumer migrieren. Der deprecated Alias kann aus Kulanz noch ein oder zwei Releases in F9200/F9210 bleiben, aber neue Objekte verwenden den neuen Alias. Custom Code, der den alten Alias hard-coded hat, funktioniert weiter, bis das Deprecation-Fenster schließt, und bricht dann. Planen Sie die Migration während des Upgrades selbst, nicht erst in der Release, die die deprecated Zeile entfernt.

DD Items mit den Objekten verknüpfen, die von ihnen abhängen

Das DD allein sagt nicht, was brechen wird — F980011, die Cross-Reference-Tabelle, tut das. Nach jedem Checkout, der DD-Nutzung verändert, aktualisiert JDE F980011 mit der Beziehung zwischen Objekten und den DD Items, auf die sie verweisen. Der XREF-Index wird durch R980011 neu aufgebaut (oder durch sein modernes Äquivalent auf aktuellen Tools Releases); bei einem veralteten Index ist die Cross-Reference unvollständig und die Impact-Analyse zählt zu wenig.

Die Abfrage, die die Analyse steuert, ist einfach:

SELECT FOOBNM, FOMODNAME, FOOBJTYPE
FROM   F980011
WHERE  FOPONM = 'TARGET_ALIAS'
ORDER  BY FOOBJTYPE, FOOBNM;

Die Ausgabe ist die vollständige Liste der UBEs, APPLs, NERs und BSFNs, die auf den Alias verweisen, gruppiert nach Object Type. Für einen Alias, der in einem Dutzend Objekten verwendet wird, ist das eine saubere zweistündige Impact Review. Für einen Alias wie AN8 (Address Number) — in Tausenden von Objekten im Standardprodukt referenziert — ist die Liste in dieser Form unlesbar, und der bessere Ansatz ist, zu bestätigen, dass Oracle die Item-Definition nicht geändert hat, und weiterzugehen. AN8 ändert sich nicht; am wahrscheinlichsten ändern sich Items, die spezifisch für einen Funktionsbereich sind.

Für hochwertige DD Items (Währungsbeträge, Mengen, Unit Cost, Wechselkurse) auf Standardtabellen in Finance und Distribution sollten Sie die Cross-Reference manuell durchführen, selbst wenn der Diff sagt, dass Oracle sie nicht geändert hat. Die 20 wichtigsten DD Items verdienen jeweils 20 Minuten Aufmerksamkeit — deutlich günstiger, als in Woche drei nach dem Go-live ein verpasstes Retrofit zu entdecken.

Tools und Skripte, die sich in jedem Upgrade bezahlt machen

Einige gezielte Tools verwandeln DD-Analyse von einer mehrtägigen Plackerei in eine Halbtagsübung. Die Form dieser Tools ist wichtiger als die konkrete Implementierung — entscheidend ist, dass Sie sie haben und dass sie zwischen Upgrades überleben, um für das nächste bereit zu sein.

Ein Baseline-Differ, der zwei F9200/F9210-Exporte verarbeitet und einen kategorisierten Diff erzeugt (Änderungen an Länge, Dezimalstellen, Data Type, Edit Rule, Glossar), ist das am häufigsten wiederverwendete Bauteil. SQL reicht aus; ein 200-Zeilen-Skript in Python oder pandas liefert eine spreadsheet-artige Ausgabe, die das Functional Team prüfen kann.

Ein Custom-Präfix-Inventarskript (die 55-69-Abfrage plus Cross-Reference zu F980011) liefert den Custom-DD-Footprint pro Object Type. Alles mit mehr als 100 abhängigen Objekten wird ausdrücklich hervorgehoben; alles Orphaned (DD Item mit null F980011-Referenzen) wird für Bereinigung vor dem Upgrade markiert, nicht danach.

Ein Decimal-Change-Validator läuft nach dem Upgrade gegen hochwertige Tabellen: Für jede Zeile in zum Beispiel F0911 berechnet er den angezeigten Wert sowohl mit der alten als auch mit der neuen Dezimaldefinition und markiert jede Zeile, in der sich beide unterscheiden. Auf einer Stichprobe von 10.000-50.000 Zeilen dauert das Sekunden und liefert eine Ja/Nein-Antwort darauf, ob das Upgrade die Interpretation von Geld verschoben hat.

Diese drei Tools zusammen verwandeln DD-Upgrade-Arbeit in eine handhabbare Engineering-Aufgabe statt in einen vagen Punkt "wir prüfen das DD" im Projektplan.

Die Fehler, die ein Upgrade still um Wochen verlängern

Der erste ist, DD-Analyse als alleinige Aufgabe des CNC-Teams zu behandeln. Das CNC-Team besitzt die technische Promotion von DD-Änderungen durch die Umgebungen; das Functional Team besitzt die Entscheidung, ob eine 2dp-zu-4dp-Änderung an einem Wechselkurs für das Business akzeptabel ist. Beide Teams müssen im DD Review sein, sonst liefert das technische Sign-off Änderungen aus, die das Business nie akzeptiert hat.

Der zweite ist, das Custom-Präfix-Inventar zu überspringen, weil "wir nicht viele Customisations haben". Langlebige JDE-Umgebungen sammeln über Jahrzehnte Custom DD Items an — Items, die von Beratern angelegt wurden, die längst weg sind, Items für Projekte, die abgebrochen wurden, Items, die doppelt angelegt wurden, weil zwei Teams nichts voneinander wussten. Das erste Inventar einer zehn Jahre alten Umgebung überrascht immer jemanden.

Der dritte ist, den Diff zwischen Source- und Target-Release durchzuführen, aber nicht zwischen der aktuellen Tools Release und der Target Tools Release auf derselben Product Release. Tools Releases liefern eigene DD-Änderungen — meist klein im Volumen, aber hoch im Impact, weil sie Standard-Runtime-Items betreffen, auf die jedes Objekt verweist. Der Tools-Release-Diff ist eine eigene Abfrage und ein eigenes Review.

Der vierte ist, zu vergessen, dass F9202 und F9203 (Alpha Description und Übersetzungen) ebenfalls einen Upgrade-Durchlauf benötigen. Neue von Oracle gelieferte DD Items kommen mit englischen Beschreibungen und manchmal mit einem Teil der Sprachübersetzungen. Wenn Ihre Umgebung mehrsprachig ist, erspart die Post-Upgrade-Gap-Analysis auf F9203 den Benutzern leere Labels am ersten Tag.

Der fünfte ist, das DD während des Cut-over nicht einzufrieren. Das Fenster zwischen Start des Upgrades und Abschluss der Post-Go-live-Validierung ist nicht der Zeitpunkt, an dem jemand ein neues DD Item "für einen schnellen Fix" hinzufügen sollte. Sperren Sie P92001 über Security und entsperren Sie es erst, wenn das Upgrade abgenommen ist.

Wenn diese Art von Upgrade-seitiger Analyse das ist, was Sie für Ihre eigene JDE-Landschaft benötigen, behandeln die verwandten Artikel auf dieser Website OMW-Projektmuster, Custom-Code-Analyzer-Skripte für Upgrade-Scoping und das Retrofit-Risk-Dashboard, das diese Arbeit für Steering Committees zusammenfasst. Das Projektportfolio zeigt, wo diese Techniken in echten B9-zu-9.2- und 9.2-zu-zukünftige-Releases-Upgrades angewendet wurden.