In über zwei Jahrzehnten der Fehlerbehebung bei benutzerdefinierten JDE-AnwendungenSoftwareanwendungen innerhalb des JD Edwards EnterpriseOne ERP-Systems, die für Geschäftsprozesse wie Finanzen oder Logistik genutzt werden. sehe ich regelmäßig benutzerdefinierte Find/Browse- oder Header-Detail-Formulare, deren RenderingDer Prozess, bei dem der Webbrowser den Programmcode in eine sichtbare und interaktive Benutzeroberfläche umwandelt. vier bis acht Sekunden dauert. Der Grund: Entwickler packen synchrone F0101- oder F4101-Table I/OBefehle innerhalb der JDE-Logik, die Daten direkt aus Datenbanktabellen lesen, schreiben oder aktualisieren.-Abfragen in das Dialog Is InitializedEin technisches Ereignis beim Start einer JDE-Anwendung, das Logik ausführt, bevor der Benutzer den Bildschirm sieht.-Event. Dieser Designfehler umgeht das native Datenbank-zu-Grid-Mapping der JDE-Engine und zwingt den HTML-ServerAuch JAS genannt; die Komponente, die die JDE-Logik für die Darstellung im Webbrowser aufbereitet., auf serialisierte Datenbank-Roundtrips zu warten, bevor das erste Pixel gerendert wird.

Um dies zu beheben, müssen wir von synchronen, prozeduralen Abfragen zu einer ereignisgesteuerten Verzögerung übergehen. Wir werden ein konkretes JDE APPLDie Kurzbezeichnung für eine interaktive Anwendung innerhalb der JD Edwards Entwicklungsumgebung. Table I/O-Beispiel analysieren, um langsame Formular-Ladezeiten zu vermeiden, indem wir sekundäre Validierungsabfragen aus der Formularinitialisierung in das Grid Record Is FetchedEin Ereignis, das jedes Mal ausgelöst wird, wenn eine einzelne Zeile in einer JDE-Tabelle (Grid) geladen wird.-Event verschieben. Diese einzige architektonische Anpassung reduziert die LatenzDie Verzögerungszeit zwischen einer Benutzeranfrage und der Antwort des Systems. beim Start interaktiver Formulare regelmäßig um 75 % bis 80 %, während der JVM-Thread-PoolEin Bereich im Arbeitsspeicher des Servers, der die gleichzeitige Ausführung mehrerer Aufgaben (Threads) verwaltet. des HTML-Servers entlastet wird.

Die Mechanik der Formular-Ladeverzögerung

Wenn ein Benutzer eine benutzerdefinierte interaktive Anwendung öffnet, verarbeitet die JAS-EngineDer Java Application Server, der die Kernlogik und die Weboberfläche von JD Edwards verarbeitet. den Lebenszyklus der Formularerstellung sequenziell. Das Dialog Is Initialized-Event blockiert den Thread der Präsentationsschicht vollständig, bis jede synchrone Zeile der Event Rules (ER)Die proprietäre Programmiersprache von JD Edwards, mit der Geschäftslogik erstellt wird. ausgeführt wurde. Wenn Entwickler dieses Event als Abladeplatz für die Setup-Logik missbrauchen, kann der HTML-Client nicht einmal mit dem Aufbau des Bildschirms beginnen.

Das Ausführen mehrerer Table I/O-Operationen wie 'Fetch Single' oder 'Select/Fetch Next'-Schleifen gegen große Stammdatentabellen wie den Address Book Master (F0101) oder Item Master (F4101) während dieser Blockierphase erzeugt einen sofortigen Performance-Engpass. Jeder einzelne Abruf erfordert einen Roundtrip vom HTML-Server zum Enterprise Server und dann zum Datenbankserver. Dieses Verhalten summiert die Netzwerklatenz, insbesondere in hybriden Cloud-Topologien, in denen sich Datenbank- und HTML-Server in unterschiedlichen Subnetzen befinden.

