Der schwierige Teil eines JD Edwards EnterpriseOne Table-Conversion-Projekts für Legacy-Datenmigration ist fast nie das Mapping. Field-to-Field-Mapping ist mechanische Arbeit, die ein Functional Analyst innerhalb von zwei Wochen in einer Tabelle spezifizieren kann. Was diese Projekte scheitern lässt, ist die Ladereihenfolge über F0101Address Book Master table — die Masterdatei, auf die jede Transaktionstabelle in JDE über die Spalte AN8 verweist., F4101, F0911 und die verwandten Transaktionstabellen hinweg, sowie das Fehlen eines Reconciliation-Pakets, das das Business unterschreiben kann.

Ich habe in den letzten fünf Jahren sechs Legacy-zu-JDE-Migrationen geleitet, mit Zeilenzahlen von 800.000 bis ungefähr 40 Millionen über alle geladenen Tabellen hinweg. Das Muster, das Cutovers, die pünktlich abgeschlossen wurden, von denen unterscheidet, die neun Monate lang Supporttickets erzeugten, ist konsistent — und es hat nichts damit zu tun, wie clever die Transformationslogik war.

Was eine Table Conversion in JDE wirklich bedeutet

In der JDE-Terminologie ist die Table Conversion ein spezifischer Objekttyp (TC), der über OMWObject Management Workbench — das JDE-Tool zum Auschecken, Ändern und Promoten jedes Custom-Objekts, einschließlich Table Conversions, BSFNs, UBEs und Anwendungen. erzeugt und über Logik im Stil von R98403 ausgeführt wird. Der breitere Engineering-Aufwand, der Daten aus einem abzulösenden System in JDE-Produktionstabellen verschiebt, kombiniert fast immer drei Ausführungstools: das generierte TC-Objekt, Custom-UBEs aus RDA und Orchestrator-Flows für kleinere Loads.

Ein reines TC-Objekt ist das günstigste Tool im Build und das am schwierigsten zu erweiternde. Es funktioniert gut, wenn eine Quellzeile sauber auf eine Zielzeile mit leichter Transformation abgebildet wird — Zahlungsbedingungen, Artikelkategorien, Address-Book-Erweiterungen. Sobald der Load Multi-Table-Writes benötigt, etwa ein Sales Order, der F4201 und F4211 berührt, mit möglichen F4209-Preisen und F4106-Basispreisen, NextNumbers-Akquise oder Validierung pro Zeile gegen UDC-Tabellen, ist das TC-Objekt nicht mehr die richtige Wahl. Eine Custom-UBE aus RDA mit sauberen Event Rules und BSFN-Aufrufen ist dann die einzige ehrliche Antwort.

Das Missverständnis, das ich am häufigsten bei Kunden und Junior Consultants sehe, ist, "Table Conversion" als Synonym für die gesamte Migration zu behandeln. Es ist ein Werkzeug im Werkzeugkasten, nicht der Werkzeugkasten selbst. Wird das am Anfang des Projekts falsch verstanden, liegt die gesamte Schätzung um den Faktor zwei daneben.

Das fünfstufige Grundgerüst, das sich nicht ändert

Jede erfolgreiche Migration nach JDE E1 folgt demselben fünfstufigen Grundgerüst: extract, stage, convert, load, verify. Die Tools ändern sich von Projekt zu Projekt. Die Phasen nicht.

Extract zieht Daten aus dem abzulösenden System in ein neutrales Format — SQL-Exporte, CSV oder Flat Files, die auf einen Staging-Share geschrieben werden. Die Regel, die ich nie breche: keinen JDE-Prozess direkt mit einer produktiven Legacy-Datenbank verbinden. Erstelle einen eingefrorenen, auditierbaren Snapshot, den du beliebig oft erneut abspielen kannst. Replays sind nicht optional; sie werden passieren, meistens um 2 Uhr morgens an einem Samstag.

