Was ein Custom Code Analyzer wirklich ist

Entfernt man die Marketingbedeutung, bleibt eine Pipeline, die drei Inputs verarbeitet und einen Output erzeugt. Die Inputs sind das Repository des Kunden, also der gesamte PDProduktionsumgebung in JDE — die Live-Umgebung. Ihr Repository ist die Quelle der Wahrheit dafür, welche Custom-Objekte auf Kundenseite tatsächlich existieren.-Pathcode oder ein gleichwertiger Stand, die Oracle-Baseline des Source Release und die Oracle-Baseline des Target Release. Der Output ist eine objektbezogene Entscheidung: behalten, verwerfen, retrofiten, neu schreiben.

Die Rechnung ist unerbittlich. In einer reifen Installation enthält das Kunden-Repository einen langen Schwanz von Objekten, die technisch custom, aber funktional tot sind — Kopien von Standards, die nie deployed wurden, Prototypen aus einem Proof of Concept von 2014, BSFNs, die 2017 während einer UDC-Untersuchung geklont wurden. Ein solcher Analyzer lässt nichts davon in die Entwicklungsphase gelangen. Er wendet zuerst einen Smart Filter an, und nur was diesen Filter überlebt, darf Engineering-Stunden verbrauchen.

Die objektbezogene Entscheidung macht das Konzept überhaupt erst benennenswert. Ohne sie behandelt man alle 12.000 Objekte als Arbeit; mit ihr behandelt man 350 als Arbeit und den Rest als Backup-and-RestoreStrategie, bei der unveränderte Custom-Objekte durch das Upgrade hindurch erhalten bleiben, indem sie einfach kopiert werden, ohne Analyse oder Retrofit-Arbeit.. Gleiches Upgrade, ein Sechstel des Budgets.

Warum der Begriff wie ein Tool klingt

Weil vor einigen Jahren zwei oder drei Anbieter auf der OpenWorld Produkte mit Namen vorgestellt haben, die Wörter wie Analyzer, Code und JDE enthalten. Das sind echte Produkte, einige davon gut, aber keines davon magisch. Was jedes dieser Produkte intern implementiert, ist dieselbe konzeptionelle Pipeline, die oben beschrieben wurde — Repository-Diff, Fingerprinting, Klassifizierung — verpackt in eine Benutzeroberfläche.

Die dadurch entstehende Verwirrung ist teuer. Ein CIO hört den Begriff und nimmt an, dass das Team eine SKU kaufen soll. Das Team beginnt, Lizenzkosten zu vergleichen, und verfehlt den Punkt: Der Wert liegt in der Disziplin, nicht in der Hülle. Eine Tabelle, bedient von einem Senior Consultant mit acht Upgrades von 9.1 auf 9.2, schlägt eine sechsstellige Lizenz, die von jemandem bedient wird, der noch keines gemacht hat. Das Tool kommt nach der Methode.

Behandle diese Disziplin wie Continuous Integration. Niemand fragt „welches CI soll ich kaufen?“, ohne zuerst zu klären, was CI bedeutet. Hier ist es genauso. Zuerst die Methode festlegen, dann entscheiden, ob sie mit einer Skript-Suite, einem Oracle-Partnerangebot oder einem lizenzierten Tool umgesetzt wird — in genau dieser Reihenfolge.

Der Smart Filter: wo 95 % der Arbeit verschwinden

Die erste Stufe jedes ernstzunehmenden Analyzers ist der Smart Filter, und genau dort rettet jedes Projekt entweder sein Budget oder verschwendet es. Der Filter folgt einem einzigen Prinzip: Ein Objekt ist nur dann analysewürdig, wenn sowohl der Kunde es verändert hat als auch Oracle es zwischen Source und Target Release verändert hat.

