Wenn eine Batch-QueueEine Warteschlange auf dem Server, in der Hintergrundprozesse (Batch-Jobs) nacheinander oder parallel abgearbeitet werden. auf dem Enterprise ServerDer zentrale Server, der die Geschäftslogik und Batch-Prozesse der JD Edwards-Anwendung ausführt. um 2:00 Uhr morgens blockiert, ist die erste Reaktion vieler Teams, die maximale Anzahl gleichzeitiger Jobs in der JDE-Umgebungskonfiguration zu erhöhen. In neun von zehn Fällen ist das eine Fehldiagnose. Der tatsächliche Engpass ist fast immer ein fehlerhaftes Report Design Aid (RDA)Das Entwicklungswerkzeug innerhalb von JD Edwards, mit dem Berichte und Batch-Prozesse (UBEs) erstellt und gestaltet werden. Layout, das Millionen von nicht indizierten Datenbank-Abfragen ausführt. Die Verknüpfung des F4111 Item LedgerEine zentrale JD Edwards-Datenbanktabelle, die alle Lagerbewegungen und Artikeltransaktionen historisch erfasst. mit dem F0911 General LedgerDie Hauptbuchtabelle in JD Edwards, in der alle Finanztransaktionen und Buchungszeilen gespeichert werden. in einem einzigen benutzerdefinierten Business ViewEine logische Sicht auf eine oder mehrere Datenbanktabellen, die in JD Edwards für Berichte und Anwendungen verwendet wird. ohne strikte Index-Abstimmung verwandelt einen Batch-Lauf, der eigentlich 90 Sekunden dauern sollte, in eine 4-stündige Queue-Blockade.
Die Beherrschung des JDE UBE Custom Report Designs zur Vermeidung lang laufender Jobs erfordert die Behebung der zugrunde liegenden Event RulesDie integrierte, ereignisgesteuerte Programmiersprache von JD Edwards zur Definition von Geschäftslogik. Logik, lange bevor der Code Ihre Package Build PipelineDer automatisierte Prozess, der geänderten Programmcode kompiliert, paketiert und für die verschiedenen Umgebungen bereitstellt. erreicht. Das Verschieben von I/O-Operationen auf Zeilenebene aus der Do SectionEin Ereignisbereich in JD Edwards-Berichten, der für jeden gelesenen Datensatz der Haupttabelle einmal ausgeführt wird., das Entfernen nicht benötigter Tabellenspalten aus Business Views und die ordnungsgemäße Freigabe von C BSFN Memory HandlesSpeicherzeiger für in der Programmiersprache C geschriebene Geschäftsfunktionen (Business Functions) in JD Edwards. reduziert die UBE-Verarbeitungszeiten regelmäßig um 80 % bis 95 %. Hier ist die technische Audit-Checkliste, die Sie für benutzerdefinierte Berichte durchgehen sollten, bevor Sie diese aus dem Development (DV) PathcodeEine spezifische Umgebung oder ein Verzeichnis in JD Edwards, das eine bestimmte Version des Quellcodes enthält. hochstufen.
Business Views optimieren, um den Query-Footprint zu reduzieren
Entwickler greifen routinemäßig auf Standard-Business-Views wie V0911A zurück oder erstellen benutzerdefinierte Views, die alle über 120 Spalten des F0911 Account Ledger zusammen mit dem F0006 Business Unit Master selektieren (SELECT). Bei der Verarbeitung von 5 Millionen Transaktionsdatensätzen beeinträchtigt das Übertragen von F0911.GLPOST, F0911.GLALT1 und Dutzenden ungenutzter Audit-Felder über das Netzwerk die Speicherleistung auf dem Enterprise Server und überlastet die Netzwerkschnittstelle der Datenbank. JDE generiert SQL mit einer expliziten Spaltenliste basierend auf der BSVW-Definition, aber eine View mit über 100 Feldern über zwei Tabellen hinweg bläht die Speicherallokation für jeden Zeilenpuffer in der UBE-Runtime immer noch auf.
Der Leistungsabfall verschlimmert sich, wenn Entwickler Left Outer JoinsEine SQL-Abfragemethode, die alle Zeilen der linken Tabelle und die passenden Zeilen der rechten Tabelle verknüpft. zwischen F0911 und sekundären Tabellen wie F0006 oder F4111 unter Verwendung von nicht indizierten Primärschlüsselkombinationen oder ungenauen Join-Kriterien konfigurieren. Das Verknüpfen über nicht indizierte Felder zwingt den Query-Optimizer der Datenbank zu einem Full Table ScanEin zeitaufwendiger Suchvorgang, bei dem die Datenbank jede einzelne Zeile einer Tabelle durchsuchen muss, da kein passender Index existiert. oder einem kostenintensiven Hash JoinEine Methode der Datenbank, um zwei Tabellen über eine temporäre Hash-Tabelle im Arbeitsspeicher effizient miteinander zu verknüpfen. über Millionen von Datensätzen, wodurch der zusammengesetzte Index F0911_1 (GLDCT, GLDOC, GLKCO, GLDGJ, GLJEL) vollständig umgangen wird. Auf einer Oracle Database 19c Instanz verlängert eine so strukturierte Abfrage die UBE-Ausführungszeit regelmäßig von unter einer Minute auf weit über zwei Stunden.
Erstellen Sie eine dedizierte, minimale Business View in der Object Management Workbench (OMW)Das zentrale Entwicklungswerkzeug in JD Edwards zur Erstellung, Änderung und Verwaltung von Softwareobjekten., die nur die genauen Primärschlüssel und Zielfelder enthält, die für die Filterung oder Verarbeitung benötigt werden. Wenn Ihr Bericht nur GLAID, GLAA und GLDGJ aus der F0911 benötigt, um Hauptbuchsalden zu berechnen, schließen Sie alle anderen Spalten aus der View aus. Das Reduzieren einer View von 120 Feldern auf 10 verringert den SQL-Netzwerk-Payload pro Zeile um etwa drei Viertel und ermöglicht es der Datenbank, Indexblöcke während der Batch-Ausführung weitaus effizienter im Cache zu halten.
Data Selection und Indizes für sofortige Abfragen aufeinander abstimmen
Wenn Sie eine Abfrage auf eine F4111 Item Ledger Tabelle mit 10 Millionen Zeilen absetzen, ohne die führenden Spalten eines Index zu berücksichtigen, weicht der Datenbank-Optimizer auf einen Full Table Scan oder einen teuren Index Skip Scan aus. Benutzerdefinierte Bestandsberichte filtern häufig nach dem Transaktionsdatum (ILGLDATE) und der Filiale/dem Werk (ILMCU), lassen jedoch die Artikelnummer (ILITM) weg, was die Laufzeit von wenigen Sekunden auf bis zu 45 Minuten ansteigen lässt. Die RDA Data SelectionDie Filterkriterien in JD Edwards, die festlegen, welche Datensätze aus der Datenbank für einen Bericht abgerufen werden. muss strikt der Spaltenreihenfolge eines Indexschlüssels von links nach rechts entsprechen, damit der Datenbank-Optimizer einen direkten Index Range ScanEin schneller Datenbankzugriff, bei dem nur ein bestimmter Wertebereich eines Index gezielt durchsucht wird. ausführen kann, anstatt Millionen von nicht indizierten Blöcken zu parsen.
Vergleichsoperatoren in Report Design Aid bestimmen, ob die Datenbank-Engine einen Index verwendet oder Datensätze Zeile für Zeile auswertet. Die Verwendung von Kriterien wie NOT EQUAL TO, CONTAINS oder WILD CARD in der RDA Data Selection unterdrückt die Indexoptimierung, indem sie Full Scans auf der Zieltabelle erzwingt. Beim Abfragen von Tabellen mit hohem Datenvolumen wie F4111 oder F4011 reduziert das Ersetzen eines NOT EQUAL TO-Operators für die Belegart (ILDOTY) durch eine explizite Positivliste – oder das Filtern unerwünschter Belegarten in den Event Rules nach dem Abrufen des Datensatzes – die I/O-Wartezeiten der Datenbank auf Oracle oder SQL Server häufig um 80 % bis 90 %.
Dynamische Sortierung zur Laufzeit ist ein weiterer stiller Killer der Batch-Ausführung. Wenn eine Event Rule oder ein Berichtsabschnitt ein Data SequencingDie Definition der Sortierreihenfolge für die abzurufenden Datensätze in einem JD Edwards-Bericht. definiert, das nicht mit einem aktiven Datenbankindex übereinstimmt, fügt EnterpriseOneDer offizielle Name der modernen, webbasierten ERP-Software-Suite von JD Edwards (Oracle). eine ORDER BY-Klausel hinzu, die die Datenbank zwingt, Zwischenergebnisse in temporäre TablespacesLogische Speicherbereiche in einer Datenbank, in denen die physischen Daten von Tabellen und Indizes organisiert werden. zu schreiben, bevor die erste Zeile zurückgegeben wird. Das Erstellen eines gezielten benutzerdefinierten Tabellenindex in der Object Management Workbench (OMW), der genau zu Ihrer RDA Data Selection und Ihrem erforderlichen Data Sequencing-Layout passt, eliminiert den Sortier-Overhead zur Laufzeit und ermöglicht es der UBE-EngineDie Universal Batch Engine, die in JD Edwards für die Ausführung von Hintergrundprozessen und Berichten zuständig ist., vorsortierte Datensätze sofort zu streamen.
Ineffiziente ER-Logik und Klausel-Fallen eliminieren
Das Filtern von Datensätzen mittels Event Rules Logik in der Do Section zwingt den Enterprise Server, jeden einzelnen Datensatz von der Datenbankebene abzurufen, bevor er ausgewertet wird. Wenn ein Transaktionsdetailbericht 500.000 nicht übereinstimmende Zeilen im F4111 Cardex scannt und diese mithilfe der Systemfunktion Suppress Section WriteEine Systemfunktion in JD Edwards, die das Drucken oder Schreiben eines Berichtsabschnitts verhindert. innerhalb eines ER-IF/ELSE-Blocks unterdrückt, zahlen Sie dennoch die volle Strafe für DB-Puffer und Netzwerklatenz für alle 500.000 Zeilen. Die Datenbank-Engine bleibt für Ihre Bewertungskriterien völlig blind und streamt Gigabytes über das Netzwerk, nur damit die JDE-Runtime sie Zeile für Zeile verwirft.
Verlagern Sie diese Filterlogik in die SQL-Engine, indem Sie Set User SelectionEine Systemfunktion in JD Edwards, mit der die Filterbedingungen (WHERE-Klausel) einer Datenbankabfrage dynamisch per Code angepasst werden. in der Initialize SectionEin Ereignisbereich in JD Edwards-Berichten, der einmalig vor dem eigentlichen Datenabruf zur Initialisierung ausgeführt wird. aufrufen. Systemfunktionen, die während der Initialisierung ausgeführt werden, übersetzen sich direkt in SQL-WHERE-Klausel-Prädikate im initialen Query-Payload, der an die Oracle Database oder den SQL Server gesendet wird. Die Auswertung von Bedingungen auf Datenbankebene ermöglicht es dem Query-Optimizer, vorhandene zusammengesetzte Indizes zu nutzen, wodurch nur die 20.000 relevanten Zeilen an den Enterprise Server zurückgegeben werden und über 90 % des Netzwerk- und Speicher-Overheads sofort entfallen.
Gehen Sie präzise mit dynamischer User-Selection-Logik um, um ein Aufstauen von Klauseln (Clause StackingDas unbeabsichtigte, mehrfache Aneinanderreihen von Filterbedingungen in einer SQL-Abfrage, was die Datenbankleistung massiv beeinträchtigen kann.) zu verhindern. Das wiederholte Aufrufen von Set User Selection über verschiedene Logikzweige hinweg, ohne das Set Selection Append Flag auf den Ersetzungsmodus (Replace Mode) einzustellen, zwingt JDE dazu, redundante Prädikate im generierten Statement aneinanderzureihen. Ein Bericht, der in einer Schleife läuft und kontinuierlich AND-Klauseln anhängt, kann leicht eine 2.000 Zeichen lange WHERE-Klausel mit redundanten Bedingungen konstruieren, was den Datenbank-Optimizer verwirrt und eine ansonsten sofortige Indexabfrage in einen mehrstündigen Batch-Engpass verwandelt.
I/O-Operationen auf Zeilenebene aus der Do Section auslagern
Das Platzieren einer Table-I/O-Operation innerhalb der Do Section einer UBE ist der häufigste Fehler, der dazu führt, dass Enterprise-Batch-Berichte stunden- statt minutenlang laufen. Betrachten wir einen typischen Bestands-Transaktionsbericht, der 500.000 Datensätze in der Tabelle F4111 scannt. Wenn ein Entwickler ein explizites Fetch SingleEin Datenbankbefehl in JD Edwards, der gezielt einen einzelnen Datensatz anhand bestimmter Schlüsselwerte abruft. gegen den F4101 Item Master innerhalb der Do Section einfügt, um den Suchtext oder die Lagerart abzurufen, führt der Batch-Prozess 500.000 einzelne SQL-Abfragen über das Netzwerk aus. Jeder Roundtrip verursacht Datenbanklatenz und verwandelt eine Abfrage, die unter fünf Minuten dauern sollte, in einen mehrstündigen Batch-Job, der Ressourcen des Enterprise Servers blockiert und die Ausführungswarteschlangen der Datenbank-Threads ausbremst.
Das Zusammenführen erforderlicher Tabellenabfragen in die dem Abschnitt zugrunde liegende Business View eliminiert diese Hunderttausenden von diskreten Datenbankaufrufen sofort. Die Verknüpfung der F4101 mit der primären F4111-Tabelle auf View-Ebene verlagert die Last auf die Datenbank-Engine, die den verknüpften Datensatz über einen einzigen Datenbank-Cursor unter Verwendung vorkompilierter Ausführungspläne abruft. Wenn eine bedingte Logik einen statischen View-Join verhindert – wie z. B. optionale Cross-Reference-Abfragen –, laden Sie die Zieldaten während der Initialize Section in einen C-basierten API-SpeichercacheEin schneller Zwischenspeicher im Arbeitsspeicher, auf den über Programmierschnittstellen (APIs) zugegriffen wird. oder fragen Sie lokale Umgebungsvariablen einmal pro Level BreakEin Ereignis in JD Edwards-Berichten, das ausgelöst wird, wenn sich der Wert eines Sortierfeldes ändert (z. B. Gruppenwechsel). anstatt einmal pro Zeile ab.
Vermeiden Sie es, Event Rules zu verwenden, um manuelle Iterationsschleifen mit Select- und Fetch Next-Befehlen über Hilfstabellen wie F4074 oder F0911 während der Zeilenausführung zu konstruieren. Entwickler schreiben diese manuellen ER-Schleifen häufig, um Preisanpassungen oder Hauptbuchbeträge zu aggregieren, ohne sich bewusst zu sein, dass sie die Abfragelatenz bei jedem einzelnen Detaildatensatz vervielfachen. Konfigurieren Sie Level Break Headers und Level Break Footers, um Zwischensummen und laufende Aggregationen nativ innerhalb der UBE-Engine zu verarbeiten. Wenn Sie die Runtime ereignisgesteuerte Abschnittswechsel verarbeiten lassen, entfallen benutzerdefinierte ER-Akkumulatoren und Millionen unnötiger Table Handles bei großen Batch-Läufen werden eingespart.
Cache Handles und C Business Function Memory verwalten
Ein Enterprise-Bericht, der 100.000 Datensätze verarbeitet, schlägt stillschweigend fehl oder zieht den Enterprise Server in das Kernel-PagingDas Auslagern von aktivem Arbeitsspeicher auf die langsame Festplatte durch das Betriebssystem, was zu extremen Leistungsverlusten führt., wenn benutzerdefinierte C Business FunctionsIn der Programmiersprache C geschriebene, wiederverwendbare Geschäftslogik-Bausteine in JD Edwards für komplexe Berechnungen., die in der Do Section ausgeführt werden, ihre Cache-Pointer verwaisen lassen. Wenn Sie jdeCacheInit oder jdeCacheAddItem innerhalb einer Event Rules Schleife aufrufen, ohne nach Abschluss des Abschnitts ein entsprechendes jdeCacheTerminate oder jdeCacheFreeCursor auszuführen, skaliert der Speicherbedarf des Prozesses linear mit der Zeilenanzahl. Ein RUNBATCHDer Betriebssystem-Prozess auf dem Enterprise Server, der für die Ausführung von JD Edwards-Batch-Jobs verantwortlich ist.-Prozess, der während der Ausführung von anfänglich 40 MB auf über 3 GB anwächst, wird fast immer durch nicht freigegebene Heap-AllokationenDynamisch zugewiesener Arbeitsspeicher für Programme, der nach der Verwendung explizit wieder freigegeben werden muss. in Legacy-C-Code verursacht.
Der gleiche Speicherverlust tritt auf, wenn Entwickler Open Table System Functions oder rohe Datenbank-Handles innerhalb von Event Rules verwenden und diese nicht mit einem expliziten Close Table-Aufruf in der End Section oder im Destroy Global Bank Event paaren. Das Offenlassen eines nicht geschlossenen Table HandlesProgramminterne Zeiger oder offene Verbindungen zu einer bestimmten Datenbanktabelle. pro Iteration führt zu einem Leck von Datenbank-Cursorn auf dem Datenbankserver, während Handle-Objekte im JDE-Middleware-Speicher fixiert bleiben. Bei einem Batch-Lauf mit 250.000 Zeilen führt diese Handle-Erschöpfung routinemäßig dazu, dass der Datenbank-Verbindungspool blockiert, was parallele Jobs auf dem Enterprise Server abstürzen lässt.
Bei korrekter Verwaltung liefern In-Memory-jdeCache-Strukturen drastische Leistungssteigerungen anstelle von Speicherlecks. Das Caching statischer Validierungsdaten – wie Filial-/Werkskonstanten aus F41001 oder Cross-Reference-Datensätze – in einem globalen C-Cache-Handle während der Initialize Section eliminiert redundante I/O-Aufrufe vollständig. Der Austausch von 100.000 einzelnen SQL-SELECT-Operationen gegen Speicher-Pointer-Lookups reduziert die Latenz von Datenbankaufrufen bei Batch-Läufen mit hohem Volumen um 80 % bis 90 % und senkt die Ausführungszeiten von Stunden auf Minuten.
Pre-Flight SQL-Profiling in Debug-Logs durchführen
Stufen Sie eine benutzerdefinierte UBE niemals aus dem Development (DV) hoch, ohne während eines repräsentativen Testlaufs ein jdedebug.logDie detaillierte Protokolldatei von JD Edwards, die SQL-Statements und Programmschritte zur Fehlersuche aufzeichnet. auf Trace-Ebene zu erfassen. Das Öffnen des Logs und das Überprüfen des von der JDE-Middleware konstruierten literalen SQL-SELECT-Statements – insbesondere der WHERE-Klausel – deckt versteckte Full Table Scans auf Tabellen mit mehreren Millionen Zeilen wie F0911 oder F4111 auf, noch bevor dieser Code jemals Prototype (PY) oder Production (PD) erreicht. Entwickler nehmen häufig an, dass die UBE-Engine den in Report Design Aid (RDA) ausgewählten Index verwendet, aber komplexe Event-Rule-Data-Selection oder dynamische SQL-Overrides können Index-Constraints stillschweigend entfernen und die Datenbank-Engine zu teuren Table Scans zwingen.
Quantifizieren Sie die Leistung in DV, indem Sie Metriken zur Ausführungszeit pro 10.000 verarbeiteten Datensätzen berechnen. Das Subtrahieren des Zeitstempels des ersten FET (Fetch) API-Aufrufs vom letzten Fetch-Aufruf im Log liefert die tatsächliche Datenbankzeit im Vergleich zum Verarbeitungs-Overhead der Event Rules. Wenn die Verarbeitung von 10.000 Zeilen auf der Datenbankebene während der lokalen Ausführung der Spezifikationen länger als 1,5 bis 2,0 Sekunden dauert, ist die Indexauswahl oder die Join-Bedingung fehlerhaft. Die Behebung dieses Problems auf Workstation-Ebene kostet Minuten; die Fehlersuche bei einem laufenden Batch-Job, der F0101 oder F4211 in der Produktion blockiert, kostet Tausende an betrieblichen Auswirkungen.
Deaktivieren Sie die RDA-Rendering-EngineDie Komponente in JD Edwards, die für die visuelle Aufbereitung und Formatierung des Berichts-Layouts (z. B. PDF) zuständig ist. vollständig, wenn Sie Exportberichte entwerfen, die direkt in benutzerdefinierte Arbeitstabellen, CSVs oder Exportschnittstellen schreiben. Das Aktivieren des Systemfunktionsaufrufs „Suppress Section Writing“ für Detailabschnitte und das Kennzeichnen von Hilfsabschnitten als „Hide Section“ reduziert den Verarbeitungs-Overhead um 30 % bis 50 %. Der Enterprise Server verbraucht erhebliche CPU-Zyklen für die Formatierung von PDF-Seitenpuffern, die Auswertung von Schriftmetriken und die Berechnung von Zeilenanzahlen, selbst wenn die Batch-Ausgabe niemals gedruckt wird. Das Ausschalten visueller Rendering-Elemente verwandelt einen layoutintensiven Bericht in einen optimierten Batch-Prozess mit hohem Durchsatz.
Die Durchsetzung dieser Checklisten-Standards vor dem Hochstufen benutzerdefinierter Batch-Spezifikationen aus DV stellt sicher, dass die Berichtslaufzeiten im Minutenbereich bleiben, anstatt die Enterprise-Queues stundenlang zu blockieren.