Stage lädt die extrahierten Zeilen in Custom-F55*-Tabellen auf der JDE-Seite, angelehnt an die Standardkonvention der F5511Z1-Interface-Tabelle: jede Quellspalte plus EDUS, EDBT, EDTN, EDLN, EDSP-Steuerspalten und ein Processing-Status-Flag. Staging ist der Ort, an dem Validierungsabfragen wiederholt laufen, ohne Produktion zu berühren. Convert transformiert jede gestagte Zeile gegen die JDE-Regeln: UDCUser Defined Codes — die JDE-Lookup-Tabellen in F0005 und F0004, die Codes validieren, die von praktisch jeder Transaktionstabelle verwendet werden.-Validierung gegen F0005, Datumsnormalisierung zu Julian, NextNumbers aus F0002, wenn die Zielspalte eine Dokumentnummer ist. Load schreibt nur validierte Zeilen in JDE-Produktion. Verify schließt den Kreis mit Zählungen, Key-Integrity-Prüfungen und finanziellen Summen.

Die einzelne Phase, die die meisten Projekte unterfinanzieren, ist verify. Drei bis fünf Tage Reconciliation-Arbeit, von Anfang an eingeplant, verhindern drei bis sechs Monate Post-Go-Live-Supportlärm.

Die Ladereihenfolge, die entscheidet, ob das Projekt sauber endet

