Custom Development in JD Edwards — BSFN, NER, APPL und ERP-Automatisierung — ist der Punkt, an dem sich bei den meisten Implementierungen entscheidet, ob sie in den nächsten zehn Jahren erfolgreich bleiben oder technischen Schulden aufbauen. Die Plattform bietet vier zentrale Werkzeuge, um das Standardverhalten zu erweitern. Jede falsche Entscheidung darüber, welches Werkzeug für welchen Anwendungsfall eingesetzt wird, hat Folgen, die erst dann sichtbar werden, wenn ein Kurswechsel wirtschaftlich kaum noch möglich ist: während eines Upgrades, während eines Retrofits oder während eines Tools Release, das das zugrunde liegende Verhalten auf nicht dokumentierte Weise verändert.
Dieser Artikel ordnet die vier Werkzeuge — Business Functions in C, Named Event Rules, FDA-Anwendungen und Orchestrator — ein, beschreibt, wofür jedes davon tatsächlich geeignet ist, und zeigt Entscheidungsmuster, die sich in produktiven Umgebungen bei realen Kunden bewährt haben. Keines dieser vier Werkzeuge ist den anderen universell überlegen. Jedes deckt einen bestimmten Problemraum ab; die Disziplin besteht darin, diesen Raum zu erkennen, bevor die erste Codezeile geschrieben wird.
BSFN in C: die unterste Ebene des Stacks, in der wirklich schwere Logik lebt
Eine BSFNBusiness Function in JDE — kompilierte Business-Logic-Funktion, geschrieben in C oder von NER generiert. Sie wird auf dem Logic Server ausgeführt und kann von jedem Punkt der Plattform aufgerufen werden. in C ist die leistungsfähigste und zugleich am wenigsten wartbare Form von Custom Code in JDE. Es handelt sich um echten C-Code, der gegen die JDE-Runtime-Bibliotheken kompiliert, in die DLLs des Logic Servers gelinkt und von jedem Punkt der Plattform aufgerufen werden kann — Anwendungen, UBE, andere BSFN, Orchestrator, AIS REST. Die Performance entspricht nativem C, der Zugriff auf externe Bibliotheken ist über Standard-Linking-Mechanismen möglich, und die Kontrolle über das Verhalten ist maximal.
Der Preis dieser Leistung ist die Wartbarkeit. Wenn eine andere Person eine BSFN in C öffnet, die drei Jahre zuvor von einem Senior Developer geschrieben wurde, der inzwischen das Unternehmen verlassen hat, braucht sie vierzig bis fünfzig Minuten, um zu verstehen, was sie tut — vorausgesetzt, sie kennt die JDE-Makros (jdeStrcpy, jdeERRORInsert, jdeReadKeyed und die hundert anderen Runtime-Utilities). Eine funktional gleichwertige NER ist in fünfzehn Minuten lesbar.
Die Fälle, in denen eine BSFN in C die richtige Wahl ist, sind spezifisch und klar abgegrenzt: komplexes String-Parsing jenseits der Fähigkeiten von Event Rules, Datumsarithmetik außerhalb der eingebauten Operatoren, Aufrufe externer C-Bibliotheken, die in die Runtime gelinkt sind, oder Code, der über gemeinsame Header mit Legacy-Modulen geteilt wird. Von fünfzehn Custom BSFN, die in den letzten zwei Jahren bei Kunden geschrieben wurden, war nur eine wirklich in C — die anderen vierzehn waren NER, weil bei einer ehrlichen technischen Bewertung jedes Mal NER gewonnen hat.
Die andere nicht verhandelbare Disziplin bei BSFN in C ist Reentrancy. Die JDE-Runtime ruft BSFN unter Last parallel aus mehreren Threads auf, und jeder Zustand auf Modulebene — eine statische Variable, ein globaler Pointer, ein ungeschützter Cache — erzeugt intermittierende Fehler, deren Diagnose Wochen dauern kann. Zustand gehört in die übergebene Data Structure, niemals in statische Variablen.
NER: der De-facto-Standard für neue Logik
NERNamed Event Rules — visuelle Skriptsprache zum Schreiben von Business Functions ohne C-Code. Unter der Oberfläche werden sie vom Tools Release in C kompiliert. sind die Standardwahl für jede neue BSFN, die nicht in einen der oben beschriebenen Spezialfälle fällt. Der visuelle Editor stellt die Konstrukte bereit, die für 95 % der Business-Logik benötigt werden — Lesezugriffe auf indizierte Tabellen, bedingte Validierungen, Suchen in F0005 nach UDC, Zuweisung von Next Numbers aus F0002, Schreiben von Fehlerzeilen mit typisierten Codes — und der Compiler übersetzt sie in äquivalenten C-Code, der genau wie eine von Hand geschriebene BSFN ausgeführt wird.
Der operative Vorteil von NER, der oft unterschätzt wird, ist die lesbare Diff während Code Reviews. Eine Änderung an einer BSFN in C erzeugt eine C-Code-Diff, die der Reviewer Zeile für Zeile interpretieren muss. Eine Änderung an einer NER erzeugt eine visuelle Diff im Event-Rules-Panel, in der geänderte Bedingungen und hinzugefügte BSFN-Aufrufe sofort erkennbar sind. Die Review-Zeit halbiert sich, und die Zahl der im Review gefundenen Fehler steigt.
Die Grenzen von NER sind real, aber enger, als Oracle-Präsentationen oft vermuten lassen. String-Manipulation über elementare Operationen hinaus ist unbequem; Mathematik mit fester Genauigkeit bei Beträgen erfordert Aufmerksamkeit bei MATH_NUMERIC-Typen; der Aufruf externer Bibliotheken ist schlicht nicht verfügbar. Wenn eine dieser Einschränkungen auftritt, besteht die richtige Entscheidung nicht darin, NER so lange zu erzwingen, bis sie unlesbar wird. Die richtige Entscheidung ist, genau diese Operation in eine kleine BSFN in C auszulagern, die von der größeren NER aufgerufen wird, sodass C-Code auf den Teil beschränkt bleibt, der ihn wirklich benötigt.
APPL: die Schicht, in der Custom Development dem Benutzer begegnet
Custom Applications — APPL in der OMW-Sprache — sind die Forms, die der Benutzer sieht und ausführt. Sie werden in FDAForm Design Aid — visueller JDE-Designer zum Erstellen von Forms, Anhängen von Business Views, Definieren von Grids und Schreiben von Event Rules. Wird aus OMW gestartet, indem man auf eine ausgecheckte APPL doppelklickt. gebaut, an eine Business View gebunden, die die verfügbaren Spalten bestimmt, erhalten Event Rules an Controls wie Buttons, Grid-Zeilen oder Form Post-Load und werden wie jede Standardanwendung Teil des Menüs oder der Fast Path.
Das Standardmuster ist das Duo Find/Browse plus Fix/Inspect. Find/Browse ist das Eingangsformular — ein Grid mit QBE-Filterzeile oben und Buttons zur Navigation in die Detailansicht. Fix/Inspect ist das Detailformular — Record Header plus gegebenenfalls ein Grid mit verknüpften Zeilen, Save- und Cancel-Buttons. Fast alle Abfrage- und Verwaltungsanwendungen, die ich bei Kunden gebaut habe, folgen diesem Muster, weil JDE-Benutzer es sofort erkennen und es sich reibungslos in den Rest des Produkts integriert.
Die Falle, in die neue APPL-Entwickler regelmäßig geraten, besteht darin, zu viel Logik in die Event Rules der Forms zu legen, statt in wiederverwendbare BSFN. Eine komplexe Validierung in der Event Rule „Row Save“ eines Fix/Inspect funktioniert hervorragend, solange dieses Form der einzige Weg ist, in diese Tabelle zu schreiben. Sobald eine Orchestration, ein Z-File-UBE, ein AIS-Service oder ein zweites Custom Form beginnt, in dieselbe Tabelle zu schreiben, wird die Validierung vollständig umgangen. Die operative Regel, die funktioniert: Business-Logik gehört in BSFN; Form Event Rules rufen BSFN auf und verwalten nur die Benutzererfahrung — die fehlerhafte Zeile hervorheben, den Bestätigungsdialog anzeigen, zum nächsten Form navigieren.
Orchestrator und ERP-Automatisierung: die moderne Schicht über dem Stack
OrchestratorLow-Code-Studio von JDE, das REST-Aufrufe, AIS-Services, BSFN-Aufrufe und Benachrichtigungslogik in benannte Flows zusammensetzt. Das strategische Werkzeug für Integrationen und Automatisierung in EnterpriseOne. ist das strategische Integrationswerkzeug, das Oracle in neueren Tools Releases eingeführt hat, und es verändert die Gestalt moderner JDE-Entwicklung im Vergleich zu vor zehn Jahren am stärksten. Es ersetzt BSFN, NER oder APPL nicht — es ergänzt den Stack als Kompositions- und Automatisierungsschicht, in der Flows, die früher ein Custom UBE oder ein extern geplantes Skript erforderten, zu deklarativen Konfigurationen werden.
Das häufigste Nutzungsmuster bei Kunden ist die Bereitstellung von JDE-Logik für externe Systeme über REST. Ein B2B-Partner, der Sales Orders erstellen muss, ruft keine BSFN mehr über proprietäre Mechanismen auf. Er ruft einen REST-Endpunkt auf, der von einer Orchestration bereitgestellt wird und intern die Form Service Request Chain oder eine Sequenz von Custom BSFN mit Validierungen und Auftragserstellung ausführt. Der Partner sieht REST; JDE bleibt JDE; die Orchestration ist der Vertrag zwischen den beiden Welten.
Der andere Anwendungsfall mit unmittelbarem ROI ist die Automatisierung zuvor manueller Batch-Flows. Eine typische Sequenz — der Benutzer öffnet einen Report, speichert die Ausgabe, sendet sie per E-Mail an drei interne Empfänger und kopiert einen Teil in ein Excel-Sheet — wird zu einer Orchestration aus fünf Schritten, die jeden Morgen um 06:00 Uhr geplant läuft und dasselbe Ergebnis ohne menschlichen Eingriff liefert. Der Aufwand für den Bau beträgt ein oder zwei Tage; die Zeitersparnis für den Benutzer beträgt dreißig Minuten pro Tag, dauerhaft. Genau diese Art von Automatisierung rechtfertigt allein die Einführung von Orchestrator bei Kunden, die heute noch Mitarbeiter mit repetitiven manuellen Abläufen beschäftigen.
Die Grenze von Orchestrator ist das Volumen. Für Volumina unter einigen zehntausend Aufrufen pro Tag ist er perfekt. Für Orchestrations, die Millionen von Zeilen pro Zyklus verarbeiten müssen — eine Massenladung aus einem Legacy-System, eine Periodenneuberechnung über die gesamte F0911 — bleibt das richtige Werkzeug ein Custom UBE, der gegebenenfalls von Orchestrator als Trigger aufgerufen wird, nicht eine Orchestration, die direkt verarbeitet.
Die vier Werkzeuge in einem realen Fall zusammenführen
Ein realer Fall zeigt, wie die vier Werkzeuge im selben Projekt zusammenarbeiten. Fertigungsunternehmen, Anforderung: erweiterte Validierung bei der Erstellung von Kundenaufträgen, zugänglich sowohl aus dem Standardform P4210 als auch aus einem B2B-REST-Kanal und aus einem täglichen EDI-Import, mit Regeln, die sich je nach Kunde und Warengruppe ändern.
Die Lösung, die in den letzten Jahren bei Kunden entworfen und implementiert wurde, folgt diesem Schema. Eine Custom BSFN in NER, B5542VAL, erhält die Auftragszeile als Data Structure und wendet alle Regeln an — Lesezugriffe auf F0301 für Kredit, auf F4101 für Artikelsperren, auf eine kleine Custom-Tabelle F5542001 für kundenspezifische Regeln. Die BSFN gibt Severity und Error Code zurück. Eine NER, keine BSFN in C, weil die gesamte Logik aus Tabellenzugriffen und bedingtem Branching besteht, das NER nativ beherrscht.
Das Standardform P4210 wird mit einer kleinen Änderung an der Event Rule „Row Save“ erweitert, die B5542VAL vor dem Commit aufruft. Das ist der einzige Eingriff in den JDE-Standardcode und wird in der Upgrade-Roadmap als Retrofit geführt. Eine Orchestration „ValidateAndCreateSalesOrder“ stellt einen REST-Endpunkt bereit, den das B2B-System aufruft; intern ruft die Orchestration B5542VAL auf und startet, wenn die Validierung erfolgreich ist, die Standard-Chain zur Auftragserstellung. Das Custom UBE R5542EDI, das den täglichen EDI-Import verarbeitet, ruft ebenfalls B5542VAL für jede Zeile des Z-Files auf und markiert abgelehnte Zeilen in der Statusspalte der Staging-Tabelle.
Eine einzige Implementierung der Regeln, drei Eingangskanäle, identisches Verhalten in allen drei. Wenn das Business sechs Monate später eine Regeländerung verlangt — „fügt die Sperre für über 90 Tage fälligen Umsatz hinzu“ — wird die Änderung an einer einzigen Stelle vorgenommen, in B5542VAL, und wirkt sich bei der nächsten Promotion gleichzeitig auf alle Kanäle aus. Das ist der eigentliche Wert von diszipliniertem JDE Custom Development: nicht weniger Code zu schreiben, sondern Code zu schreiben, der zukünftige Änderungen erlaubt, ohne zehn verschiedene Stellen anfassen zu müssen.
Für eine vertiefende Betrachtung der einzelnen in diesem Artikel behandelten Themen decken die verwandten Artikel zur Order-Entry-Validierung mit BSFN, zur Object Promotion DV/PY/PD und zu Orchestrator Design Patterns die Materie im Detail ab. Das Projektportfolio dokumentiert zwei reale Implementierungen, die auf den hier beschriebenen Mustern basieren.