Während diese Datenbank-Roundtrips stattfinden, starrt der Endbenutzer auf einen leeren oder eingefrorenen Webbrowser. Der HTML-Client wartet darauf, dass die JAS-Engine – und in modernen Deployments der AISApplication Interface Services; ein Server, der JDE-Daten über moderne REST-Schnittstellen für externe Apps bereitstellt. Server – die synchrone Metadatenverarbeitung abschließt und den initialen Daten-Payload zurückgibt. Bis dieser Payload geliefert wird, kann die Rendering-Engine des Browsers das clientseitige JavaScript nicht ausführen, das zum Zeichnen der Formularsteuerelemente erforderlich ist.

In unseren Performance-Audits von Legacy-9.1-Systemen, die auf 9.2 aktualisiert wurden, benötigt eine typische nicht optimierte benutzerdefinierte APPL acht bis zwölf Sekunden zum Laden, wenn sie mehr als ein Dutzend sequenzielle Datenbanklesevorgänge vor dem Rendern des Formulars ausführt. Das Ersetzen dieser sequenziellen Lesevorgänge durch mengenbasierte Logik oder Lazy LoadingEin Designmuster, bei dem Daten erst dann geladen werden, wenn sie tatsächlich benötigt werden. ist der schnellste Weg, um die Ladezeiten unter den Schwellenwert von ein bis zwei Sekunden zu senken.

Table I/O von der Datenbank-Performance isolieren

Ich sehe regelmäßig Entwickler, die Tage damit verbringen, DatenbankindizesEine Datenstruktur, die das Suchen und Abrufen von Datensätzen in einer Datenbank massiv beschleunigt. auf Tabellen mit hohem Volumen wie F0911 oder F4111 zu optimieren, um einen trägen Bildschirm zu beheben. Sie gehen davon aus, dass die Datenbank Schwierigkeiten hat, die Datensätze zu finden, wenn die Formularinitialisierung langsam ist. Die Realität ist kontraintuitiv: Die Datenbank arbeitet oft perfekt, aber die schiere Menge an sequenziellen Roundtrips zwischen dem Enterprise Server und der Datenbank-Engine killt die Performance. Wenn eine benutzerdefinierte Anwendung während des Starts hunderte Male ein Fetch Single innerhalb einer Schleife ausführt, summiert sich selbst ein hochoptimierter Index-Read von wenigen Millisekunden zu einer mehrsekündigen Verzögerung, bevor das Grid geladen wird.

Diese Latenzdifferenz führt zu einer klassischen Diskrepanz zwischen DBAs und JDE-Entwicklern. Ihr Datenbankadministrator wird sich den Oracle Database oder SQL Server Profiler ansehen und keine Probleme melden, wobei er auf eine niedrige CPU-Auslastung und Ausführungszeiten im Sub-Millisekundenbereich verweist. In der Zwischenzeit zeigen Ihre JDE HTML-Server-Logs und jas.log-Dateien massive CallObject KernelEin Prozess auf dem Enterprise Server, der die eigentliche Geschäftslogik und Berechnungen ausführt.-Laufzeiten für die zugehörige Anwendung. Der Engpass ist nicht die Geschwindigkeit des Datenabrufs auf Festplattenebene; es ist der Netzwerk- und MiddlewareSoftware, die als Vermittler zwischen dem Betriebssystem und den Anwendungen fungiert, um Datenaustausch zu ermöglichen.-Overhead für die serielle Verwaltung tausender einzelner Datenbankoperationen.

Um diesen architektonischen Engpass zu umgehen, müssen Sie die zeilenweise Verarbeitung während des Dialog Is Initialized-Events eliminieren. Anstatt einzelne Table I/O-Anweisungen innerhalb einer Event-Rules-Schleife auszuführen, sollten Sie die Logik auf mengenbasierte Verarbeitung umstellen oder das Laden von Hilfsdaten verzögern. Anstatt beispielsweise F4111-Transaktionsdaten für jede Zeile in einem Grid mit 500 Datensätzen abzufragen, rufen Sie die eindeutigen Schlüssel einmal beim Formularstart in einen JDE-CacheEin temporärer Speicher im RAM des Servers, um häufig benötigte Daten extrem schnell ohne Datenbankzugriff abzurufen. ab, wodurch hunderte von Datenbank-Roundtrips auf einen einzigen Speicherzugriff reduziert werden.