Die Ladereihenfolge ist die technische Entscheidung mit dem größten Blast Radius im ganzen Projekt, und sie wird fast immer zu spät getroffen. Die Regel, klar formuliert: Masters vor Transaktionen, immer, ohne Ausnahmen für "Bequemlichkeit" oder "wir beheben die Orphans später". F0101 (Address Book Master) und F0111 (Who's Who) vor jeder Transaktionstabelle, die AN8 referenziert. F4101 (Item Master) und F4102 (Item Branch) vor Sales Orders, Purchase Orders oder Inventory Transactions. F0901 (Account Master) vor jeder F0911-Journalzeile. F4801 (Work Order Master) vor F4801T oder F31*-Manufacturing-Details.

Was "Orphans" in der Praxis wirklich bedeutet: Eine Customer-Ledger-Zeile in F03B11 mit einer Kundennummer, die in F0101 nicht existiert, erzeugt zur Ladezeit keinen Fehler, weil JDE Physical Files keine erzwungenen Foreign Keys auf Datenbankebene haben. Die Zeile bleibt dort. Drei Wochen nach Go-Live zeigt der Aged-Receivables-Report einen Saldo, der zu nichts im Customer Master passt, und jemand muss eine CTE schreiben, um die Orphans zu finden, sie gegen Legacy-Backups abzugleichen und zu entscheiden, ob erstellt oder gelöscht werden soll.

Die Kosten, die Ladereihenfolge richtig zu machen, bestehen aus einer zusätzlichen Woche Dependency-Graph-Arbeit im Design. Die Kosten, sie falsch zu machen, sind offen.

Idempotenz, Restartability und das Cutover-Fenster

Die einzelne Eigenschaft, die jede Load-UBE im Projekt haben muss, ist Idempotenz: Dieselbe UBE zweimal mit demselben Input auszuführen, erzeugt denselben Endzustand. Das einfachste Muster ist "delete-where-source-batch-id then insert", begrenzt auf eine Batchnummer, die der Load selbst besitzt und in eine Kontrollspalte schreibt. Ohne Idempotenz erzwingt jeder Fehler während des Cutovers ein Restore aus dem Backup, was bei einem 40-Millionen-Zeilen-Dataset bedeutet, dass sich das Cutover-Fenster verdoppelt.

Restartability ist die verwandte Eigenschaft: Eine UBE, die bei Zeile 4 Millionen abbricht, muss bei Zeile 4 Millionen plus eins fortsetzen können, nicht wieder bei Zeile eins. Checkpoint-Logik in der Staging-Tabelle — eine Spalte "last_committed_row", die alle 10.000 Zeilen aktualisiert wird — sind zwanzig Zeilen EREvent Rules — die visuelle Skriptsprache innerhalb von JDE-UBEs, Anwendungen und BSFNs, mit der Business-Logik ohne C-Code kodiert wird.-Code und retten ganze Cutover-Wochenenden. Ich habe Cutovers durchgeführt, bei denen der Load dreimal aus unabhängigen Infrastrukturgründen fehlschlug, etwa Netzwerkunterbrechung, abgelaufenes DB-Token oder volles Transaction Log, und trotzdem planmäßig landete, weil die Restart-Logik bereits vorhanden war.

Das Cutover-Fenster selbst ist der Zeitraum, in dem Legacy-Schreibvorgänge blockiert sind und der finale Delta-Load läuft. Je kleiner das Fenster, desto mehr Delta-Loads liefen vorher. Zwei Wochenenden Delta-Rehearsal vor dem echten Cutover sind das Minimum; vier sind normal. Jede Probe deckt einen anderen Fehlermodus auf — die dritte Probe findet normalerweise den UDC-Wert, der drei Monate nach Einfrieren der Spezifikation im Legacy-System ergänzt wurde.

Reconciliation als Deliverable, das das Projekt abschließt

Eine Migration endet, wenn das Business das Reconciliation-Paket unterschreibt, nicht wenn die letzte UBE RC=0 zurückgibt. Das Paket, das ich in jedem Projekt liefere, hat drei Komponenten: Zeilenzählungen pro Source-Target-Paar, finanzielle Summen, also Summe von AG in F0911 gegen die Legacy-Trial-Balance bis auf den Cent, und eine Exception-Liste der Zeilen, die nicht geladen wurden, jeweils mit typisiertem Grund.

Zeilenzählungen sind der einfache Teil — eine zweispaltige SQL-Abfrage gegen Staging-Tabelle und Produktionstabelle pro Paar. Finanzielle Reconciliation ist der Teil, der am häufigsten scheitert, weil die beiden Systeme Periodensalden unterschiedlich berechnen und die natürliche Annahme, dass "wenn die Journalzeilen stimmen, auch die Salden stimmen", falsch ist. F0902-Periodensalden müssen aus den geladenen F0911-Zeilen mit UBEUniversal Batch Engine — der Batch-Report-Runner von JDE, hier verwendet für den Standardjob zur Neuberechnung der F0902-Periodensalden nach dem Laden der Journalzeilen. R09866 oder einem Äquivalent neu berechnet werden, sonst ist die Trial Balance um die Summe jeder Journalzeile verschoben, die eine Periodengrenze überschritten hat.

Die Exception-Liste ist der Ort, an dem Engineering-Glaubwürdigkeit lebt. Vierzigtausend Sales Orders geladen, zweihundertachtzig mit Reason Codes abgelehnt — das ist ein vertretbares Ergebnis. Vierzigtausend geladen, "einige abgelehnt" — das ist ein Projekt, das nicht abgeschlossen ist. Sobald das Business dieses Paket gegen namentlich benannte Personen auf der Finanzseite unterschreibt, ist die Migration wirklich abgeschlossen. Alles, was später auftaucht, ist Post-Implementation-Supportarbeit, keine Migrationsschuld. Die Disziplin des Reconciliation-Pakets verwandelt das eine in das andere.

Wenn die Detailtiefe oben die Art von Perspektive ist, die Sie für JDE-Arbeit suchen, gehen die verwandten Artikel zum Retrofitting von Kopien des Standards, zu UBE-Checkpoint-Mustern und zur F0911-Reconciliation nach Go-Live tiefer auf die hier berührten Themen ein. Das technische Projektportfolio auf dieser Website dokumentiert außerdem zwei der Migrationen, aus denen diese Schlussfolgerungen entstanden sind, mit anonymisierten Zahlen.