Wenn ein Universal Batch Engine (UBE)Die zentrale Engine in JD Edwards zur Ausführung von Hintergrundprozessen, Berichten und Massenverarbeitungen.-Prozess in Work With Submitted Jobs (P986110B) in den „Status E“ wechselt, springen Entwickler häufig direkt zur Neukompilierung von Event RulesDie proprietäre Skriptsprache von JD Edwards, mit der Geschäftslogik visuell programmiert wird.. In der Realität sind die meisten fatalen Report-Abstürze keine spontanen Serverfehler, sondern deterministische Fehlausrichtungen zwischen benutzerdefinierten C Business Functions (BSFNs)In C geschriebene Programme, die komplexe Geschäftslogik und Datenbankoperationen in JD Edwards ausführen., beschädigten JDECACHEEin JDE-interner Zwischenspeicher im Arbeitsspeicher, der den schnellen Zugriff auf temporäre Daten ermöglicht.-Pointern und unbehandelten Null-Parametern, die bei der dynamischen Datenauswahl übergeben werden.
Die Diagnose dieser Fehler erfordert einen strukturierten Trace anstelle von Trial-and-Error-Patches. Das Verständnis von JDE UBE Debug-Logs zur systematischen Fehlerbehebung fehlgeschlagener Batch-Jobs bietet ERP-Leitern und Entwicklern eine reproduzierbare Methode, um Speicherallokationsfehler zu isolieren, rohe SQL-WHERE-Klauseln zu parsen und exakte BSFN-Call-StacksEin Stapelspeicher, der die Reihenfolge der aktuell aktiven Funktionsaufrufe in einem Programm dokumentiert. direkt vor dem Abbruch eines Kernel-Prozesses auf dem Enterprise Server zu erfassen.
Ermitteln von Jobstatus und Prozess-IDs übermittelter Jobs
Wenn ein Batch-Prozess fehlschlägt, liegt Ihre unmittelbare Diagnosebasis in Work With Submitted Jobs (P986110B), direkt gestützt durch die Job-Master-Tabelle F986110Die Systemtabelle in JD Edwards, die den Status und die Details aller übermittelten Batch-Jobs speichert. im System-Schema. Die Überwachung des Feldes JCJOBSTATUS zeigt exakte Übergänge des Ausführungsstatus – insbesondere, wenn ein Job abrupt von „Processing“ (P) auf „Error“ (E) wechselt. Bei den meisten unmittelbaren Übergängen von P zu E liegt die Ursache eher in einer unbehandelten Speicher-Exception im C-Code oder einer verlorenen Datenbankverbindung als in einem Datenvalidierungsproblem in den Event Rules.
Das Öffnen des Zeilen-Exits (Row Exit) für Job Details in WSJ legt die Server-Prozess-IDEine eindeutige Nummer, die das Betriebssystem einem laufenden Programm zur Identifikation zuweist. offen, die in der Spalte JCEXEPROCESS aufgezeichnet ist. Diese Ganzzahl ist nicht nur eine interne JDE-Referenz; sie entspricht 1:1 der aktiven Betriebssystem-Prozess-ID, die den UBE-Kernel auf Ihrem Enterprise Server ausführt. Durch die Isolierung dieser PID können Sie direkt das entsprechende jde_PID.log im Log-Verzeichnis Ihres Servers – wie z. B. /u01/jdedwards/e920/log – anvisieren, ohne kostspielige systemweite Traces auszuführen oder raten zu müssen, welcher Kernel den ThreadEin einzelner Ausführungsstrang innerhalb eines Prozesses, der Aufgaben parallel zu anderen Threads verarbeiten kann. verwaltet hat.
Engine-Abstürze schreiben kritische Diagnoseausgaben nativ direkt in diese standardmäßigen jde_PID.log-Dateien, noch bevor ein Administrator ein tiefes Tracing auf Aufrufebene aktivieren muss. Speicherallokationsfehler, Array-Index-Überschreitungen und SQL-Verbindungsabbrüche erscheinen automatisch am Ende des Standard-Logs. Das vorzeitige Aktivieren des vollständigen Debug-Tracings verursacht einen Overhead von 20 % bis 30 % auf dem Enterprise Server und gibt Millionen von routinemäßigen API-Zeilen aus, was den einzelnen Pointer-Fehler, der den Job beendet hat, maskiert.
Analyse des primären JDE.LOG auf fatale Engine-Fehler
Wenn ein UBE-Job in F986110 direkt von „Processing“ auf „Error“ wechselt, ohne ein PDF zu schreiben, ist der Start mit einem riesigen Trace-Log ein taktischer Fehler. Das primäre jde.log dient als Exception-Reporter auf Systemebene für Kernel-Panics, Speicherverletzungen und unbehandelte C-BSFN-Abbrüche. Während Trace-Dateien die Ausführungsreihenfolge protokollieren, erfasst diese primäre Datei den genauen Moment, in dem der Enterprise-Server-Prozess abstürzt.
Suchen Sie im Log direkt nach C/C++-Laufzeitfehlersignaturen wie EXCEPTION_ACCESS_VIOLATION oder signal 11. Diese Zeilen geben die genaue Quelldatei und Zeilennummer aus, an der die Ausführung gestoppt wurde – beispielsweise B554201.c:412. Wenn eine benutzerdefinierte C Business Function einen Null-PointerEin Zeiger im Programmcode, der auf keine gültige Speicheradresse verweist und oft zu Abstürzen führt. dereferenziert oder eine Datenstruktur überläuft, zeigt der Laufzeit-Stack-Trace genau auf die fehlerhafte Codezeile und verwandelt ein unternehmensweites Problem in einen gezielten C-Quellcode-Fix.
Die Unterscheidung zwischen Plattform-Laufzeitabstürzen und weichen Anwendungsfehlern spart Teams erhebliche Analysezeit. Weiche fachliche Fehler, wie ungültige Artikelnummern oder gesperrte Datensätze in F4102, lassen den runbatch-Prozess intakt und geben Meldungen direkt auf der Fehlerseite des Reports aus. Ein fataler C-Engine-Absturz beendet den zugrunde liegenden Thread sofort, wodurch das PDF leer bleibt und keinerlei Fehlermeldungen auf Anwendungsebene generiert werden.
Wenn Sie mit einem Report-Fehler konfrontiert sind, dem keine Standard-Fehlermeldungs-IDs zugeordnet sind, überspringen Sie die Überprüfung der Event Rules komplett. Lesen Sie das jde.log von unten nach oben, um die fehlerhafte Thread-ID zu isolieren, nicht initialisierte MATH_NUMERICEin spezieller JDE-Datentyp zur präzisen Verarbeitung von numerischen Werten und Währungsbeträgen.-Variablen oder nicht allokierte Speicherstrukturen zu identifizieren und den C-Code direkt zu korrigieren. Kompilieren Sie die Ziel-BSFN mit busbuild.exe neu und stellen Sie das Update über einen selektiven Package-Build bereit, anstatt funktionierende Anwendungslogik umzustrukturieren.
Aktivieren und Filtern von hochvolumigen JDEDEBUG.LOG-Traces
Das Aktivieren des globalen Debug-Loggings (Output=FILE) in der jde.ini des Enterprise Servers kann ein Systemlaufwerk in weniger als einer halben Stunde füllen, da ein einzelner Batch-Prozess in Sekundenschnelle Hunderte von Megabytes an Trace-Text erzeugen kann. Enterprise Server, auf denen Dutzende von gleichzeitigen Batch-Threads laufen, erschöpfen die Festplattenkapazität oder beeinträchtigen die Kernel-Leistung, wenn das globale Tracing während eines großen Batch-Laufs aktiviert bleibt. Schalten Sie das Tracing strikt auf Job-Ebene in Work With Submitted Jobs (P986116) über Row > Advanced > Logging um, oder konfigurieren Sie ein gezieltes Tracing auf Benutzerebene im Abschnitt [DEBUG] der jde.ini unter Verwendung spezifischer Benutzer-Handles. Dies beschränkt die Log-Generierung auf den Zielprozess, während der Performance-Overhead in der Produktion unter 5 % bleibt.
Bei der Analyse eines gemeinsam genutzten jdedebug.log, in das mehrere Prozesse gleichzeitig schreiben, werden aufeinanderfolgende Log-Einträge ohne Isolierung von Thread-Identifikatoren unlesbar. Suchen Sie die UBE-Prozess-ID (PID) oder das Thread-Handle im Header der Job-Ausführung, die typischerweise im Format WRK:ProcessName_PID_ThreadID protokolliert werden. Das Filtern der Log-Datei mit Befehlszeilen-Utilities wie grep oder sed nach dieser spezifischen Thread-ID filtert Hintergrundrauschen von gleichzeitigen interaktiven Sitzungen, Subsystem-Jobs und nicht zusammenhängenden Batch-Queues heraus. Dies liefert einen sauberen Ausführungspfad, der die genaue Abfolge von C-API-Aufrufen und Event Rules for Ihre spezifische Job-Instanz zeigt.
Speicherlecks während lang laufender Verarbeitungsschleifen bleiben eine Hauptursache für stille UBE-Fehler, die keine funktionalen ER-Fehler erzeugen. Suchen Sie im nach Threads gefilterten Log nach jdeAlloc- und jdeFree-Anweisungen, um die C-Speicherverwaltung über Datensatz-Verarbeitungsschleifen hinweg zu prüfen. Wenn eine benutzerdefinierte Business Function während der Do Section einer UBE-Schleife mit 50.000 Zeilen dynamischen Speicher über jdeAlloc allokiert, ohne vor der Rückgabe von ER_SUCCESS ein entsprechendes jdeFree auszuführen, erschöpft der Kernel des Enterprise Servers schließlich den Heap-SpeicherEin Bereich des Arbeitsspeichers, aus dem Programme während der Laufzeit dynamisch Speicher anfordern und freigeben. und bricht ab. Das Überprüfen einer höheren Anzahl von Allokationsaufrufen im Vergleich zu Deallokationsaufrufen zeigt genau auf die spezifische benutzerdefinierte C-BSFN, die die Heap-Beschädigung verursacht.
Validierung von Datenauswahl und SQL-Ausführung
Wenn ein Batch-Job hängt oder ein Datenbank-Timeout auftritt, ist der Verursacher selten die Processing-Engine, sondern die physische SQL-Anweisung, die an die Datenbank gesendet wird. Das Parsen des jdedebug.log nach Zeilen, die Treiber-API-Aufrufe wie OCI0000054 oder direkten SQL-Text enthalten, legt die genaue Abfrage offen, einschließlich impliziter Joins über Business ViewsJDE-Objekte, die Tabellen verknüpfen und festlegen, welche Datenfelder einer Anwendung oder einem Bericht zur Verfügung stehen. und schlechter Indexauswahlen durch den Datenbank-Optimizer.
Abweichungen zwischen der entworfenen Auswahl und dem ausgeführten SQL lassen sich meist auf beschädigte Versionsspezifikationen zurückführen, die in der Job-Detailtabelle F986110 gespeichert sind. Die Datenauswahl der Report-Version wird als Binary Large Object (BLOBBinary Large Object; ein Datentyp in Datenbanken zur Speicherung großer, unstrukturierter binärer Daten.) im F986110-Datensatz gespeichert. Wenn ein Entwickler eine Version eincheckt, die auf einem veralteten Central-Objects-Paket basiert, kann dieser binäre Payload Data-Dictionary-Elemente falsch interpretieren. Der Vergleich der im Trace-Log gerenderten rohen WHERE-Klausel mit dem visuellen Layout im EnterpriseOne Development Client deckt sofort weggefallene Kriterien auf, wie z. B. eine fehlende MCU- oder DCTO-Klausel.
Auch die Logik der Event Rules kann die SQL-Performance unbemerkt sabotieren. Der Aufruf der Systemfunktion Set Selection Append Flag mit dem Parameter 0 oder NO löscht stillschweigend die gesamte auf der Report-Version definierte Basis-Datenauswahl, bevor die ER-Auswahl angewendet wird. Anstatt dynamische Kriterien an die vom Benutzer eingegebenen Filter anzuhängen, erstellt die Engine eine uneingeschränkte SQL-Anweisung auf riesigen Tabellen wie F0911 oder F0011 ohne Datums- oder Ledger-Einschränkungen. Dies führt zu einem sofortigen Full Table Scan, der den temporären Speicher der Datenbank sprengt und die Job-Queues des Servers blockiert.
Tracing von Event-Rules-Ausführung und Cache-Fehlern
Wenn ein Report bei fast 100 % CPU-Auslastung hängt oder nach der Verarbeitung einer Handvoll Datensätze anstelle des vollständigen Datensatzes abbricht, verfolgen Sie den Ausführungsfluss der Event Rules direkt im JDEDEBUG.LOG. Das Verfolgen des Ausführungspfads vom Do Section-Event über On Fetch Structure zeigt genau auf, wo eine unbegrenzte While-Schleife endlos läuft oder wo ein Stop Processing-Systemaufruf die Ausführung vorzeitig beendet. In benutzerdefinierten Sektionen auf Treiberebene betten Entwickler häufig benutzerdefinierte Logik in Fetch-Events ein, ohne Null-Key-Pointer zu berücksichtigen, was dazu führt, dass die Engine denselben Datensatz wiederholt auswertet, bis der Serverspeicher erschöpft ist.
Logzeilen, die JDE-Cache-Fehler während der UBE-Ausführung offenbaren, weisen eher auf unmanaged Speicherallokationen als auf eine Beschädigung der Engine hin. Das Auftreten des Fehler-Rückgabecodes COB0100011 oder von Ausnahmen wegen ungültiger Handles während eines jdeCacheFetch-Aufrufs bedeutet, dass ein früheres jdeCacheTerminate in einer bedingten Verzweigung umgangen wurde. Bei Batch-Jobs mit Zehntausenden von Detail-Iterationen führt das Überspringen der Cache-Terminierung zu Lecks von Hunderten von Megabytes an Heap-Speicher auf dem Enterprise Server, was schließlich zu Speicherallokationsfehlern in verknüpften C-BSFNs führt.
Ein weiteres häufiges Fehlerszenario ist der stille Abschluss eines Batch-Jobs, bei dem keine Detailzeilen gedruckt werden. Die fehlerhafte Verwendung der Systemfunktion Suppress Section Write innerhalb einer bedingten ER-Logik führt dazu, dass die UBE-Engine alle zugrunde liegenden Datenbankoperationen ausführt, während die Layout-Ausgabe-Engine vollständig umgangen wird. Der Job endet mit dem Status 60 in F986110 und erzeugt ein kleines PDF, das nur Sektionsüberschriften enthält. Suchen Sie im Log nach Sektions-Ausführungsflags direkt nach den Detail-Fetch-BSFNs, um zu bestätigen, ob Sektions-Schreibvorgänge absichtlich unterdrückt oder aufgrund unbehandelter Logikzweige übersprungen wurden.
Behebung intermittierender BSFN-Speicher- und Call-Stack-Probleme
Wenn eine UBE auf Enterprise Servern mit 64-Bit-Tools-Releases sporadisch abstürzt, ist die Ursache häufig eine Strukturabweichung zwischen dem kompilierten C-BSFN-Header-Typedef und den in der Objekttabelle F9860 gespeicherten Datenstrukturspezifikationen. Auf 64-Bit-Architekturen erfordern Speicherausrichtungsregeln strikte 8-Byte-Grenzen für Pointer und Strukturmitglieder. Wenn eine benutzerdefinierte Datenstruktur in den Event Rules geändert wird, ohne die entsprechende C-Header-Datei neu zu parsen und neu zu kompilieren, verschieben sich die Speicher-Offsets. Der Batch-Prozess verarbeitet möglicherweise Tausende von Datensätzen fehlerfrei, bevor er bei starker Datenverarbeitung auf eine Zugriffsverletzung stößt, wenn sich Stack-Frames überschneiden.
Diese Fehler treten bei lokalen Fat-Client-Ausführungen routinemäßig nicht auf, während sie in der Produktion katastrophal fehlschlagen. Lokale Entwicklungs-Workstations allokieren Speicher sequenziell mit lockeren Stack-Grenzen, was nicht initialisierte C-Variablen effektiv maskiert. Multi-Threaded Enterprise Server Call-Stacks recyceln jedoch Speicheradresse schnell über gleichzeitige Batch-Engine-Prozesse hinweg. Ein nicht initialisierter Pointer oder eine nicht initialisierte MATH_NUMERIC-Variable innerhalb einer benutzerdefinierten C-Funktion zieht Restdaten aus der Ausführung eines vorherigen Threads. Logik, die isolierte Unit-Tests auf einem Fat Client besteht, stürzt während eines nächtlichen Verarbeitungslaufs ab.
Die Behebung dieses Problems erfordert die Neugenerierung der Datenstruktur-Header über die Object Management Workbench, gefolgt von einem vollständigen Business-Function-Rebuild über alle Serverpakete hinweg. Löschen Sie innerhalb des C-Quellcodes den Strukturspeicher explizit mit memset(&dsOutput, 0, sizeof(dsOutput)) am Einstiegspunkt jedes benutzerdefinierten API-Aufrufs. Stellen Sie sicher, dass Event Rules BSFN-Rückgabecodes auswerten – Prüfung auf ER_SUCCESS (0) im Vergleich zu ER_ERROR (2) –, bevor nachgelagerte Verarbeitungsschritte ausgelöst werden. Wenn Rückgabecodes ungeprüft bleiben, können nicht initialisierte Pointer-Zustände kaskadenartig durch den Call-Stack wandern und letztendlich den Batch-Kernel zum Absturz bringen, ohne einen expliziten Eintrag im JDE.LOG zu hinterlassen.
