Die meisten JDE-Teams betrachten die Object Management WorkbenchDie zentrale Change-Management- und Versionskontrollumgebung in JD Edwards zur Verwaltung aller Projektlebenszyklen und Entwicklungsobjekte. lediglich als eine Quellcodeverwaltungs-UI mit Check-in- und Check-out-Schaltflächen. In Wirklichkeit bedeutet die Verwaltung des JD Edwards OMW Projekt-Lebenszyklus von der Entwicklung bis zur Promotion die Orchestrierung einer relationalen Zustandsmaschine über Token-Sperren, Central Objects Spezifikationsänderungen und PathcodeEine logische Definition in JD Edwards, die eine Reihe von Spezifikationen und Verzeichnissen für eine Umgebung (z. B. DV, PY, PD) festlegt.-Synchronisationen über die Steuertabellen F98220 und F98222 hinweg. Ein nachlässiger Umgang damit ist der Grund, warum rund 15 % bis 20 % aller Fehlschläge bei Custom-Promotions direkt auf verwaiste Token, nicht committete C-BSFNC Business Function: In C programmierte Logikbausteine zur Ausführung wiederverwendbarer Geschäftsfunktionen in JD Edwards.-Header-Dateien oder unbemerkten lokalen Spec-DriftAbweichungen zwischen lokal modifizierten Objektspezifikationen und dem zentralen Repository, meist durch unvollständige Synchronisation. zurückzuführen sind.
Jedes JD-Edwards-System mit einigen Jahren Laufzeit trägt eine unbeantwortete Frage in sich: Wie viele der im Laufe der Zeit entwickelten Custom-Objekte sind noch im Wesentlichen identisch mit dem Oracle-Standard, von dem sie abstammen – und wie viele haben sich so weit entwickelt, dass sie etwas völlig anderes geworden sind? Diese Frage wird dringend, wenn ein Upgrade, eine Migration oder ein Customizing-Audit ansteht. In den meisten Fällen gibt es keine Antwort, weil niemand sie jemals systematisch gesucht hat. In diesem Artikel beschreibe ich, wie ich dieses Problem in meiner Arbeit angehe, und das proprietäre Tool, das ich dafür entwickelt habe.
Seite 16 von 16