Das Starten eines C-Debuggers wie Microsoft Visual Studio zum Durchlaufen einer Named Event Rule (NER)Eine visuelle Programmiersprache in JD Edwards, die in C-Code umgewandelt wird, um Geschäftslogik zu definieren. ist oft unnötig und zeitaufwendig. Für die meisten JD Edwards-Entwickler ist ein effizienterer Ansatz für das JDE NER Debugging das TracingDie Aufzeichnung von Programmschritten in einer Log-Datei zur Fehleranalyse. von Event Rules, die direkt von einem Applikationsaufruf ausgelöst werden, unter Verwendung der nativen Logging-Funktionen der Runtime-Engine. Durch die systematische Analyse des Call StacksEine Liste der aktiven Funktionsaufrufe, die die Hierarchie der Programmausführung zeigt., der Parameter-Mappings und der Rückgabecodes im lokalen Debug-LogEine Textdatei mit detaillierten technischen Informationen über den Programmablauf und Fehler. können Sie die Ursache von Transaktionsfehlern schnell isolieren, ohne den Aufwand für das Kompilieren von Debug-Symbolen oder das Anhängen externer Prozesse.
Die APPL-zu-NER-Schnittstelle: Mapping des Call Stacks
Wenn ein Benutzer in der Sales Order Entry Applikation (P4210) auf die Schaltfläche OK klickt, führt die Runtime-Engine einen komplexen Call Stack aus, der oft 30 bis 60 verschachtelte Business Function (BSFN)Ein wiederverwendbares Programmodul in JDE für spezifische Geschäftslogik. und Named Event Rule (NER) Aufrufe innerhalb einer einzigen Transaktionsgrenze auslöst. Wenn Ihre benutzerdefinierte Logik während dieses Prozesses fehlschlägt, erfordert das Finden der Ursache das Mapping der exakten Sequenz des NER-Aufrufs innerhalb der Event Rules (ER) der APPL. Entwickler verschwenden oft Stunden damit, Log-Dateien zu durchkämmen, wenn sie zuerst das spezifische Ereignis isolieren sollten – wie Post Button Clicked oder OK Button Clicked –, in dem die benutzerdefinierte NER registriert ist.
Interaktive Applikationen übergeben Werte an NERs unter Verwendung eines spezifischen Data StructureEine definierte Gruppe von Feldern für den Datenaustausch zwischen JDE-Objekten. (DSTR) Templates, was in diesem Szenario eine benutzerdefinierte Struktur mit mehreren Parametern (D554201A) ist, die von der benutzerdefinierten NER N554201A aufgerufen wird. Ein häufiger Fehlerpunkt ist eine Diskrepanz zwischen den Datentypen der Form Control (FC)Ein Eingabefeld oder Steuerelement auf einer grafischen JDE-Benutzeroberfläche. oder Grid Column (GC)Eine Spalte in einer tabellarischen Listenansicht innerhalb einer JDE-Anwendung. in der APPL und den entsprechenden Elementen im Template der NER. Beispielsweise führt das Mapping eines 40-stelligen String-Form-Controls auf ein 30-stelliges Data Structure Member (wie SZALPH) zu einer stillen Speicherabschneidung oder, schlimmer noch, zu einer Speicherinitialisierungsverletzung, die den Call Object KernelEin Server-Prozess, der die Geschäftslogik auf dem Enterprise Server ausführt. auf dem Enterprise ServerDer zentrale Server, auf dem die Datenbank und die Geschäftslogik von JD Edwards laufen. zum Absturz bringt.
Um diese Alignment-Fehler zu vermeiden, überprüfen Sie immer das Parameter-Mapping im Event Rules Design (ERD) ToolDie Entwicklungsumgebung in JDE zum Erstellen und Bearbeiten von Programmlogik., bevor Sie die benutzerdefinierte NER generieren. Wenn Sie eine Data Structure ändern, um einen zusätzlichen Parameter hinzuzufügen, aktualisiert JDE die vorhandenen Mappings in der APPL nicht automatisch; sie bleiben ungemappt oder falsch ausgerichtet. Das manuelle Neuausrichten dieser Variablen im ER-Editor der APPL und das Durchführen einer lokalen Generierung ist der einzige Weg, um sicherzustellen, dass die Runtime-Engine die Parameter korrekt auf den Execution Stack schiebt.
Konfiguration des Runtime-Trace für eine saubere Log-Erfassung
Eine standardmäßige lokale Web-Client-Sitzung auf einem Fat Client kann leicht zig Megabyte an Log-Daten pro Minute erzeugen, was eine präzise Konfiguration der lokalen jde.iniDie zentrale Konfigurationsdatei für JD Edwards-Einstellungen auf Clients und Servern. entscheidend macht, bevor Sie Ihre Zielapplikation auslösen. Wenn Sie die Standardeinstellungen weit offen lassen, überflutet das System das Log mit Hintergrund-MiddlewareSoftware, die als Brücke zwischen verschiedenen Anwendungen oder Betriebssystemen fungiert.-Rauschen und begräbt die spezifische Ausführung der Named Event Rule, die Sie analysieren müssen. Um den Ausführungspfad zu isolieren, navigieren Sie zum Abschnitt [DEBUG] Ihrer lokalen jde.ini-Datei.
Innerhalb dieses [DEBUG]-Abschnitts ist die Einstellung Output=FILE und DebugLevel=EXT die Grundvoraussetzung für die Erfassung der granularen Ein- und Ausstiegspunkte der NER-Engine. Der Wert EXT stellt sicher, dass die JDE-Runtime die exakten Parameter protokolliert, die in die Business Function Data Structure übergeben wurden, sowie die bei der Ausführung zurückgegebenen Werte. Ohne diese Detailtiefe sehen Sie nur, dass die Funktion aufgerufen wurde, verpassen aber die kritischen Zustandsänderungen der Variablen.
Um das Log lesbar zu halten, müssen Sie unnötige Tracing-Komponenten explizit deaktivieren, die die Ausgabe verunreinigen. Schalten Sie das SQL-TracingDie Aufzeichnung aller Datenbankabfragen, die von einer Anwendung an den Server gesendet werden. aus, indem Sie LogSQL=0 im Abschnitt [DB SYSTEM SETTINGS] setzen, und stellen Sie sicher, dass das Security Kernel Tracing deaktiviert ist. Durch das Eliminieren dieser Datenbank-Abrufdetails wird das Log-Volumen um etwa zwei Drittel reduziert, sodass Ihr Fokus vollständig auf dem Event Rules Ausführungsfluss und dem Call Stack bleibt.
Ein zuverlässiger Ansatz ist die Verwendung des JDE AppControl Utilities oder das manuelle Umschalten des Debug-Log-Status unmittelbar bevor Sie auf die spezifische Schaltfläche oder den Exit klicken, der das Applikationsereignis auslöst. Das aktive Debugging sollte nur für die 3 bis 5 Sekunden laufen, die für die Ausführung der Ziel-Business-Logik benötigt werden. Das dynamische Umschalten des Log-Status über die Runtime-API oder ein lokales Utility hält Ihre Trace-Datei unter 5 bis 10 Megabyte, sodass Sie sie sofort in jedem Texteditor öffnen können, ohne die Applikation zum Absturz zu bringen.
Isolieren von NER-Einstieg und -Ausstieg im jdedebug.log
Das Isolieren einer benutzerdefinierten Named Event Rule innerhalb einer großen Log-Datei, die oft mehrere hundert Megabyte groß ist, erfordert sofortiges, chirurgisches Filtern. Wenn Sie nach der Zeichenfolge Entering JDE_NER: N554201A suchen, bestimmen Sie die exakte Millisekunde, in der die Runtime die Ausführung von der interaktiven Applikation an Ihre benutzerdefinierte Verkaufslogik übergibt. Dieser Einstiegspunkt wird von einer spezifischen Kennung begleitet, wie z. B. der Thread-IDEine eindeutige Nummer, die einen einzelnen Ausführungsstrang innerhalb eines Programms identifiziert. 4512, die als Ihr Anker fungiert. Sie müssen diesen spezifischen Thread sofort isolieren; andernfalls werden verschachtelte Logs von asynchronen Business Functions, Hintergrund-UBEsUniversal Batch Engine: Hintergrundprozesse für Berichte und Massendatenverarbeitung. oder System-Subroutinen, die auf parallelen Threads laufen, Ihre Analyse des Ausführungspfads verfälschen.
Sobald Sie Thread 4512 isoliert haben, legt die JDE-Runtime die Call-Stack-Tiefe mit verschachtelten Ebenenindikatoren wie --> für den Einstieg und <-- für den Ausstieg offen. Jede verschachtelte Ebene stellt einen Schritt tiefer in der Ausführungshierarchie dar, z. B. wenn N554201A Standard-Sales-Master-Business-Functions wie B4200310 aufruft. Das Zählen dieser Pfeilindikatoren ermöglicht es Ihnen, die exakte Parent-Child-Beziehung der Business Functions abzubilden, ohne raten zu müssen. Wenn Sie den entsprechenden Marker Exiting JDE_NER: N554201A auf demselben Thread finden, haben Sie das Ausführungsfenster für diesen spezifischen Aufruf erfolgreich eingegrenzt.
Der Vergleich der Zeitstempel-Differenzen zwischen diesen Einstiegs- und Ausstiegsmarkern ist der schnellste Weg, um Performance-Einbußen zu diagnostizieren. Eine einzelne Ausführung von N554201A sollte in weniger als 50 bis 100 Millisekunden verarbeitet werden. Wenn sich das Delta zwischen den Einstiegs- und Ausstiegsmarkern jedoch auf mehrere Sekunden erstreckt, haben Sie es mit einem kritischen Engpass zu tun. Diese Verzögerung deutet typischerweise auf nicht indizierte benutzerdefinierte Abrufe innerhalb einer Select/Fetch Next-Schleife oder repetitive, redundante Tabellen-I/O-Operationen innerhalb der Event Rules hin. Durch die Berechnung dieser Deltas über mehrere Iterationen im Log können Sie beweisen, ob ein Performance-Problem systemisch ist oder mit einer spezifischen Datenlast zusammenhängt.
Überprüfung von Parameter-Mappings und Datenstrukturen
Der exakte Zustand Ihrer Datenstruktur zum Zeitpunkt der Ausführung wird im jdedebug.log unmittelbar nach der Zeile Entering JDE_NER offengelegt. Die Engine gibt jedes Member der Zieldatenstruktur aus und zeigt Ihnen genau, was die aufrufende APPL auf den Stack geschoben hat. Wenn Sie eine Berechnung debuggen, die nur fehlschlägt, wenn sie von einem bestimmten Power Form aus ausgeführt wird, ist dieser Dump der Ort, an dem Sie das Delta zwischen erwarteten und tatsächlichen Eingaben isolieren.
Ein häufiger Übeltäter in diesen Dumps ist ein MATH_NUMERICEin spezieller JDE-Datentyp für hochpräzise mathematische Berechnungen. Parameter, der als nicht initialisierter leerer String ankommt, anstatt als saubere Null. In C-basierten Business Functions und NERs wird ein Leerzeichen in einer Math-Struktur nicht standardmäßig auf Null gesetzt; stattdessen umgeht es die Initialisierungslogik, was dazu führt, dass nachgelagerte mathematische Operationen stillschweigend fehlschlagen oder Speicherverletzungen auslösen. Wenn Sie das Log untersuchen, suchen Sie nach einer Zeile wie IN [1] <Math Numeric> : [], die bestätigt, dass die aufrufende Applikation die Variable nicht initialisiert hat, bevor sie an die Datenstruktur übergeben wurde.
Zeichenfelder wie EV01-Flag-Parameter erfordern die gleiche Sorgfalt. Eine APPL könnte ein kleingeschriebenes 'y' anstelle eines großgeschriebenen 'Y' übergeben, oder ein Zeichenfeld könnte ein nachfolgendes Leerzeichen enthalten, das die Basisvalidierungsregeln passiert. Das Trace-Log legt diese Literalwerte in Klammern offen, was es einfach macht zu erkennen, ob eine bedingte Anweisung innerhalb der NER fehlschlägt, nur weil sie 'y' == 'Y' als falsch ausgewertet hat.
Bevor Sie am Aufrufblock vorbeiscrollen, verfolgen Sie den Trace bis zur entsprechenden Zeile Exiting JDE_NER, um die ausgehenden Parameter zu überprüfen. Wenn die interne Logik erfolgreich ausgeführt wurde, muss das Log die Ausgabeparameter mit ihren neuen Werten unmittelbar vor diesem Ausstiegsmarker anzeigen. Wenn die Ausgaben trotz fehlender Datenbankfehler in den Logs leer oder unverändert bleiben, liegt Ihr Problem im bedingten Routing der internen Event Rules der NER, nicht in der Datenbankebene.
Verfolgung von Rückgabecodes und Error Stack Propagation
Eine NER kommuniziert ihren Ausführungsstatus an die aufrufende APPL über ein striktes Rückgabewert-Protokoll: ER_SUCCESS (0) zeigt eine saubere Ausführung an, während ER_ERROR (2) einen harten Fehler signalisiert. Wenn eine Validierung innerhalb der NER fehlschlägt, stoppt die Engine die Event Rules der aufrufenden Applikation nicht automatisch, es sei denn, dieser Rückgabecode wird explizit vom Aufrufer ausgewertet. Im jdedebug.log sehen Sie dies unmittelbar nach der Zeile Return value is des BSFN-Ausführungsblocks, wo eine 2 anzeigt, dass das aufrufende Formular seine Commit-Sequenz stoppen muss.
Innerhalb des generierten C-Codes der NER werden native Event Rules wie "Set Action Error" direkt auf die Error StackEin interner Speicherbereich, der Fehlermeldungen während der Programmausführung sammelt. APIs der JDE-Engine gemappt. Wenn Sie einen Validierungsfehler tracen, suchen Sie im Log nach der Tracking-Zeile COB0000012 oder dem API-Aufruf jdeErrorSet, der das spezifische Data DictionaryEin zentrales Repository, das alle Felddefinitionen und Validierungsregeln in JDE speichert. Item – wie 0002 für "Record Invalid" – direkt im Speicher des Threads registriert. Die Log-Zeile gibt explizit das Ziel-DD-Item und die zugehörige Tabelle oder den Alias aus und bestätigt damit, dass die Business Function den Fehler erfolgreich registriert hat, noch bevor die Kontrolle an die interaktive Runtime zurückgegeben wird.
Eine häufige Falle tritt auf, wenn die aufrufende APPL diesen Rückgabecode unterdrückt oder nicht auswertet, was zu einem stillen Fehler führt, bei dem der Bildschirm einfriert, ohne den standardmäßigen roten Fehlertext anzuzeigen. Diese Diskrepanz tritt auf, weil der Error Stack zwar das registrierte DD-Item 0002 enthält, der Kontrollfluss des Formulars jedoch aufgrund einer ungemappten Rückgabevariablen in den Event Rules der APPL die Fehleranzeigelogik umgeht. Um dies zu beheben, stellen Sie sicher, dass die aufrufenden Event Rules den Return-Pointer der BSFN prüfen und explizit ein Set Action Error auf Kontrollebene auslösen, wenn die NER 2 zurückgibt.
Rebuilding und Deployment der korrigierten NER via OWM
Wenn Sie den Alignment-Fehler in Ihrer benutzerdefinierten Sales Order Entry NER finden, zum Beispiel N554201A, können Sie den Event Rules Designer nicht einfach speichern und schließen. JDE-Entwickler vergessen oft, dass das Speichern von ER nur die Spezifikationen aktualisiert; Sie müssen explizit den Generierungsprozess innerhalb der Object Management Workbench (OWM)Das zentrale Werkzeug für Entwicklung und Versionskontrolle in JDE. auslösen, um diese visuellen Regeln in tatsächliche n554201a.c und n554201a.h Quelldateien zu übersetzen. Wenn Sie diesen Generierungsschritt überspringen, baut der Compiler den alten C-Code und ignoriert Ihre visuellen ER-Änderungen vollständig.
Führen Sie nach der Generierung einen lokalen Build der Business Function innerhalb der OWM aus, um den neuen C-Code in das Runtime-Verzeichnis Ihrer lokalen Entwicklungsumgebung zu kompilieren, was besonders kritisch ist, wenn Sie ein 64-Bit Tools Release wie 9.2.6 verwenden. Um diese Änderung lokal auf Ihrem Entwicklungs-Client zu testen, müssen Sie den lokalen Spec-Caching-Mechanismus umgehen. Löschen Sie die lokale Datei spec.db in Ihrem lokalen PathcodeEine isolierte Umgebung in JDE, die eine spezifische Version von Softwareobjekten enthält.-Verzeichnis (typischerweise unter E920\DV920\spec\) und starten Sie Ihren lokalen Web Dev Client neu, um EnterpriseOne zu zwingen, die neu kompilierten Spezifikationen zu serialisieren.
Sobald die lokale Validierung erfolgreich ist, stufen Sie N554201A über die OWM in Ihren Testprojektstatus hoch, typischerweise Status 26 für QA. Sie müssen einen selektiven Update Package Build für Ihren Ziel-Pathcode, wie z. B. PY920, durchführen und diesen sowohl auf dem Enterprise Server als auch auf den HTML Server Instanzen bereitstellen. Das Überspringen dieses Deployment-Schritts ist die häufigste Ursache für das "Works on my machine"-Syndrom, bei dem der Enterprise Server weiterhin die veraltete, gecachte DLLDynamic Link Library: Eine Datei mit kompilierem Programmcode, der zur Laufzeit geladen wird. oder Shared Library ausführt, was zu sofortigen Runtime-Fehlern führt.
Das Beherrschen des Call Stacks und das Interpretieren der jdedebug.log-Ausgabe ist unerlässlich bei der Fehlersuche in komplexer NER-Logik in Tools Release 9.2.8 und darüber hinaus. Durch systematisches Isolieren von Thread-IDs, Verifizieren von Parameter-Mappings und Überwachen des Error Stacks können Entwickler Integrationsengpässe lösen und die Transaktionsintegrität im gesamten Unternehmen sicherstellen.