Strategische Event-Platzierung für Table I/O

Das Platzieren schwerer Fetch Single-Schleifen im Dialog Is Initialized-Event ist der schnellste Weg, um eine HTML-Client-Sitzung für fünf bis zehn Sekunden einzufrieren. In dieser Phase der JDE-Runtime-Engine bereitet das System noch das strukturelle Layout des Formulars vor, was bedeutet, dass der Benutzer einen leeren Bildschirm sieht, während die Datenbank arbeitet. Das Verschieben dieser nicht blockierenden Datenbankoperationen in das Post Dialog Is Initialized-Event stellt sicher, dass die Formularstruktur sofort gerendert wird, was dem Benutzer die visuelle Bestätigung gibt, dass die Anwendung reagiert.

Ein häufiger architektonischer Fehler in benutzerdefinierten JDE-Anwendungen ist das Abrufen von Hilfsdaten auf Grid-Ebene während des initialen Formularladens. Bei einem Grid, das 50 Datensätze anzeigt, erzwingt das Ausführen einzelner Tabellen-Lookups während der Initialisierung Dutzende von sequenziellen Datenbank-Roundtrips. Entwickler müssen diese Arbeit in die Events Grid Record is Fetched oder Write Grid Line-Before auslagern, die dynamisch ausgeführt werden, wenn jede Zeile gefüllt wird. Dies reduziert die Größe des initialen Payloads und verhindert Timeouts des JAS-Servers.

In Find/Browse-Formularen schreiben Entwickler oft manuelle Select- und Fetch Next-Schleifen innerhalb des Find-Buttons, um Grid-Ergebnisse zu filtern. Dies umgeht die integrierte Datenbank-Cursor-Verwaltung der JDE-Engine. Die Ausführung der Systemfunktion Set Selection innerhalb des Clear Screen Before Find-Events ermöglicht es der nativen JDE-Engine, benutzerdefinierte WHERE-Klauseln direkt an das primäre SELECT-Statement anzuhängen, sodass der Datenbankindex die Hauptarbeit übernimmt.

Bei Header/Detail-Formularen mit mehreren Tabs ist das Laden von Datensätzen aus untergeordneten Tabellen für alle Tabs während des ersten Öffnens eine unnötige Performance-Last. In einer Standard-F4211- oder F4311-Eingabemaske inspiziert ein Benutzer sekundäre Tabs möglicherweise nur in einem kleinen Bruchteil der Sitzungen (typischerweise unter 15 %). Die Implementierung von bedingtem Abrufen – bei dem detaillierte Lesevorgänge gegen Tabellen wie F42119 nur ausgelöst werden, wenn der Benutzer auf eine bestimmte Tab-Seite klickt – reduziert den initialen SQL-Ausführungs-Overhead auf eine einzige, leichtgewichtige Abfrage.

Refactoring eines Beispiels für Custom APPL Table I/O

Ich habe kürzlich eine benutzerdefinierte F4211-Abfrageanwendung für offene Aufträge geprüft, bei der Benutzer jedes Mal eine schmerzhafte Verzögerung erlebten, wenn sie das Suchformular öffneten. Die Ursache war ein klassisches JDE-Anti-Pattern: Der Entwickler hatte eine manuelle Select/Fetch Next-Schleife in das Dialog Is Initialized-Event platziert, um Kundennamen aus dem Address Book Master (F0101) und Steuererklärungscodes aus den Address Book Phone Numbers (F0116) für jeden Verkaufsauftrag im System abzurufen, noch bevor das Grid überhaupt gerendert wurde. Dieses prozedurale Datenbank-Dreschen umgeht die Effizienz der EnterpriseOne-Middleware vollständig.