Wendet man diesen Test auf ein typisches Repository mit 12.000 Objekten an, werden rund 70 % sofort als obsolet oder doppelt entfernt — der tote Schwanz kumulativer Anpassungen. Von den verbleibenden 30 % wurde die große Mehrheit vom Kunden, aber nicht von Oracle im Versionsdelta verändert. Das bedeutet: Die Kundenänderungen werden unverändert übernommen, ohne Retrofit-Arbeit. Übrig bleiben nur 200 bis 500 Objekte in der echten Schnittmenge: vom Kunden verändert und von Oracle verändert. Das sind die betroffenen Objekte, und nur an diesen arbeiten die Entwickler wirklich.

Die Filterregeln klingen einfach. Sie sind es nicht, weil jede Regel eine Ausnahmeliste braucht. UBEUniversal Batch Engine — der Batch-Report-Runner von JDE. Custom-UBEs sind häufig, weil jeder Kunde eigene Reporting-Anforderungen hat.-Versionen werden anders gefiltert als zugrunde liegende UBE-Templates, UDCUser Defined Code — der JDE-Begriff für Code- oder Lookup-Tabellen. UDC-Ergänzungen benötigen fast nie Retrofit, weil Oracle den Namespace nicht besitzt.-Ergänzungen benötigen fast nie Retrofit, und Business-View-Änderungen folgen einem anderen Pfad als die Views selbst. Diese Regeln korrekt zu setzen, ist die eigentliche Fähigkeit dieser Disziplin.

Fingerprinting: wie man erkennt, was sich wirklich geändert hat

Der Smart Filter sagt, welche Objekte man betrachten muss. Der Fingerprint sagt, was sich in ihnen wirklich unterscheidet. Genau diesen Teil überspringen viele Teams und bezahlen später beim Testen dafür.

Ein naiver Diff vergleicht die BSFN des Kunden mit der Oracle-BSFN des Target Release und meldet jede abweichende Zeile. Das erzeugt Rauschen, das das Signal überdeckt: Eine umbenannte Custom-Variable erscheint genauso wie eine echte Logikänderung. Ein fingerprintbasierter Vergleich ist strukturell — er kanonisiert den Code, entfernt Formatierungsunterschiede, normalisiert Variablennamen innerhalb eines Scopes und erzeugt einen Hash der semantischen Form. Zwei Objekte mit demselben Fingerprint sind funktional äquivalent, auch wenn sie im Editor unterschiedlich aussehen.

Die praktische Folge: Mit Fingerprinting lässt sich in einem einzigen Durchlauf zwischen einem echten Konflikt und einem Phantomkonflikt unterscheiden. Ein echter Konflikt bedeutet: Oracle hat Logik A geändert, der Kunde hat Logik A geändert, und beide Änderungen interagieren. Ein Phantomkonflikt bedeutet: Oracle hat formatiert, der Kunde hat eine Variable umbenannt, es gibt keine echte Interaktion. Echte Konflikte bekommen einen Entwickler; Phantomkonflikte werden automatisch gelöst. In einem aktuellen Retrofit-Lauf lag das Verhältnis von Phantom- zu echten Konflikten bei ungefähr drei zu eins — der Unterschied zwischen drei Wochen Entwicklungszeit und einer.

Klassifizierung: die Entscheidung pro Objekt

Sobald klar ist, was sich geändert hat, wird klassifiziert. Jedes verbleibende Objekt landet genau in einem von vier Buckets, und der Bucket bestimmt die Arbeit. Die Klassifizierungsphase schließt den Kreis und verwandelt die Analyse in einen Projektplan.

Die vier Entscheidungen sind: keep — das Objekt ist custom, aber die Oracle-Baseline hat sich im Delta nicht geändert, also übernehmen ohne Arbeit; drop — das Objekt war custom, aber das Oracle-Äquivalent im Target Release deckt dieselbe Funktionalität ab, also Custom-Objekt löschen und Oracle verwenden; retrofit — Oracle hat es geändert, der Kunde hat es geändert, die Änderungen sind kompatibel, also mergen; rewrite — die Änderungen kollidieren, oder die Anpassung setzt Runtime-Verhalten voraus, das die neue Tools Release nicht mehr bereitstellt, also neu beginnen.

