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.

Was ist JD Edwards und warum existiert dieses Problem?

JD Edwards (allgemein bekannt als JDE) ist ein von Oracle entwickeltes Enterprise-ERP-System, das in Fertigungs-, Distributions- sowie in der Öl- und Gas- und Baubranche weit verbreitet ist. Wie alle High-End-ERP-Systeme bietet JDE einen Satz von „Standard"-Objekten – Anwendungen, Reports, Business Functions und Business Views –, die grundlegende Geschäftsprozesse abdecken.

Die operative Realität ist jedoch, dass kein Unternehmen reines JDE einsetzt. Jede Implementierung bringt Dutzende, wenn nicht Hunderte von Anpassungen mit sich: Standard-Objekte werden kopiert, mit einem Custom-Präfix umbenannt (typischerweise im Bereich 55–69 gemäß der JDE-Nomenklatur) und an die spezifischen Prozesse des Kunden angepasst.

Dies schafft ein sehr konkretes Problem: Wie lässt sich Jahre später feststellen, welcher Standard einem Custom-Objekt zugrunde liegt? Die Nachvollziehbarkeit geht verloren. Entwickler wechseln. Die Dokumentation veraltet oder existiert nicht.

Das technische Problem: den Ursprung eines Custom-Objekts finden

In meiner JDE-Beratungstätigkeit muss ich häufig ganze Repositories von Custom-Objekten – manchmal Hunderte von Dateien – analysieren, um Fragen wie diese zu beantworten:

• Ist dieses P55001 eine Kopie des P4210? Und wie weit hat es sich davon entfernt?
• Ist diese Business Function noch im Wesentlichen identisch mit dem Standard, oder wurde sie neu geschrieben?
• Welche Objekte wurden grundlegend verändert und welche entsprechen noch dem Original?

Das Problem ist aus mehreren Gründen nicht trivial.

Der Inhalt ist verrauscht. JDE-Exporte enthalten eine große Menge an Boilerplate: Standard-Kommentare, Copyright-Header, sich wiederholende Strukturdeklarationen. Vergleicht man den Rohtext, überlagert das Rauschen das Signal.

Namen allein reichen nicht. Ein P554210 stammt wahrscheinlich vom P4210 ab, aber ein P55001 könnte von P4101, P4201 oder einem völlig anderen Objekt abgeleitet sein. Die Namenskonvention wird nicht immer eingehalten, und in manchen Fällen folgt das Custom-Präfix keiner Logik in Bezug auf das Original.

Die Größenordnung macht manuelle Vergleiche unpraktikabel. Bei 200 Standards und 400 Custom-Objekten erzeugt ein manueller Vergleich 80.000 mögliche Kombinationen. Das ist keine menschliche Operation.

Der Ansatz: eine hybride Analyse-Engine

Um dieses Problem zu lösen, habe ich COS-Analysis entwickelt, ein proprietäres Desktop-Tool, das den Vergleich auf drei verschiedenen Ebenen durchführt, kombiniert zu einem finalen gewichteten Score.

Ebene 1 — Bereinigung und Normalisierung des Inhalts

Vor jedem Vergleich wird jede Datei einer Preprocessing-Phase unterzogen:

• Entfernung fester Boilerplate-Elemente (Copyright-Header, JDE-spezifische, sich wiederholende Strukturdeklarationen)
• Entfernung von Layout-Rauschen (Positionen, Dimensionen, UI-Identifikatoren)
• Ersetzung des spezifischen Objektnamens durch einen generischen Platzhalter, um Namensunterschiede beim Textvergleich zu neutralisieren

Dieser Schritt ist entscheidend: Ohne Normalisierung würden zwei im Verhalten identische Objekte mit unterschiedlichen Copyright-Headern als unähnlich erscheinen, und zwei verschiedene Objekte mit demselben Namen könnten künstlich ähnlich wirken.