Um dies zu beheben, haben wir das prozedurale Table I/O aus den Event Rules entfernt und den primären Business ViewEine Definition in JDE, die festlegt, welche Datenbanktabellen und Felder in einer Anwendung verknüpft werden. der Anwendung überarbeitet. Durch das Ersetzen des flachen F4211-Views durch einen einfachen Left Outer Join zwischen F4211 und F0101/F0116 übernimmt die Datenbank-Engine den relationalen Join in einer einzigen SQL-Operation. Dieser Designwechsel delegiert die Schwerstarbeit an den Datenbank-Query-Optimizer und eliminiert hunderte von einzelnen Netzwerk-Roundtrips zwischen dem HTML-Server, dem Enterprise Server und dem Datenbankserver.

Wenn ein komplexer Tabellen-Join aufgrund von datenquellenübergreifenden Mappings oder volatiler benutzerdefinierter Geschäftslogik nicht machbar ist, besteht der korrekte Fallback darin, das Table I/O in das Event Grid Record is Fetched zu verschieben. Im Gegensatz zu Initialisierungs-Events, die den gesamten Datensatz vorab verarbeiten, wird dieses Event "lazy" ausgeführt und feuert nur für die Zeilen, die aktuell auf dem Bildschirm sichtbar sind. Wenn Ihre Grid-Seitengröße auf die standardmäßigen 50 Datensätze eingestellt ist, führt JDE genau 50 Abrufe aus, anstatt die gesamte F4211-Tabelle zu scannen.

Die Anwendung dieses Refactoring-Musters auf das F4211-Abfrageformular lieferte sofortige, messbare Ergebnisse. Die initiale Ladezeit des Formulars sank von trägen sechs plus Sekunden auf unter eine halbe Sekunde für eine Standard-Grid-Seite mit 50 Zeilen. Diese einfache Änderung reduziert die Auslastung des Datenbank-Thread-Pools auf Ihrem Enterprise Server drastisch und gibt Ressourcen für gleichzeitige interaktive Benutzer über die HTML-Instanz hinweg frei.

Optimierung des Grid-Ladens und virtuelle Tabellen

Entwickler übersehen häufig die Grid-Eigenschaft "Page-at-a-Time", was dazu führt, dass APPLs versuchen, zehntausende von Datensätzen aus der F4211 beim ersten Start in den Speicher des HTML-Webservers zu laden. Die Aktivierung der Page-at-a-Time-Verarbeitung begrenzt den initialen Datenbankabruf auf die Grid-Seitengröße – typischerweise 10 bis 20 Zeilen – und fragt nachfolgende Datensätze erst ab, wenn der Benutzer auf die Schaltfläche "Next" klickt. Diese einzige Eigenschaftsänderung stabilisiert sofort die JVM-Speichernutzung auf Ihren WebLogic- oder WebSphere-Instanzen während der morgendlichen Spitzenzeiten.

Standard-JDE-Business-Views scheitern, wenn Sie komplexe Multi-Tabellen-Joins, Union-Abfragen oder Aggregationen über Tabellen wie F4101, F41021 und F4102 hinweg benötigen. Anstatt verschachtelte Table I/O-Anweisungen innerhalb des Grid Record is Fetched-Events zu schreiben, um diese Felder aufzulösen, sollten Sie einen nativen Datenbank-View auf SQL Server- oder Oracle Database-Ebene erstellen und diesen als virtuelle JDE-Tabelle über die Object Management Workbench (OMW)Das zentrale Werkzeug in JD Edwards zur Verwaltung von Entwicklungsobjekten, Code-Änderungen und deren Lebenszyklus. mappen. Diese virtuelle Tabelle ermöglicht es der JDE-Datenbank-Middleware, ein einziges, hochoptimiertes SQL-Statement auszuführen, anstatt den JAS-Server zu zwingen, mehrere sequenzielle Table I/O-Operationen zu koordinieren.

