Ein Standard-EnterpriseOne-GridEine Benutzeroberflächen-Komponente in JD Edwards zur Darstellung von Daten in Zeilen und Spalten., das nur 500 Zeilen verarbeitet, kann unbemerkt Tausende von Datenbank-Abrufen ausführen, wenn ungepuffertes Table I/ODatenbankoperationen zum Lesen, Schreiben oder Aktualisieren von Datensätzen. oder schwere Business FunctionsWiederverwendbare Programmeinheiten in JDE, die spezifische Geschäftslogik ausführen. innerhalb der Ereignisse "Grid Record Is Fetched" oder "Write Grid Line-Before" platziert werden. Dieses synchrone Ausführungsmodell führt zu einem schwerwiegenden JDE APPLEine interaktive Anwendung innerhalb der JD Edwards EnterpriseOne Umgebung. Performance-Problem durch wiederholte Lesezugriffe in Grid-Loops, bei dem der interaktive JVM-ThreadEin Ausführungspfad innerhalb der Java Virtual Machine, der Benutzeranfragen verarbeitet. blockiert, während er auf sequentielle Datenbank-Roundtrips wartet. Wenn eine einzelne Benutzeraktion zweistellige Sekundenbeträge anstatt eines Bruchteils einer Sekunde in Anspruch nimmt, ist die Ursache fast immer diese repetitive, zeilenweise synchrone Verarbeitung.
Um dies zu beheben, müssen Entwickler aufhören, das Grid wie einen Datenbank-CursorEin Steuerelement, das das Durchlaufen der Datensätze in einer Datenbank ermöglicht. zu behandeln, und beginnen, Speicherstrukturen effektiv zu nutzen. Analysieren Sie vor dem Refactoring die Kardinalität der Ziel-Tabelle; wenn Sie wiederholt statische Setup-Daten wie Zahlungsbedingungen (F0014) oder Branch/Plant-Konstanten (F41001) abfragen, gehören diese Daten in einen JDE CacheEin temporärer Speicherbereich im Arbeitsspeicher für schnellen Datenzugriff ohne erneute Datenbankabfrage. oder eine speicherresidente Named Event Rule (NER)Eine JDE-eigene Programmiersprache, die zur besseren Performance in C-Code umgewandelt werden kann.. Durch die Verlagerung dieser Logik in eine C-basierte Business Function (BSFN), die die JDE Cache APIProgrammierschnittstelle zur Verwaltung und Abfrage des JDE-internen Arbeitsspeichers. nutzt, reduzieren Sie den Datenbank-Overhead erheblich – oft um mehr als 80 % – und stellen Antwortzeiten im Sub-Sekunden-Bereich wieder her.
Die Anatomie eines Grid-Loop-Engpasses
In benutzerdefinierten JDE-Anwendungen platzieren Entwickler häufig standardmäßig ein F4101 Fetch Single innerhalb des Ereignisses "Grid Record is Fetched", um Artikelbeschreibungen oder Kategorie-Codes on-the-fly abzurufen. Diese Entscheidung führt zu massiven Performance-Einbußen, da die Ereignisse "Grid Record is Fetched" und "Write Grid Line-After" sequentiell für jede einzelne in das Grid-Control geladene Zeile ausgeführt werden. Wenn ein Benutzer eine Search-and-Select-Form abfragt, die 200 Datensätze abruft, muss der HTML-ServerDer Webserver (JAS), der die grafische Benutzeroberfläche für den JDE-Benutzer bereitstellt. 200 Mal warten, bis der Enterprise Server und die Datenbank diese synchronen Roundtrips abgeschlossen haben, bevor die Seite gerendert werden kann.
Die Performance-Verschlechterung potenziert sich exponentiell, wenn mehrere Tabellen-Lookups innerhalb dieser Loop-Events gestapelt werden. Ein typisches benutzerdefiniertes Grid, das 200 Datensätze mit drei unabhängigen Tabellen-Lookups innerhalb der Schleife anzeigt – wie z. B. Abrufe aus F4101, F4102 und F0006 – führt zu 600 separat ausgeführten SQL-StatementsStandardisierte Befehle zur Kommunikation und Datenabfrage mit einer relationalen Datenbank.. Da jedes Statement einen eigenen Roundtrip über die MiddlewareSoftware, die als Brücke zwischen verschiedenen Anwendungen, Servern und der Datenbank fungiert. erfordert, lässt selbst eine niedrige Datenbank-Antwortzeit von 2 Millisekunden pro Abfrage die Ladezeit des Grids auf über eine Sekunde reine Datenbank-Wartezeit ansteigen, exklusive Netzwerk-Overhead.
Unter der Haube behandelt die Runtime-Engine des JDE-Toolset jedes Event Rules (ER)Die proprietäre Skriptsprache von JD Edwards zur Definition von Anwendungslogik. Statement als isolierte Anweisung. Im Gegensatz zu modernen Anwendungs-Frameworks, die Object-Relational Mapping (ORM)Eine Technik, um Daten aus einer Datenbank als Objekte in einer Programmiersprache darzustellen. zur Bündelung von Anfragen nutzen, kann die JDE-Engine diese einzelnen ER-Statements nicht in eine einzige mengenbasierte Datenbank-Operation optimieren. Diese architektonische Einschränkung bedeutet, dass das Platzieren von Select- und Fetch Next-Schleifen innerhalb von Grid-Events das System in ein geschwätziges, zeilenweises Ausführungsmuster zwingt, das die Fähigkeit der Datenbank zur Optimierung mengenbasierter Ausführungspläne umgeht.
Messung von Timing und Datenbank-Overhead
Ein einzelner Datenbank-Abruf über ein lokales Netzwerk dauert in der Regel zwischen 2 und 5 Millisekunden. Isoliert betrachtet wird ein Entwickler, der einen einzelnen Datensatz auf einem lokalen Entwicklungs-Client testet, diese Verzögerung niemals bemerken. Wenn dieser einzelne Abruf jedoch in ein "Grid Record is Fetched"- oder "Write Grid Line-Before"-Event eingebettet und über einen 500-zeiligen Grid-Loop multipliziert wird, ändert sich die Rechnung drastisch. Eine scheinbar geringfügige Latenz von wenigen Millisekunden pro Abruf eskaliert sofort zu über einer Sekunde reiner Datenbank-Wartezeit für eine einzelne Benutzeraktion, wodurch der interaktive Thread blockiert wird, während der HTML-Server auf den Enterprise Server wartet.
Um diesen spezifischen Engpass zudiagnostizieren, müssen Sie die Standard-CallObject-Kernel-Logs umgehen und das jdedebug.log für die spezifische HTML-Sitzung isolieren. Die Suche in diesem Log nach JDB_FetchKeyed-Statements unter der Thread-ID Ihrer Anwendungsausführung offenbart die exakte Timing-Aufschlüsselung der zugrunde liegenden SELECT-Statements. Sie werden häufig beobachten, dass dasselbe SQL-Statement hunderte Male mit identischen WHERE-Klausel-Parametern ausgeführt wird – wie z. B. das Abrufen derselben Kategorie-Code-Beschreibung aus der Tabelle F0005 (UDCUser Defined Codes; anpassbare Werte-Listen innerhalb von JD Edwards.) oder Artikelstammdaten aus der F4101 für jede einzelne Detailzeile.
Der Vergleich der Zeitstempel 'Time Start' und 'Time End' dieser sequentiellen JDB_FetchKeyed-Aufrufe legt die kumulative Verzögerung der synchronen Event Rules-Ausführung offen. Da EnterpriseOne Grid-Event-Rules synchron ausführt, bleibt der Browser des Benutzers in einem Verarbeitungszustand gesperrt, bis die letzte Iteration abgeschlossen ist. Wenn Ihr Log 500 Iterationen eines F4101-Abrufs zeigt, die jeweils einige Millisekunden dauern, stellt die mehrsekündige Lücke zwischen dem ersten 'Time Start' und dem letzten 'Time End' Totzeit dar, die weder durch Webserver-Tuning noch durch JVM-Speicherzuweisung behoben werden kann.
Identifizierung des idealen Cache-Kandidaten
In einer Standard-Distributions-APPL wie P4210 oder P4111 löst das Ereignis "Grid Record Fetched" oft einen redundanten Lookup in der Tabelle F41001 (Inventory Constants) für jede einzelne Zeile aus. Statische oder sich selten ändernde Tabellen wie F0005 (UDC) oder F41001 sind prädestinierte Kandidaten für das Caching auf Anwendungsebene, da ihre Daten während der gesamten Lebensdauer der Anwendungssitzung konstant bleiben. Die Datenbank 500 Mal für dieselbe Branch/Plant-Konstante während eines Grid-Ladevorgangs abzufragen, ist eine Verschwendung von Datenbankressourcen.
Wenn derselbe Datensatz während einer einzelnen Grid-Ausführung mehr als dreimal abgerufen wird, muss er als Cache-Kandidat markiert werden, um redundante I/O zu vermeiden. Beispielsweise werden in einem 200-zeiligen Grid, in dem 150 Zeilen zu denselben drei Branch/Plants gehören, bei einem Standard-Abruf 200 SQL-Statements ausgeführt. Durch die Identifizierung dieser repetitiven Lookup-Muster während der Designphase eliminieren Sie den Overhead wiederholter Datenbank-Roundtrips.
Die Verwendung von JDE Cache ermöglicht es Entwicklern, Referenzdaten einmalig während des Ereignisses 'Post Dialog Is Initialized' in den Benutzerspeicher zu laden. Anstatt bei jeder Grid-Zeile auf die Datenbank zuzugreifen, kann eine benutzerdefinierte C-Business-Function eine Speicherstruktur mit den erforderlichen F41001-Datensätzen vorab füllen. Der Grid-Loop fragt dann diese Speicherstruktur ab, anstatt ein SQL-SELECT-Statement auszuführen.
Das Speichern von Key-Value-Paaren im Speicher reduziert die anschließende Abrufzeit von Millisekunden auf Mikrosekunden. Ein physischer Datenbank-Lesezugriff über ein Netzwerk dauert je nach Netzwerklatenz und Datenbankindizierung in der Regel 2 bis 10 Millisekunden. Das Abrufen desselben Key-Value-Paares aus dem lokalen Speicher dauert weniger als 10 Mikrosekunden, was zu einer nahezu vollständigen Reduzierung der Abrufzeit für diesen spezifischen Datenpunkt führt.
Refactoring zu NER für mengenbasierte Logik
Das Platzieren von fünf aufeinanderfolgenden Fetch Single-Statements innerhalb des "Grid Record Is Fetched"-Events einer schweren Transaktionsanwendung wie P4210 oder P4312 ist ein architektonisches Anti-Pattern. Jedes Table I/O auf FDAForm Design Aid; das Entwicklungswerkzeug zum Erstellen von JDE-Anwendungsoberflächen.-Ebene zwingt den HTML-Server zur Koordination mit dem Enterprise Server, was massiven Call-Stack-Overhead für jede einzelne Zeile im Grid erzeugt. Die Verlagerung dieses repetitiven Table I/O in eine Named Event Rule (NER) konsolidiert diese fragmentierten Datenbankoperationen sofort in eine einzige, kompilierte C-Komponente.
Dieser Wechsel ermöglicht es Ihnen, verwandte Validierungsschritte – wie die Prüfung von F4102-Artikel-Filialdatensätzen, F03012-Kundenfakturierungsanweisungen und F4101-Kategorie-Codes – in einem einheitlichen Ausführungsblock zu gruppieren. Da die NER direkt auf dem Enterprise Server läuft, wird die Business-Logik wesentlich näher an der Datenbank-Engine ausgeführt. Anstelle von fünf separaten Roundtrips von der Präsentationsschicht verarbeitet das System die Validierungslogik lokal auf der Anwendungsebene, wodurch die Ausführungszeiten von über 100 Millisekunden pro Grid-Zeile auf einstellige Millisekunden gesenkt werden.
Um dies zu implementieren, definieren Sie eine saubere Datenstruktur, die die Schlüsselfelder der Grid-Zeile – wie MCU, ITM und AN8 – akzeptiert und alle fünf erforderlichen Attribute, wie Zeilentyp, Zahlungsbedingungen und Lagerkosten, in einem einzigen Aufruf zurückgibt. Diese strukturierte Parameterliste macht sequentielle, unabhängige Datenbank-Lesezugriffe in der FDA überflüssig.
Durch das Bündeln dieser Abrufe minimieren Sie das Netzwerk-Geschwätz zwischen dem HTML-Server, dem Enterprise Server und dem Datenbank-Server und transformieren einen geschwätzigen, zeilenweisen Engpass in eine effiziente, mengenbasierte Operation. Bei einem Grid, das 100 Zeilen lädt, reduziert diese Optimierung die einzelnen Netzwerkaufrufe von 500 auf nur noch 100. Dies entscheidet direkt darüber, ob die Anwendung unter Produktionsvolumen reaktionsschnell bleibt.
Implementierung der JDE Cache API in C Business Functions
Wenn ein Grid 500 oder mehr Zeilen enthält, führt die Ausführung von Datenbank-Abrufen via Table I/O innerhalb des "Grid Record Is Fetched"-Events mit hoher Wahrscheinlichkeit zu einer erhöhten CPU-Auslastung des CallObject-KernelsEin Serverprozess in JD Edwards, der für die Ausführung von Business Functions zuständig ist.. Für maximale Performance bieten C-basierte Business Functions (BSFN) unter Verwendung der jdeCache-APIs den Datenzugriff mit der geringsten Latenz, da sie die Middleware-Übersetzungsschicht eliminieren. Diese APIs arbeiten direkt im Speicherbereich des CallObject-Kernels und umgehen den Datenbanktreiber vollständig, sobald der initiale Ladevorgang abgeschlossen ist.
Die APIs jdeCacheInit, jdeCacheAdd und jdeCacheFetch ermöglichen es Entwicklern, strukturierte In-Memory-Datentabellen direkt im CallObject-Kernel zu verwalten. Während des Ereignisses "Dialog Is Initialized" oder "Post Dialog Is Initialized" der APPL kann eine C-BSFN ein einzelnes, optimiertes SQL-Select ausführen, um die gesamte Teilmenge der erforderlichen Referenzdatensätze – wie z. B. 1.000 Branch/Plant-Konstanten – in eine benutzerdefinierte Cache-Instanz zu laden. Diese Datenbankoperation mit nur einem Roundtrip ersetzt hunderte einzelner SELECT-Statements, die andernfalls während des Grid-Ladevorgangs ausgeführt würden.
Sobald der Cache gefüllt ist, fragen nachfolgende Grid-Loop-Iterationen den Speicher-Cache mittels jdeCacheFetchPosition ab, wobei der Datenbanktreiber und der Netzwerk-Stack komplett umgangen werden. Diese API-Ausführung innerhalb einer C-BSFN zielt unter Verwendung einer vordefinierten Indexstruktur auf das spezifische Cache-Bucket ab und ruft die erforderliche Zeile in Sub-Millisekunden-Zeit ab. In einer Hochvolumen-APPL mit einem 500-zeiligen Grid senkt das Ersetzen einzelner SQL-Lookups durch jdeCacheFetchPosition in der Regel die gesamte Ausführungszeit der Event Rules von zweistelligen Sekunden auf einen Bruchteil einer Sekunde. Entwickler müssen dies mit einem abschließenden Aufruf von jdeCacheTerminate im Ereignis "End Form/Close" kombinieren, um Memory LeaksEin Fehler, bei dem Arbeitsspeicher belegt, aber nicht wieder freigegeben wird, was das System verlangsamt. im CallObject-Kernel zu verhindern.
Form Extensions und Orchestrations als Alternativen
Das Ersetzen veralteter Event Rules durch Form ExtensionsEin JDE-Werkzeug zur Anpassung von Bildschirmen ohne Programmierung. in Tools ReleaseDie Version der zugrunde liegenden Technologieplattform von JD Edwards. 9.2.x bietet eine No-Code-Methode zum Mapping von Feldern, ohne die APPL anzupassen. In P4210- oder P4310-Anpassungen schrieben Entwickler früher ER im Ereignis "Grid Record Is Fetched", um Daten aus F0101 oder F4101 abzurufen. Form Extensions umgehen dies, indem sie Spalten direkt mappen, was die Kosten für Upgrade-Anpassungen bei einfachen Datenabrufen erheblich reduziert, oft um bis zu die Hälfte.
Wenn Joins über mehrere Tabellen erforderlich sind, nutzt Tools Release 9.2.7 die Orchestrator Data Request Aggregation, um Group-by-Operationen auf Datenbankebene auszuführen. Anstatt 500 einzelne SELECT-Statements auszuführen, um den offenen Saldo eines Kunden zu berechnen, gibt ein einziger REST-AufrufEine standardisierte Methode zur Kommunikation zwischen Web-Services. die voraggregierte Summe zurück. Dies verlagert die Rechenlast auf die Datenbank-Engine, wo Indizes den Abruf in Millisekunden optimieren.
Ein kritischer Architekturfehler tritt auf, wenn Entwickler diese OrchestrationsAutomatisierte Prozesse, die über den JDE Orchestrator erstellt und ausgeführt werden. innerhalb eines Grid-Loop-Events aufrufen, wie z. B. "Row Is Exited/Changed Inline" oder "Write Grid Line-Before". Jeder einzelne Orchestration-Aufruf löst einen ausgehenden HTTP-POST-RequestEine Methode zum Senden von Daten an einen Server über das HTTP-Protokoll. vom AIS-ServerApplication Interface Services Server; die Schnittstelle für mobile Apps und den Orchestrator. aus, was eine Netzwerklatenz von 15 bis 50 Millisekunden pro Zeile verursacht. In einem Grid mit 200 Zeilen summiert sich dieses Anti-Pattern auf mehrere Sekunden reinen Netzwerk-Overhead, was die Anwendung unbrauchbar macht und eine weitaus schlechtere Performance als Standard-ER-Datenbank-Lesezugriffe aufweist.
Um diese Latenz zu eliminieren, rufen Sie die Orchestration einmal während des Ereignisses "Post Dialog Initialized" auf, um den aggregierten Datensatz in eine temporäre Speicherstruktur zu laden, bevor das Grid geladen wird. Verwenden Sie einen schnellen Pointer-Lookup, um die Grid-Zeilen zu füllen, und vermeiden Sie ausgehende Netzwerk-Hops während der Rendering-Phase. Die Beschränkung der Orchestrator-Ausführung auf diese Einzelaufrufe vor der Grid-Initialisierung gewährleistet Bildschirm-Antwortzeiten im Sub-Sekunden-Bereich bei gleichzeitiger Beibehaltung einer sauberen, upgrade-sicheren APPL.
Die Reduzierung der Row-Exit-Latenz von mehreren Sekunden auf einen Bruchteil einer Sekunde erfordert oft den Schritt über Standard-Event-Rules hinaus hin zu C-basiertem Caching für Tabellen mit hohem Volumen wie F4211 oder F0911. Für Entwickler, die 9.2.x.x-Umgebungen verwalten, ist das Ersetzen repetitiver Grid-Abrufe durch speicherresidente Arrays der effektivste Weg, um die APPL-Performance unter hoher gleichzeitiger Last zu stabilisieren. Um zu sehen, wie diese Muster in großem Maßstab angewendet werden – einschließlich spezifischer BSFN-Cache-Strukturen und Orchestrator-Datenabfrage-Optimierungen – werfen Sie einen Blick auf unser technisches Projektportfolio oder lesen Sie die verwandten Deep-Dives zu JDE-Speichermanagement und AIS-Performance-Tuning.