Ebene 2 — Textinhalt-Vergleich mittels WinnowingDokumenten-Fingerprinting-Algorithmus: repräsentiert jeden Text als eine Menge von Hashes, die aus gleitenden Fenstern von Zeichensequenzen extrahiert werden. Ursprünglich für die akademische Plagiatserkennung entwickelt, ist er robust gegenüber partiellen Textänderungen.

Das Herzstück des Textvergleichs basiert auf dem WinnowingDokumenten-Fingerprinting-Algorithmus: repräsentiert jeden Text als eine Menge von Hashes, die aus gleitenden Fenstern von Zeichensequenzen extrahiert werden. Ursprünglich für die akademische Plagiatserkennung entwickelt, ist er robust gegenüber partiellen Textänderungen.-Algorithmus, einer Fingerprinting-Technik, die ursprünglich für die Erkennung akademischen Plagiats entwickelt wurde. Die Idee besteht darin, jedes Dokument als eine Menge von k-Gramm-FingerprintsEin k-Gramm ist eine zusammenhängende Sequenz von k Zeichen (oder Token), die aus einem Text extrahiert wird. Beispielsweise erzeugt das Wort „HELLO" mit k=4 die k-Gramme: HELL, ELLO. k-Gramm-Fingerprinting ermöglicht den Vergleich von Texten, auch wenn diese teilweise verändert wurden. darzustellen, die mittels eines gleitenden Fensters extrahiert werden.

Dieser Ansatz hat einen grundlegenden Vorteil gegenüber dem klassischen TF-IDFTerm Frequency–Inverse Document Frequency: eine statistische Technik, die misst, wie relevant ein Wort in einem Dokument im Vergleich zu einer Sammlung ist. Sehr häufige Wörter erhalten ein niedriges Gewicht; seltene, spezifische Wörter erhalten ein hohes Gewicht. (das ich als Fallback verwende): Es ist robust gegenüber partiellen Änderungen. Wurde ein Objekt nur in einigen Abschnitten modifiziert, erkennt Winnowing dennoch den strukturellen Overlap in den unveränderten Teilen und erzeugt einen signifikanten Ähnlichkeitsscore, auch bei substanziellen Änderungen.

Die rechenintensivste Komponente von Winnowing ist in einem nativen, in Rust kompilierten Modul implementiert, das in Python integriert ist. Dies reduziert die Analysezeiten bei großen Repositories erheblich im Vergleich zu einer rein Python-basierten Implementierung.

Ebene 3 — Struktureller FingerprintEin „digitaler Fingerabdruck" des JDE-Objekts: Anstatt den vollständigen Text zu vergleichen, wird eine reduzierte Menge semantisch bedeutsamer Token (Forms, Tabellen, Views, Joins) extrahiert, die die logische Struktur des Objekts unabhängig vom Code darstellen. mittels JaccardDer Jaccard-Index misst die Ähnlichkeit zwischen zwei Mengen: Er ist das Verhältnis der gemeinsamen Elemente (Schnittmenge) zur Gesamtheit der eindeutigen Elemente (Vereinigung). Wert 1 = identische Mengen, Wert 0 = keine gemeinsamen Elemente.

Ein reiner Textvergleich ist nicht ausreichend. Zwei JDE-Objekte können ähnlichen Textinhalt, aber eine völlig unterschiedliche Struktur haben. Deshalb habe ich eine zweite Schicht hinzugefügt, die auf dem Konzept des Structural FingerprintEin „digitaler Fingerabdruck" des JDE-Objekts: Anstatt den vollständigen Text zu vergleichen, wird eine reduzierte Menge semantisch bedeutsamer Token (Forms, Tabellen, Views, Joins) extrahiert, die die logische Struktur des Objekts unabhängig vom Code darstellen. basiert: eine Menge semantisch relevanter Token, die aus der Datei extrahiert werden.

Für jeden JDE-Objekttyp ist der Token-Satz unterschiedlich:

