In Form Design Aid (FDA)Das Entwicklungswerkzeug von JD Edwards zur Erstellung grafischer Benutzeroberflächen und interaktiver Anwendungen. ist es ein riskanter Fehler, eine Business FunctionEin wiederverwendbares Programmodul in JD Edwards, das spezifische Geschäftslogik oder Datenbankoperationen ausführt. wie F4211FSEditLine (B4200310) einfach in eine Event RuleDie proprietäre Skriptsprache von JD Edwards, mit der Logik hinter Schaltflächen, Feldern oder Ereignissen programmiert wird. einzufügen und darauf zu vertrauen, dass die HTML-Engine Verarbeitungsfehler elegant abfängt. Ein erheblicher Teil der von uns geprüften kundenspezifischen interaktiven Anwendungen (P55/P56) – unserer Erfahrung nach etwa ein Drittel bis die Hälfte – leidet unter stillen Fehlern, da sich Entwickler darauf verlassen, dass die JDE-RuntimeDie Ausführungsumgebung, die den Programmcode während der Benutzung der Anwendung verarbeitet. Fehler automatisch nach oben weiterreicht. Dieser Artikel liefert ein konkretes JDE APPL Beispiel für den Aufruf von Business Functions aus Event Rules, um zu demonstrieren, wie diese verborgenen Datenbankkorruptionen verhindert werden können.
Um defensiven Code zu erstellen, müssen Sie die SystemvariableVordefinierte Variablen der JDE-Umgebung, die Statusinformationen wie Fehlerzustände oder Benutzerdaten enthalten. SV COB_API_FAILED explizit auswerten oder das Flag cErrorActive direkt aus der DatenstrukturDie definierte Schnittstelle von Parametern, über die Daten zwischen der Anwendung und einer Business Function ausgetauscht werden. der BSFN mappen. Indem Sie einige zusätzliche Minuten investieren, um diese Rückgabewerte zu mappen und die SystemfunktionIntegrierte Funktionen der JDE-Entwicklungsumgebung zur Steuerung der Benutzeroberfläche oder des Programmablaufs. Set Action Code Error aufzurufen, eliminieren Sie das Risiko, dass ein Benutzer einen fehlerhaften Verkaufsauftrag oder einen Gutschriftendatensatz speichert. Schauen wir uns an, wie diese Grenzprüfung korrekt strukturiert wird.
Der Trugschluss der automatischen ER-Fehlerbehandlung
Form Design Aid (FDA) suggeriert fälschlicherweise, dass die EnterpriseOne Runtime EngineDer Kernmechanismus von JD Edwards, der für die Ausführung von Anwendungen und die Verarbeitung von Geschäftslogik zuständig ist. Fehler von Business Functions auf C-Ebene automatisch an die Benutzeroberfläche weiterleitet. In der Realität kann ein kritischer Fehler innerhalb einer benutzerdefinierten C-Business-Function auftreten, während die interaktive Anwendung so fortfährt, als wäre die Ausführung erfolgreich gewesen, sofern Sie die Rückgabeparameter nicht explizit mappen und validieren. Dieses Verhalten ist besonders gefährlich, wenn Entwickler davon ausgehen, dass die einfache Prüfung der Systemvariablen SV CO_SUCCESS für jeden BSFN-Aufruf ausreicht; diese Variable gibt lediglich an, ob die Funktion ausgeführt wurde, nicht jedoch, ob die interne Geschäftslogik erfolgreich war.
Die EnterpriseOne Runtime Engine verarbeitet Fehler unterschiedlich, je nachdem, ob die Business Function innerhalb einer aktiven TransaktionsgrenzeDer logische Rahmen einer Datenbanktransaktion, der sicherstellt, dass entweder alle Änderungen gespeichert oder bei Fehlern alle verworfen werden. ausgeführt wird. Bei einer Ausführung außerhalb einer Transaktion löst ein Fehler auf Datenbankebene – wie z. B. ein Fehler aufgrund eines doppelten Schlüssels beim Schreiben in eine benutzerdefinierte Tabelle – keinen automatischen RollbackDas Rückgängigmachen von Datenbankänderungen, wenn ein Fehler auftritt, um einen konsistenten Datenzustand zu bewahren. aus. Wer sich allein auf die JDE-Engine verlässt, um diese Fehler auf Datenbankebene abfangen, ohne die BSFN-Rückgabecodes zu prüfen, riskiert oft stille DatenkorruptionFehlerhafte oder inkonsistente Zustände in der Datenbank, die durch unvollständige oder falsche Schreibvorgänge entstehen.. Dies hinterlässt verwaiste Datensätze in benutzerdefinierten Tabellen, während die Standardtabelle F4211 erfolgreich aktualisiert wird.
Um diese Integritätsprobleme zu vermeiden, müssen Entwickler die Flags cErrorToParent oder cSuppressErrorMessage, die von Standard-Oracle-Business-Functions zurückgegeben werden, explizit auswerten. Beispielsweise weist die Übergabe von '1' an cErrorToParent bei Standard-F4211-FSSO-Aufrufen (Master Business FunctionEine komplexe Business Function, die zentrale Geschäftslogik für wichtige Tabellen wie Verkaufsaufträge oder Buchhaltungsdaten zentralisiert.) die BSFN an, Fehler an die Fehlerliste des aufrufenden Formulars zurückzugeben. Wenn dieses Flag leer bleibt oder nicht gemappt wird, protokolliert die Master Business Function möglicherweise eine Warnung im jde.log, löst aber nicht die rote Fehlerhervorhebung auf dem Formular aus, sodass der Benutzer auf "OK" klicken und eine fehlerhafte Transaktion abschließen kann.
Mapping der BSFN-Datenstruktur in FDA
In Form Design Aid (FDA) ist das Mapping einer komplexen Business Function wie F4114 Edit Line (B3101260) der Punkt, an dem viele benutzerdefinierte Anwendungen unter Last scheitern. Jeder BSFN-Aufruf in Event Rules erfordert das Mapping von Form Controls oder Grid-Spalten auf die zugrunde liegenden Parameter der Datenstruktur. Wenn Sie ein 30-stelliges String-Form-Control auf ein 10-stelliges Datenstruktur-Mitglied mappen, riskieren Sie eine SpeicherkorruptionEin kritischer Fehler, bei dem ein Programm in nicht reservierte Speicherbereiche schreibt, was zu Abstürzen führen kann. im CallObject-KernelEin spezialisierter Serverprozess, der für die Ausführung von Business Functions auf dem Enterprise-Server verantwortlich ist.. Die Richtungspfeile (In, Out, Both) im Fenster "Parameter Mapping" müssen exakt mit dem Design der C-BSFN übereinstimmen, um Speicherverletzungen oder Speicherlecks zu verhindern, die die jdenet_k-Prozesse des Enterprise-Servers zum Absturz bringen.
Input-Parameter sollten direkt auf Form ControlsEingabefelder oder Steuerelemente auf einer grafischen Benutzeroberfläche in JD Edwards. oder Grid-SpaltenDie einzelnen Spalten einer tabellarischen Anzeige (Grid) innerhalb einer JDE-Anwendung. gemappt werden, um sicherzustellen, dass die Runtime die aktuellen Bildschirmwerte übergibt. Umgekehrt müssen Output-Parameter auf ER VariablenLokale Variablen innerhalb der Event Rules, die zur temporären Speicherung von Werten während der Programmausführung dienen. zielen, anstatt sie direkt auf Bildschirm-Controls zurückzumappen. Diese Staging-Strategie ermöglicht die Validierung von Rückgabewerten, wie z. B. den Status der Bestandstransaktion oder Warn-Flags, bevor der Bildschirm aktualisiert und die Daten festgeschrieben werden. Wenn Sie einen BSFN-Output direkt auf ein datenbankgestütztes Form Control mappen, verlieren Sie die Möglichkeit, einen Fehler abzufangen und den nächsten logischen Schritt im Ausführungsthread Ihrer Anwendung zu verhindern.
Das Nicht-Mappen kritischer Output-Parameter, wie des Fehlercode-Flags (cErrorCode) oder des Transaktions-Cursor-Handles, verhindert, dass die Event Rules Runtime Ausführungsstatuscodes vom CallObject-Kernel erhält. In der überwiegenden Mehrheit der von uns untersuchten Fehler in benutzerdefinierten Anwendungen hat der Entwickler den Fehlerrückgabeparameter nicht gemappt, in der Annahme, das System würde automatisch einen Fehler auf dem Bildschirm ausgeben. Ohne das Mapping dieser Rückgabe-Flags auf ER-Variablen bleibt Ihre Anwendung blind für zugrunde liegende Datenbanksperren oder Fehler in der Geschäftslogik und fährt stillschweigend fort, als wäre die Transaktion erfolgreich gewesen.
Abfangen des Rückgabestatus und des Fehlertextes
JDE-Entwickler gehen häufig davon aus, dass der Aufruf einer Business Function in Form Design Aid (FDA) die Verarbeitung automatisch stoppt, wenn eine Validierung fehlschlägt. Das tut er nicht. Standard-C-Business-Functions kommunizieren Fehler über einen binären Statusindikator in der Datenstruktur, wobei ein zurückgegebener Wert von '1' einen schwerwiegenden Fehler und '2' eine Warnung darstellt. Wenn Ihre Event Rules diesen Rückgabewert nicht unmittelbar nach dem Call Business Function-Statement explizit auswerten, führt die Runtime Engine die nachfolgenden Codezeilen blind aus und verarbeitet ungültige oder korrupte Datenbank-Schreibvorgänge.
Um diesen stillen Ausführungsfehler zu verhindern, müssen Sie den Parameter szErrorMessageID aus der BSFN-Datenstruktur auf eine dedizierte Variable in Ihren Event Rules mappen. Das Erfassen dieses spezifischen alphanumerischen Codes ermöglicht es der Anwendung, kontextbezogene, lokalisierte Fehlermeldungen aus den DD-TabellenTabellen des Data Dictionary, die Definitionen für Datenfelder und Fehlermeldungen zentral speichern. anzuzeigen, anstatt generische, wenig hilfreiche Systemfehler auszugeben. Einmal erfasst, müssen Sie sofort die Systemfunktion Set Control Error für Form Controls oder Set Grid Cell Error für Grid-Spalten aufrufen, um das exakte Feld visuell zu markieren, das den Validierungsfehler verursacht hat.
In einem kürzlich durchgeführten Projekt zur Behebung einer benutzerdefinierten Bestandsübertragungsanwendung (P554113) versäumte es der ursprüngliche Entwickler, den Rückgabestatus der Funktion VerifyAndGetItemMaster (B4100010) zu prüfen. Die Anwendung führte den Transaktionszweig auch dann weiter aus, wenn die Artikelnummer ungültig war, was zu verwaisten CardexDas zentrale Bestands-Hauptbuch in JD Edwards (Tabelle F4111), das alle Lagerbewegungen aufzeichnet.-Datensätzen in der Tabelle F4111 führte. Durch das Einfügen eines Auswertungsblocks unmittelbar nach dem Aufruf und das Mapping der zurückgegebenen Fehler-ID auf das Artikelnummer-Control blockierten wir den ungültigen Commit und reduzierten die Tickets für Datenkorruption in den Wochen nach dem Go-Live um über 90 %.
Synchrone vs. Asynchrone BSFN-Ausführung
Das Aktivieren der Option AsynchronousEin Verarbeitungsmodus, bei dem eine Funktion im Hintergrund ausgeführt wird, ohne dass der Benutzer auf den Abschluss warten muss. in Form Design Aid (FDA) für einen Business-Function-Aufruf bei einem "Post Button Clicked"-Event ist eine gängige Abkürzung, um zu verhindern, dass die Benutzeroberfläche während langwieriger Operationen einfriert. Dieses Designmuster führt jedoch zu einer Schwachstelle: Die interaktive Anwendung (APPL) verliert die Fähigkeit, Fehler abzufangen oder den Rückgabestatus dieser BSFN innerhalb des aktuellen Event-Rule-Flows zu inspizieren. Wenn eine Funktion wie F4211FSEndDoc in einem asynchronen Thread läuft, gibt die Runtime die Kontrolle sofort an das Formular zurück. Der Benutzer erhält eine irreführende Erfolgsmeldung, während das Einfügen in die Datenbank im Hintergrund tatsächlich fehlschlagen könnte.
Um eine strikte Transaktionsintegrität zu erzwingen und die Formularverarbeitung in dem Moment zu stoppen, in dem eine Validierung oder ein Datenbank-Insert fehlschlägt, müssen Sie das Kontrollkästchen Asynchronous in FDA deaktivieren. Dies zwingt die Event Rules (ER) Engine, auf den Abschluss der BSFN-Ausführung auf dem Enterprise-Server zu warten und einen sauberen Erfolgs- oder Fehlerstatus zurückzugeben, bevor sie mit der nächsten Codezeile fortfährt. In einem Standard-Verkaufsauftragsszenario (P4210) stellt das Deaktivieren dieses Kontrollkästchens sicher, dass jeder Fehler bei der Steuerberechnung oder Bestandsverpflichtung den Prozess stoppt, bevor der Bildschirm geleert wird, sodass die Grid-Daten intakt bleiben und der Benutzer den Fehler korrigieren kann.
Die asynchrone Ausführung sollte auf nicht-blockierende Post-Commit-Operationen beschränkt werden, wie z. B. das Auslösen einer ausgehenden Benachrichtigung oder den Aufruf einer AIS-OrchestrierungEin Werkzeug zur Automatisierung komplexer Prozesse und zur Integration von JD Edwards mit externen Systemen über REST-Dienste. zur Aktualisierung eines externen Logistiksystems. Bei Datenbank-Schreibvorgängen erfordern Transaktionsverarbeitungsgrenzen synchrone Aufrufe, um sicherzustellen, dass die MiddlewareSoftware, die als Vermittler zwischen verschiedenen Anwendungen, Datenbanken oder Betriebssystemen fungiert. einen Rollback auslösen kann, wenn eine BSFN im Stack einen Fehler ausgibt. Das Mischen von asynchronen Aufrufen innerhalb einer manuellen Transaktionsgrenze (gestartet über Begin Transaction in ER) bricht den Rollback-Mechanismus, wodurch Ihre Tabellen F41021 und F4211 asynchron werden, da der asynchrone Thread außerhalb des Bereichs der übergeordneten Transaktion läuft.
Schritt-für-Schritt ER-Code-Beispiel
Eine häufige Ursache für Speicherkorruption in interaktiven Anwendungen sind Rückstände in lokalen Event Rules (EV) Variablen vor der Ausführung einer Master Business Function. Bevor Sie F0911 Begin Document (B0900049) aufrufen, müssen Sie Ihre Arbeitsvariablen explizit löschen. Weisen Sie numerischen Feldern Null und Zeichenfolgen Leerzeichen zu, indem Sie Zuweisungsanweisungen in Form Design Aid verwenden. Das Überspringen dieses Schritts ermöglicht es, dass Restspeicher aus vorherigen Grid-Zeilenausführungen den aktuellen Aufrufstack verunreinigen, was zu unvorhersehbaren Fehlern aufgrund doppelter Schlüssel in der Datenbank führt.
Platzieren Sie den Aufruf von B0900049 innerhalb des 'Button Clicked'-Events der OK-Schaltfläche oder des 'Row Exit & Changed - Asynchronous'-Events bei mehrzeiligen Journalbuchungen. Stellen Sie sicher, dass Sie kritische Schlüsselfelder – wie Unternehmen, Belegart und G/L-Datum – direkt von Ihren Form Controls oder Grid-Spalten auf die BSFN-Datenstruktur mappen. Mappen Sie entscheidenderweise eine lokale Variable wie evt_cErrorFlag auf den Parameter cReturnCode der BSFN, um den Ausführungsstatus zu erfassen. Verwenden Sie dieses strukturelle ER-Layout:
// 1. Variablen initialisieren
VA evt_szErrorMessageID = " "
VA evt_cErrorFlag = "0"
// 2. BSFN aufrufen
F0911 Begin Document
FC Company -> szCompany
FC Doc Type -> szDocumentType
FC GL Date -> jdGLDate
VA evt_cErrorFlag <- cReturnCode
VA evt_szErrorMessageID <- szErrorMessageID
// 3. Rückgabecode auswerten
If VA evt_cErrorFlag is equal to "1"
Set Action Code Error
End IfDebugging und Validierung von ER BSFN-Aufrufen
Die Einrichtung eines lokalen Web-Development-Client-Debuggers bleibt der direkteste Weg, um zu isolieren, warum ein Business-Function-Aufruf auf einem Formular fehlschlägt. Entwickler verschwenden oft Stunden damit, den Status von ER-Variablen zu erraten, wenn sie einfach den EnterpriseOne HTML Web Client Debugger starten, das spezifische Formular-Event lokalisieren – wie das Button Clicked-Event der OK-Schaltfläche – und einen BreakpointEin Haltepunkt im Programmcode, der die Ausführung stoppt, damit Entwickler Variablenwerte und den Programmfluss untersuchen können. direkt auf der Zeile mit dem BSFN-Aufruf setzen könnten. Dies ermöglicht es Ihnen, die Runtime-Werte Ihrer Grid Column (GC), Hybrid Column (HC) und Form Control (FC) Variablen unmittelbar vor der Ausführung des Codes durch den CallObject-Kernel zu inspizieren und Mapping-Fehler abzufangen, bevor sie die Datenbank erreichen.
Wenn der Debugger nicht ausreicht, müssen Sie die Datei jdedebug.log analysieren, um den tatsächlichen Grenzübergang von der Präsentationsschicht zur Logikschicht zu verfolgen. Wenn Sie beispielsweise eine Standard-Hauptbuchintegration mit B0900049 (F0911 Start Document) debuggen, suchen Sie im Protokoll nach COB0000012 oder CallObject-Statements, um den Einstiegspunkt des CallObject-Kernels zu isolieren. Diese Protokollzeilen zeigen das exakte 1:1-Mapping der Datenstruktur und weisen sowohl die vom APPL übergebenen IN-Werte als auch die vom C-Code beim Verlassen zurückgegebenen OUT-Werte aus, bis hin zur exakten Zeichenlänge und Dezimalpräzision.
Ein häufiger Fehler bei der Entwicklung benutzerdefinierter APPLs besteht darin, jede zurückgegebene APIApplication Programming Interface; eine Schnittstelle, die es verschiedenen Softwarekomponenten ermöglicht, miteinander zu kommunizieren.-Warnung als fatalen Fehler zu behandeln, der die Transaktionsverarbeitung stoppt. In JDE kann eine Business Function ein Warn-Flag setzen (z. B. eine nicht-fatale Prüfung auf doppelte Rechnungsnummern), während sie dennoch einen Erfolgsstatus von Null zurückgibt. Ihre Event Rules müssen sicherstellen, dass diese Warnmeldungen die Ausführung nicht stoppen, es sei denn, Ihre spezifischen Geschäftsanforderungen schreiben einen harten Stopp vor. Dies verhindert unnötige Formularsperren und bewahrt den Standard-Transaktionsfluss.
Die Wartung eines Bestands an benutzerdefinierten Objekten von 5.000 bis 15.000 Objekten erfordert diese präzisen BSFN-Aufrufmuster, um Systemstabilität und nahtlose Upgrades zu gewährleisten.