Der drop-Bucket wird von Teams unterschätzt. In jeder Release übernimmt Oracle Funktionalität, die Kunden in früheren Versionen custom gebaut hatten: Ein Orchestrator erledigt jetzt, was früher eine Custom-BSFN tat, ein Standard-UDO ersetzt eine Custom Form Extension, ein AIS-Endpunkt ersetzt ein Custom Interface. Ein Analyzer, der das Target Release nicht auf eingebaute Alternativen prüft, lässt Geld liegen — man retrofittet Code, der gelöscht werden sollte. Beim Wechsel von 9.1 auf 9.2.7 macht der Drop-Bucket in einer reifen Installation typischerweise 10 bis 20 % der verbleibenden Objekte aus.

Was upstream und downstream liegt

Die Pipeline existiert nicht isoliert. Upstream liegen der Planner ESUDer spezielle ESU, der die Planner-Schemas aktualisiert, bevor irgendein anderer ESU angewendet werden kann. Er ist die Grundlage des Upgrade-Prozesses. und der Snapshot der Quellumgebung — ohne sauberen Snapshot hat der Analyzer keinen verlässlichen Input. Downstream liegen die Entwicklungsphase, der Regressionstest und der Cutover.

Das Artefakt, das der Analyzer an das Dev-Team übergibt, entscheidet über die nächsten 6 bis 9 Wochen. Ein guter Handoff ist ein objektbezogener Work Order: Objektname, Entscheidung, Target-Oracle-Baseline-Path, identifizierte Konfliktpunkte und Schätzung. Ein schlechter Handoff ist eine Tabelle mit 12.000 Zeilen und einer Spalte „review needed“. Teams, die Upstream- und Downstream-Verbindungen sauber herstellen, schaffen ein Upgrade von 9.1 auf 9.2 in neun Wochen Entwicklungszeit; Teams, die es falsch machen, brauchen sechsundzwanzig.

Noch ein Punkt zu downstream. Der Output des Analyzers sollte auch die Auswahl der Regressionstests steuern. Wenn der Analyzer sagt, dass nur 320 Objekte betroffen sind, sollte sich die Regression auf die Use Cases konzentrieren, die diese 320 Objekte ausführen — nicht auf einen sechswöchigen Full-Suite-Test, der 90 % eines unveränderten Systems erneut validiert. Das ist die zweite Stelle, an der sich die Disziplin auszahlt, und dort merken die meisten CIOs, dass sie die richtige Methode gekauft haben.

Was das für deinen Upgrade-Plan bedeutet

Wenn du gerade ein JDE-Upgrade scope-st und das Angebot vor dir keine Analyzer-Pipeline unter irgendeinem Namen beschreibt, ist das Angebot unvollständig. Der Begriff muss nicht wörtlich vorkommen — Synonyme wie Retrofit Analysis, Customization Assessment oder Code Impact Study beschreiben dieselbe Disziplin — aber die vier Pipeline-Stufen müssen enthalten sein: Snapshot, Smart Filter, Fingerprint, Klassifizierung.

Bitte den Partner, seinen Analyzer an einer Stichprobe von fünfzig deiner Objekte zu erklären. Wenn er an einem Nachmittag eine Entscheidung pro Objekt liefern kann, besitzt er die Disziplin. Wenn er drei Wochen und einen Workshop braucht, wird er sie auf deine Zeit und dein Geld neu entdecken. Der Unterschied liegt bei einer reifen Installation mit zwölftausend Custom-Objekten zwischen einer neunwöchigen Entwicklungsphase und einer sechsmonatigen — und genau diese Lücke ist der Wert, den das Konzept erfassen soll.

Wenn du eine zweite Meinung dazu möchtest, wie eine solche Pipeline für dein konkretes Repository aussehen sollte — die Aufteilung deiner Custom-Landschaft, die realistische Zahl betroffener Objekte für dein Delta und die Buckets, in die dein Retrofit fallen wird — buche eine kostenlose Beratung. Wir gehen deine Umgebung gemeinsam durch, und du erhältst ein konkretes Bild der Arbeit, die wirklich vor dir liegt, sowie der Arbeit, die du sicher beiseitelegen kannst.