Die Konsolidierung Ihrer Datenzugriffsschicht in einer virtuellen Tabelle reduziert die Datenbank-Roundtrips bei transaktionsintensiven Bildschirmen wie benutzerdefinierten Verkaufsauftragserfassungen oder Bestandsabfrage-APPLs um 80 % bis 90 %. In einem kürzlich durchgeführten Projekt reduzierte das Ersetzen mehrerer verschachtelter Table I/O-Abfragen in F41021 und F4105 durch eine einzige virtuelle Tabelle die Ladezeit eines benutzerdefinierten Abfragebildschirms von über acht Sekunden auf unter eine halbe Sekunde. Dieser Ansatz verlagert die Schwerstarbeit des Indizierens und Joinens auf die Datenbank-Engine, wo sie hingehört, und hält Ihre EnterpriseOne-Logik-Engine sauber und reaktionsschnell.

Profiling von Formular-Ladevorgängen mit dem Server Manager

Das Beheben einer mehrsekündigen Verzögerung beim Laden von Formularen erfordert mehr als nur Vermutungen; es erfordert den Blick in die jdedebug.log-Datei. Dieses Log ist Ihr primäres Diagnosetool, um genau die Table I/O-Anweisungen zu identifizieren, die die Benutzeroberfläche blockieren. Durch das Initiieren eines CallObject Kernel-Trace im Server ManagerEin webbasiertes Administrations-Tool zur Verwaltung, Überwachung und Konfiguration der JD Edwards EnterpriseOne Server-Infrastruktur. können Sie die exakte Millisekundendauer jedes SQL-Statements erfassen, das während der Events Dialog is Initialized und Post Dialog is Initialized ausgeführt wird. Dieses Echtzeit-Tracking deckt den Verarbeitungs-Overhead von benutzerdefinierten Business Functions auf, noch bevor das Formular auf dem Bildschirm des Benutzers erscheint.

Achten Sie bei der Analyse des Trace auf wiederholte Muster wie SELECT ... FROM PRODDTA.F0101 oder PRODDTA.F4101, die innerhalb derselben Sekunde auftreten und jeweils unterschiedliche Adressbuch- oder Artikelnummern abfragen. Dieses Muster deutet auf eine Schleife hin, die Table I/O zeilenweise für ein Grid ausführt, anstatt einen einzigen mengenbasierten Abruf oder einen Datenbank-View zu verwenden. Das Eliminieren dieser iterativen SQL-Aufrufe kann eine Datenbankverzögerung von einer halben Sekunde sofort auf wenige Millisekunden komprimieren und die im CallObject Kernel verbrachte Zeit drastisch reduzieren.

Sobald Sie die fehlerhaften Events überarbeitet haben, müssen Sie diese Gewinne vor Ihrem nächsten Tools ReleaseDie zugrunde liegende Systemsoftware von JD Edwards, die technische Funktionen unabhängig von den Geschäftsanwendungen bereitstellt.-Upgrade absichern. Verwenden Sie die Performance Monitor-Anwendung (P980060), um eine klare Baseline für die Transaktionsverarbeitung Ihrer kritischen interaktiven Anwendungen zu erstellen. Der Vergleich dieser Metriken vor und nach dem Upgrade verhindert Regressionen und stellt sicher, dass ein Tools-Update auf 9.2.8 oder höher nicht stillschweigend Latenzen durch geändertes Middleware-Verhalten oder Datenbanktreiber-Änderungen wieder einführt. Führen Sie diese Benchmark-Tests unter einer simulierten Last von 50 gleichzeitigen Benutzern durch, um die Stabilität Ihrer Modifikationen zu verifizieren.

Wenn Sie Legacy-APPL-Code überarbeiten, um die Performance-Standards von 9.2.8 zu erfüllen, bieten unsere anderen technischen Leitfäden zum BSFNBusiness Functions sind in C oder Java geschriebene Programmeinheiten, die komplexe Geschäftslogik in JDE ausführen.-Cache-Management und zu AIS-basierten Form Extensions tiefere Einblicke in die Optimierung von EnterpriseOne-Umgebungen.