Wenn eine benutzerdefinierte interaktive Anwendung (APPLEine interaktive Anwendung innerhalb von JD Edwards EnterpriseOne.) in JDE EnterpriseOne 9.2 mehrere Sekunden benötigt, um ein GridEin tabellenähnliches Element in der Benutzeroberfläche zur Anzeige von Datenzeilen. zu laden, geben Entwickler oft der Datenbank-Hardware oder der Netzwerklatenz die Schuld. In den allermeisten Fällen ist jedoch ein schlecht konstruierter Join in einer benutzerdefinierten Business View (BSVW)Ein Objekt, das festlegt, welche Tabellen und Felder eine Anwendung aus der Datenbank abruft., die in der Form Design Aid (FDA)Das grafische Entwicklungswerkzeug zum Erstellen von JD Edwards Anwendungen. definiert wurde, der Übeltäter. Die Beherrschung der JDE APPL Custom Business View Nutzung zur Vermeidung schlechter Joins ist entscheidend, um zu verhindern, dass die Datenbank unkontrollierte Nested LoopsEine Datenbank-Abfragemethode, die bei fehlenden Indizes sehr zeitaufwendig sein kann. über Millionen von Zeilen in Tabellen wie F0911 oder F4211 ausführt.
Die JDE-Runtime-Engine verarbeitet Tabellen-Joins anders als ein nativer SQL-Client. Ein einziger falscher Outer JoinEine Tabellenverknüpfung, die alle Datensätze einer Seite einschließt, auch wenn keine passenden Daten in der anderen Tabelle existieren. zwischen einer schweren Transaktionstabelle wie F4111 und einer benutzerdefinierten Lookup-Tabelle kann Datenbankindizes vollständig umgehen und Full Table ScansEin ineffizienter Suchvorgang, bei dem die Datenbank jede Zeile einer Tabelle einzeln prüfen muss. während des Events "Grid Record is Fetched" auslösen. Um Antwortzeiten im Sub-Sekunden-Bereich beizubehalten, müssen Entwickler BSVWs an physischen Datenbankindizes ausrichten und verstehen, wie die JDE-MiddlewareSoftware, die als Brücke zwischen verschiedenen Systemen oder Schichten wie Anwendung und Datenbank dient. diese Views in SQL übersetzt.
Die hohen Kosten des Missbrauchs von FDA Join Business Views
Das Ziehen einer Transaktionstabelle mit Millionen von Zeilen wie der F0911 in die Business View Design Aid neben eine Stammdatentabelle wie die F0101 ist eine gängige Abkürzung, die häufig die interaktive Performance verschlechtert. Wenn ein Entwickler einen Join-Key falsch zuordnet oder weglässt – zum Beispiel die Verknüpfung von GLALKY mit ABALKY zusätzlich zum primären Key GLAN8 zu ABAN8 vergisst – erzeugt die JDE-Middleware auf Datenbankebene ein partielles kartesisches ProduktEin Fehler, bei dem Tabellen so verknüpft werden, dass die Ergebnismenge unkontrolliert anschwillt.. Dieser Fehler umgeht Standard-Datenbankoptimierungen und führt dazu, dass der Enterprise-Datenbankserver den Speicher überlastet, während er versucht, Millionen von nicht indizierten Permutationen aufzulösen, bevor er die erste Grid-Zeile an den HTML-Server zurückgibt.
Die Datenbank-Middleware von JDE übersetzt Outer Joins je nach zugrunde liegender Plattform unterschiedlich, was ein stilles Risiko für hybride oder migrierende Architekturen darstellt. Ein in der Business View Design Aid konfigurierter Outer Join kann auf einer Oracle-Datenbank mit nativer ANSI-Syntax einwandfrei ausgeführt werden, sich jedoch auf dem MS SQL Server unvorhersehbar verhalten, was zu fehlenden Datensätzen oder abgeschnittenen Grids während einer Plattformmigration führt. Diese plattformspezifischen SQL-Übersetzungen umgehen oft den JDE-Datenbank-CacheEin Zwischenspeicher, der häufig benötigte Daten vorhält, um langsame Datenbankzugriffe zu reduzieren. vollständig und erzwingen direkte Datenbankzugriffe bei jeder einzelnen Scroll-Aktion auf dem Ziel-Find/Browse-Formular.
Wenn ein Find/Browse-Formular auf einem schlecht konzipierten Multi-Tabellen-Join basiert, bricht die Datenbank-Engine oft Index-Range-Scans auf massiven Transaktionstabellen wie der F4211 ab und entscheidet sich stattdessen für einen Full Table Scan. Dies blockiert tempdb-Ressourcen und treibt die CPU-Auslastung auf nahezu volle Kapazität, nur um einen einfachen Suchbildschirm darzustellen. Um dies zu verhindern, müssen Entwickler benutzerdefinierte Business Views auf einfache Primärschlüssel-Joins beschränken und komplexe relationale Abfragen in C-basierte Business Functions oder über virtuelle Tabellen gemappte Datenbank-Views auslagern.
Inner vs. Outer Joins in JDE Business Views
Ich habe kürzlich eine benutzerdefinierte Verkaufsabfrage-APPL analysiert, bei der sich Benutzer beschwerten, dass die Hälfte ihrer offenen Verkaufsauftragszeilen aus dem Grid verschwunden war. Der Entwickler hatte eine benutzerdefinierte BSVW erstellt, die die Sales Order Detail Tabelle (F4211) mit der Sales Order Header Tabelle (F4201) über einen Inner JoinEine Verknüpfung, die nur Ergebnisse liefert, wenn in beiden Tabellen ein passender Datensatz gefunden wird. verband. Da ein veraltetes Datenbereinigungsprogramm mehrere ältere F4211-Zeilen verwaist hatte, indem es die entsprechenden F4201-Header-Datensätze löschte, unterdrückte die JDE-Datenbank-Middleware diese Detailzeilen vollständig. Ein Inner Join in einer BSVW, die in einer interaktiven Anwendung verwendet wird, verbirgt übergeordnete Datensätze vollständig, wenn in der untergeordneten Tabelle eine entsprechende Zeile fehlt, was zu sofortigen Beschwerden über fehlende Daten führt.
Den Join-Typ in der Business View Design Aid auf einen Left Outer Join umzustellen, mag wie die offensichtliche schnelle Lösung erscheinen, bringt aber andere Laufzeitprobleme mit sich. Wenn keine passenden Datensätze in der Sekundärtabelle vorhanden sind – wie ein fehlender F4201-Datensatz für eine verwaiste F4211-Zeile – führen Left Outer Joins in JDE Business Views dazu, dass Grid-Spalten, die der Sekundärtabelle zugeordnet sind, leer, null oder fehlerhafte Werte anzeigen. In einer Produktionsumgebung mit Millionen von Zeilen umgehen diese leeren Felder die Validierungslogik der Anwendung, was oft zu nachfolgenden Speicherverletzungen oder ungültigen Parametern führt, die an nachgelagerte Business Functions wie B4200310 übergeben werden.
Die JDE-Runtime-Engine führt für jeden Grid-Fetch ein SELECT-Statement aus, was bedeutet, dass ein schlechter Outer Join die Latenz exponentiell vervielfacht, während der Benutzer durch das Grid scrollt. Wenn Ihre Grid-Seitengröße auf einen Standard-Batch von Datensätzen eingestellt ist, erzwingt ein schlecht indizierter Outer Join zahlreiche Nested-Loop-Lookups durch die Datenbank-Engine, wodurch eine Sub-Sekunden-Page-Down-Aktion zu einer spürbaren Verzögerung wird. Die Standard-JDE-Praxis schreibt vor, Inner Joins nur dann zu verwenden, wenn eine strikte 1:1- oder 1:n-Beziehung durch die referenzielle Integrität der Datenbank garantiert ist, wie z. B. das Verbinden von F4211 mit F42119 für historische Zeilen, oder wenn die Geschäftslogik das Anzeigen eines Datensatzes ohne sein übergeordnetes Element absolut verbietet.
Umgang mit benutzerdefinierten Spalten und Tabellenerweiterungen
Entwickler versuchen häufig, Standardanwendungen wie den Item Master (P4101) zu erweitern, indem sie eine benutzerdefinierte Business View erstellen, die die Standardtabelle F4101 mit einer benutzerdefinierten 55er-Tabelle wie F554101 verbindet. Während dieser Ansatz in der Form Design Aid (FDA) sauber erscheint, da er alle Felder in einem einzigen Grid anzeigt, führt er zu schwerwiegenden Einschränkungen bei Updates. In einer Multi-Tabellen-Business-View legt EnterpriseOne nur eine Tabelle als primäre, aktualisierbare Tabelle fest. Wenn Sie versuchen, Felder, die zur sekundären Tabelle F554101 gehören, direkt über Standard-FDA-Formularsteuerelemente zu aktualisieren, wird die Runtime-Engine diese sekundären Änderungen stillschweigend nicht in die Datenbank schreiben, ohne einen Fehler auszugeben.
Dieses Multi-Tabellen-Join-Design blockiert auch Standard-JDE-Tabellen-Trigger auf der Sekundärtabelle, da die Middleware den Update-Kontext nicht richtig erkennt. Wenn Sie benutzerdefinierte Table Event Rules (TER) auf der F554101 haben, um benutzerdefinierte Bestandsmetriken zu berechnen, werden diese Trigger während eines Standard-Formularspeichervorgangs nicht ausgeführt. Datenbank-Sperren (Locks) treten häufig auf, wenn das JDE-Toolset versucht, gleichzeitige Updates über eine verbundene View bei hohem Transaktionsvolumen aufzulösen, insbesondere in Umgebungen, die hunderte von gleichzeitigen Lager-Sessions unterstützen.
Um diese Sperr- und Update-Anomalien zu verhindern, müssen Sie Ihre Transaktionspfade isolieren. Das empfohlene Muster besteht darin, die primäre Business View der Anwendung auf die Standardtabelle zu beschränken und benutzerdefinierte Spalten über explizite Table I/ODatenbankbefehle innerhalb der JD Edwards Programmierumgebung zum Lesen oder Schreiben von Daten. zu verarbeiten. Verwenden Sie ein Fetch Single Statement oder eine benutzerdefinierte Named Event Rule (NER) im Event 'Grid Record is Fetched' des Grids, um die benutzerdefinierten 55/56-Felder zu füllen. Führen Sie für Updates explizite Table I/O Update-Statements aus oder rufen Sie eine dedizierte BSFN im Event 'Row Is Exit & Changed - Asynch' auf, um saubere Transaktionsgrenzen zu gewährleisten und die Ausführung von Standard-JDE-Triggern zu erhalten.
Grid-Performance und die Falle "Grid Record is Fetched"
Ich auditiere regelmäßig interaktive Anwendungen, bei denen Entwickler, die Schwierigkeiten haben, einen komplexen Multi-Tabellen-Join in einer Business View zu konfigurieren, auf die Form Design Aid (FDA) ausweichen und manuelle Table I/O innerhalb des Events Grid Record is Fetched schreiben. Dieser Wechsel von deklarativem Datenbankdesign zu prozeduralen Event Rules (ER) führt zum klassischen N+1-AbfragemusterEin Effizienzproblem, bei dem eine Hauptabfrage viele kleine Folgeabfragen auslöst, was das System verlangsamt.. Für ein Standard-Grid, das Dutzende von Zeilen anzeigt, führt ein einziges manuelles Fetch Single Statement in diesem Event Dutzende von separaten, sequenziellen Datenbank-Roundtrips aus. Was eine Ladezeit im Sub-Sekunden-Bereich sein sollte, verschlechtert sich schnell auf mehrere Sekunden, insbesondere über WAN- oder Cloud-Verbindungen mit hoher Latenz zum Datenbankserver.
Die Lösung dieser Latenz erfordert die Rückverlagerung der Schwerstarbeit auf die Datenbank oder die Middleware-Schicht. Die Verwendung einer ordnungsgemäß indizierten, nicht verbundenen Business View in Kombination mit den nativen Grid-Caching-Mechanismen von JDE wird jede prozedurale ER-Schleife konsistent übertreffen. Wenn der HTML-Server den Datenabruf übernimmt, kann er Blöcke von Datensätzen (oft über die Einstellung PageSize in der jas.ini konfiguriert, typischerweise auf 10 oder 20 Zeilen eingestellt) in einer einzigen Datenbank operation abrufen und cachen. Wenn der EnterpriseOne-Kernel gezwungen wird, einzelne SQL-Statements für jede einzelne Zeile auszuführen, werden diese Middleware-Optimierungen vollständig umgangen.
Wenn Sie Hilfsspalten aus Sekundärtabellen wie F0116 oder F0115 anzeigen müssen, die nicht sauber in der primären View verbunden werden können, vermeiden Sie Table I/O in den Grid-Events gänzlich. Laden Sie stattdessen diese Cross-Reference-Werte während des Events 'Dialog Is Initialized' in einen benutzerdefinierten JDE-Cache (unter Verwendung der APIs jdeCacheAdd und jdeCacheFind innerhalb einer C-Business-Function) oder rufen Sie sie über einen einzigen Bulk-Business-Function-Aufruf (BSFN) ab. Das Abrufen von Dutzenden von Datensätzen aus einem In-Memory-Cache dauert Mikrosekunden, während Dutzende von Datenbank-SELECT-Statements für den Endbenutzer ein spürbares Ruckeln des Bildschirms auslösen.
Auswirkungen von benutzerdefinierten BSVWs auf Upgrades und Retrofits
Während eines Upgrades von 9.1 auf 9.2 markiert der Specification Merge (insbesondere R98700) jede benutzerdefinierte Business View, die eine JDE-Standardtabelle modifiziert oder erweitert. Dies führt zu sofortigen manuellen Retrofit-Engpässen für das Entwicklungsteam, das die Unterschiede zwischen den 9.1-Quellspezifikationen und den neuen 9.2-Zentralobjekten abgleichen muss. Wenn ein Entwickler eine Standard-Business-View wie V4211A modifiziert hat, um einen benutzerdefinierten Join hinzuzufügen, anstatt eine neue 55er-View zu erstellen, scheitert die Merge-Engine oft daran, das Delta aufzulösen, was einen manuellen Neuaufbau von Grund auf erzwingt.
Technische Schulden summieren sich, wenn Oracle in späteren Tools Releases, wie der 9.2.8.x-Linie, oder durch kumulative Application Updates Änderungen am Tabellenschema einführt. Wenn eine Standardtabelle wie F4101 oder F4211 eine strukturelle Änderung erfährt – selbst eine geringfügige Indexmodifikation oder eine Feldlängenerweiterung – kann jede benutzerdefinierte Business View, die auf diese Tabellen verweist, sofort ungültig werden. Während des anschließenden Full Package Builds auf dem Enterprise-Server wirft der Compiler fatale Fehler (wie Link-Fehler im generierten Business-Function-Code) aus, was die Deployment-Pipeline stoppt, bis die View-Spezifikationen in OWM regeneriert und validiert wurden.
Das Ersetzen einer Standard-Business-View durch eine benutzerdefinierte verbundene View innerhalb einer Standardanwendung wie P4210 oder P4310 bricht Oracles Continuous-Delivery-Modell vollständig. Wenn ein kritisches ESU die P4210 aktualisiert, überschreibt der automatisierte Software-Update-Prozess die Anwendungsspezifikationen, löscht Ihre benutzerdefinierte View-Zuweisung und zwingt Entwickler dazu, den Code manuell zusammenzuführen. Die Isolierung benutzerdefinierter Joins strikt innerhalb benutzerdefinierter 55er- oder 56er-Anwendungen stellt sicher, dass die Object Management Workbench Ihre spezifische Geschäftslogik bei Updates beibehält, wodurch Ihr Kern-ERP stabil und leicht patchbar bleibt.
Architekturstandards für sauberen APPL-Datenabruf
Die Beschränkung von Business Views in interaktiven Anwendungen auf maximal ein oder zwei verbundene Tabellen verhindert, dass die JDE-Middleware ausuferndes SQL erzeugt. Wenn eine Anforderung Daten aus mehreren Tabellen erfordert – wie das Verbinden von F0101, F0116 und F0115 – erstellen Sie keinen Multi-Tabellen-Join in der FDA. Rufen Sie den Hilfsdatensatz über eine benutzerdefinierte C-Business-Function (BSFN) ab oder mappen eine virtuelle Datenbank-View, die direkt in der Oracle-Datenbank definiert ist. Dies hält den primären Datenbankabruf leichtgewichtig und verhindert Anwendungsverzögerungen.
Datenbank-Optimizer scheitern, wenn Join-Spalten in einer benutzerdefinierten BSVW vom Primärschlüssel-Index der Zieltabellen abweichen. Das Verbinden von F4211 mit F4101 über ein Nicht-Key-Feld zwingt die Datenbank-Engine zu einem Full Table Scan anstelle eines Index Seek. Stellen Sie sicher, dass jede Join-Konfiguration in Ihrer Business View strikt den primären eindeutigen Index der verbundenen Tabelle widerspiegelt, um die Antwortzeiten unter ein paar hundert Millisekunden zu halten.
EnterpriseOne Tools Release 9.2.x bietet einen saubereren Weg, um Hilfsdaten anzuzeigen, ohne die zugrunde liegende BSVW zu berühren oder Event Rules zu schreiben. Verwenden Sie Form Extensions, um eine OrchestrationEin modernes Werkzeug zur Automatisierung von Prozessen und zur Integration von Drittsystemen in JD Edwards. aufzurufen, die sekundäre Daten abruft und diese direkt einem Feld auf dem Bildschirm zuordnet. Dies eliminiert die Notwendigkeit, native Business Views wie V4211A anzupassen, was den Retrofit-Aufwand bei Tools-Upgrades um 60 % bis 80 % reduziert.
Bringen Sie niemals eine neue Business View in die Produktion, ohne das von der JDE-Middleware generierte rohe SQL-Statement zu verifizieren. Führen Sie die Anwendung in Ihrem DV HTML-Client mit aktivem JDEDEBUG.log aus, suchen Sie das exakte SELECT-Statement und lassen Sie es durch einen Datenbank-Profiler laufen. Wenn Sie einen Nested Loop Join sehen, der Millionen von Zeilen aufgrund eines fehlenden Index-Mappings scannt, können Sie dies abfangen, bevor es Tabellen in der Produktion sperrt.
Wenn Sie Ihre EnterpriseOne-Entwicklungsstandards verfeinern, bietet unsere technische Bibliothek detaillierte Blueprints und Optimierungsskripte, um Ihr Design benutzerdefinierter Objekte zu rationalisieren.