• Für APPL: Form-ID und verknüpfte Business View
• Für UBE: View und Report Interconnect
• Für BSVW: Tabellen und Join-Definitionen
• Für BSFN: Name der internen Funktion und zugehörige DSTR

Die Ähnlichkeit zwischen den beiden Token-Mengen wird über den Jaccard-IndexDer Jaccard-Index misst die Ähnlichkeit zwischen zwei Mengen: Er ist das Verhältnis der gemeinsamen Elemente (Schnittmenge) zur Gesamtheit der eindeutigen Elemente (Vereinigung). Wert 1 = identische Mengen, Wert 0 = keine gemeinsamen Elemente. (Verhältnis von Schnittmenge zu Vereinigung) berechnet, der misst, inwieweit die beiden Objekte dieselbe „Anatomie" teilen, unabhängig davon, wie der Code geschrieben ist.

Ebene 4 — Meta-Logik auf dem normalisierten Namen

Die vierte Komponente ist einfacher, hat aber einen wichtigen Einfluss auf die Genauigkeit. Jedes Custom-Objekt wird analysiert, um seinen „theoretischen Elternteil" zu identifizieren: Durch Entfernung des numerischen Custom-Präfixes aus dem Namen (z.B. P55 → P, R564 → R) erhält man den Namen des Standard-Objekts, von dem es höchstwahrscheinlich abstammt.

Existiert diese Entsprechung im Standard-Repository, erhält der Score des entsprechenden Kandidaten einen gewichteten Bonus. Dieser Mechanismus reduziert False Positives drastisch in Fällen, in denen die Namenskonvention eingehalten wurde.

Der finale Score und die Klassifizierung

Die drei Komponenten — Winnowing, struktureller Jaccard und Meta-Logik — werden mit definierten Gewichtungen kombiniert, um einen finalen Ähnlichkeitsscore zwischen 0 und 1 zu erzeugen. Das Ergebnis wird dann in vier Kategorien klassifiziert:

Für jeden Treffer generiert das Tool automatisch den Vergleichsbefehl für Beyond Compare (ein im JDE-Ökosystem weit verbreitetes Diff-Tool), sodass der Analyst den visuellen Diff zwischen dem Custom-Objekt und seinem Standard-Referenzobjekt mit einem einzigen Klick öffnen kann.

Output und praktischer Einsatz

Am Ende der Analyse erzeugt COS-Analysis einen Excel-Report mit allen Ergebnissen, sortiert nach Objekttyp und absteigendem Ähnlichkeitsscore. Jede Zeile enthält den Namen des analysierten Objekts, den besten gefundenen Standard-Referenz-Match, den prozentualen Ähnlichkeitswert, die Klassifizierung und den Beyond Compare-Befehl zur sofortigen Verwendung.

In meiner täglichen Praxis wird dieser Report zum Ausgangspunkt für Upgrade-Assessment-, Gap-Analysis- und Customizing-Dokumentations-Aktivitäten. In Projekten, in denen eine Migration auf ein neues JDE-Release ansteht, bedeutet das genaue Wissen, welche Custom-Objekte noch dem Original entsprechen und welche sich davon entfernt haben, eine fundierte und keine intuitive Planung der Re-Engineering-Aktivitäten.

Fazit

Das Problem der Identifizierung von JDE-Standard-Kopien ist ein reales, wiederkehrendes und in der Projektplanung häufig unterschätztes Problem. Der mehrstufige hybride Ansatz, den ich in COS-Analysis implementiert habe — mit semantischem Preprocessing, Winnowing mit Rust-Engine, struktureller Jaccard-Ähnlichkeit und Meta-Logik auf dem Naming — ermöglicht präzise Ergebnisse auch bei großen Repositories in Zeiten, die die Analyse praktikabel machen.

Wenn Sie ein JDE-System betreiben und mit diesen Herausforderungen konfrontiert sind, stehe ich gerne für ein Gespräch zur Verfügung.