Standard Event Rules (ER)Eine JD Edwards-eigene Skriptsprache zur Definition von Geschäftslogik direkt in der Entwicklungsumgebung. Table I/OStandardoperationen für den Datenbankzugriff, wie das Lesen, Einfügen oder Aktualisieren von Datensätzen. reicht für interaktive Anwendungen mit geringem Volumen aus, versagt jedoch bei Workloads mit hoher NebenläufigkeitDie gleichzeitige Ausführung mehrerer Aufgaben oder Prozesse, die auf dieselben Daten zugreifen können.. Wenn 50 bis 100 gleichzeitige Threads von schnellen AIS OrchestratorEin Werkzeug zur Automatisierung von Geschäftsprozessen und zur Integration über moderne REST-Schnittstellen.-Aufrufen oder multithreaded UBEsUniversal Batch Engine; Programme zur Hintergrundverarbeitung von Massendaten oder zur Erstellung von Berichten. auf dieselben benutzerdefinierten F55-Tabellen zugreifen, führt die fehlende explizite Sperrkontrolle von ER zu Dirty ReadsEin Datenbankfehler, bei dem ein Prozess Daten liest, die von einem anderen noch nicht bestätigt wurden. und Primärschlüsselverletzungen. Um Datenkorruption zu verhindern, müssen Entwickler über grundlegende ER hinausgehen und ein striktes C-basiertes JDE BSFNBusiness Function; wiederverwendbare Logikbausteine, die meist in der Programmiersprache C geschrieben sind. Table IO-Muster implementieren, um benutzerdefinierte Tabellen sicher zu lesen und zu aktualisieren.

Durch die Verlagerung dieser Logik in eine C BSFN können Sie APIsApplication Programming Interface; eine definierte Schnittstelle zur Kommunikation zwischen Softwarekomponenten. wie JDB_FetchForUpdate innerhalb expliziter TransaktionsgrenzenDer definierte Anfang und das Ende einer logischen Einheit von Datenbankoperationen, die zusammengehören. nutzen. Dies stellt sicher, dass ein Datensatz auf Datenbankebene von dem Moment an gesperrt ist, in dem er gelesen wird, bis JDB_CommitTransaction oder JDB_RollbackTransaction ausgeführt wird. Nach unserer Erfahrung reduziert der Ersatz von Standard-ER-Updates durch dieses Muster in Hochvolumenschnittstellen Datenbank-DeadlocksEin gegenseitiger Blockadezustand zweier Prozesse, die jeweils auf die Freigabe einer Ressource des anderen warten. um 70 % bis 80 % und stellt sicher, dass Ihre benutzerdefinierten JDE 9.2-Tabellen die absolute Datenintegrität wahren.

Das Risiko ungesperrter Tabellenaktualisierungen in JDE

In Umgebungen mit hohem Durchsatz ist die Verwendung von Standard Event Rules (ER) Table I/O für Aktualisierungen ein Risiko. Betrachten Sie eine benutzerdefinierte Bestandsallokationstabelle, F55101, die 100 bis 200 gleichzeitige AIS-Sitzungen verarbeitet, die Aufträge von einer externen E-Commerce-Plattform übertragen. Wenn zwei parallele HTML-Sitzungen denselben F55101-Datensatz gleichzeitig abrufen, lesen beide den identischen Anfangsbestand, berechnen ihre jeweiligen Allokationen und schreiben zurück. Der zweite Schreibvorgang überschreibt lautlos den ersten, was zu einem klassischen Concurrency-Fehler führt, bei dem der letzte gewinnt (Last-In-Wins) und Ihr physisches Lagerbuch korrumpiert.

Standard JDE Table I/O in Event Rules verwendet standardmäßig optimistische NebenläufigkeitEin Verfahren, bei dem davon ausgegangen wird, dass keine Konflikte auftreten, und erst beim Speichern geprüft wird. ohne Sperrung auf Datenbankebene. In einer multithreaded CallObject-KernelEin zentraler Serverprozess in JD Edwards, der für die Ausführung von Business Functions zuständig ist.-Umgebung führt dieser Mangel an Schutz bei hohem Transaktionsvolumen zu sofortiger Datenkorruption. Entwickler gehen oft davon aus, dass die JDE-Datenbank-MiddlewareSoftware, die als Vermittlungsschicht zwischen Betriebssystem, Datenbank und Anwendungen dient. dies automatisch handhabt, aber Standard-ER-Update-Anweisungen werden als losgelöste SQL-Operationen ausgeführt. Ohne eine aktive Sperre gibt es keinen Schutz davor, dass ein anderer Thread die Zeile in dem Millisekundenfenster zwischen Ihren Fetch- und Update-Schritten ändert.

Um diese Race ConditionsFehler, die entstehen, wenn das Ergebnis einer Operation von der zeitlichen Ablaufreihenfolge paralleler Prozesse abhängt. und Dirty Reads zu eliminieren, müssen Sie explizites Record Locking mit APIs auf Datenbankebene implementieren. Ein sicheres Update-Muster erfordert das Umschließen sowohl der Fetch- als auch der Update-Operationen innerhalb einer einzigen, atomarenEine Eigenschaft von Transaktionen, bei der entweder alle enthaltenen Schritte erfolgreich sind oder gar keiner. Datenbank-Transaktionsgrenze. Durch die Verwendung von JDB_FetchForUpdate innerhalb einer manuellen Transaktionsgrenze in einer C Business Function hält die Datenbank-Engine eine Sperre auf Zeilenebene vom Moment des Lesens bis zum Commit oder Rollback der Transaktion aufrecht, wodurch konkurrierende Threads gezwungen werden, sich sauber in die Warteschlange einzureihen.

Definition der benutzerdefinierten Tabelle und Datenstruktur

Datenbankintegritätsprobleme in Unternehmensumgebungen resultieren oft aus schlecht typisierten Primärschlüsseln in benutzerdefinierten Tabellen. Für unser F550101-Tabellenschema definieren wir den Primärschlüssel mit einer 15-stelligen Unique Key ID (UKID)Ein systemweit eindeutiger numerischer Identifikator für Datenbankeinträge in JD Edwards. zusammen mit der Belegnummer (DOCO) und der Belegart (DCTO). Diese spezifische zusammengesetzte Struktur, gepaart mit einem benutzerdefinierten Statusfeld, das bedingte Aktualisierungen erfordert, verlangt eine strikte Validierung, um konkurrierende Schreibkollisionen zu verhindern, wenn mehrere Batch-Prozessoren gleichzeitig laufen.

Die Zuordnung der UKID zu einem Standard-MathNumericEin JDE-spezifischer Datentyp zur exakten Darstellung großer Zahlen ohne Rundungsfehler.-Datentyp in der Business Function-Datenstruktur verhindert die stillen Kürzungsfehler, die auftreten, wenn Entwickler numerische Primärschlüssel Standard-C-Integer-Typen zuordnen. Beim JDE-Tabellendesign garantiert die direkte Abstimmung des Datenbankspaltentyps mit den internen Strukturen der API, dass die Runtime-Engine des Enterprise Servers die Werte ohne Präzisionsverlust sowohl auf Linux- als auch auf Windows-Kerneln identisch verarbeitet.

Um sichere Schreibvorgänge zu koordinieren, muss die Datenstruktur der Business Function den Transaktions-PointerEine Variable, die die Speicheradresse eines anderen Objekts oder einer Datenstruktur speichert. und ein Erfolgs- oder Fehler-Flag explizit an die aufrufende interaktive Anwendung oder UBE zurückgeben. Wenn während des Fetch-for-Update-Schritts ein Sperrkonflikt auftritt, weist die Business Function ein spezifisches Return-Code-Flag zu, um den Sperrfehler oder Validierungsfehler zu kommunizieren. Dies ermöglicht es der aufrufenden interaktiven Anwendung, sofort einen Datenbank-RollbackDas Rückgängigmachen von Datenbankänderungen, um einen konsistenten Zustand nach einem Fehler wiederherzustellen. auszulösen oder dem Benutzer eine saubere Fehlermeldung anzuzeigen, anstatt den Call-Stack lautlos scheitern zu lassen. Wir ordnen dieses Flag normalerweise einem 1-Zeichen-Datenelement wie EV01 in der Datenstruktur zu, um die Schnittstelle leichtgewichtig und standardkonform zu halten.

Das sichere Read-Before-Update-Muster in C BSFN

Ein häufiger Fehler in benutzerdefinierten C Business Functions ist die Annahme, dass ein Standard-Fetch einen Datensatz für Änderungen sichert. In Umgebungen mit hoher Nebenläufigkeit, wie z. B. einem großen Logistikzentrum mit Hunderten von gleichzeitigen Benutzern, die parallele Pick-Slip-Bestätigungen ausführen, lesen zwei Threads häufig denselben F554211-Datensatz gleichzeitig, was zu Dirty Writes führt. Um dies zu verhindern, besteht Ihr erster Schritt darin, die Zieltabelle mit der API JDB_OpenTable zu öffnen und dabei explizit das aktive Transaktions-Handle aus der lpBhvrcomEine interne JDE-Struktur, die Kontextinformationen und Transaktionsdaten an Business Functions übergibt.-Struktur zu übergeben, um Rollback-Funktionen zu ermöglichen.

Sobald das Tabellen-Handle aktiv ist, müssen Sie sofort die API JDB_SetBehavior mit der Option JDB_BEHAVIOR_LOCK aufrufen. Dieser spezifische API-Aufruf weist die Datenbank-Engine – egal ob sie auf Oracle 19c oder Microsoft SQL Server 2019 läuft – an, ein Äquivalent zu SELECT FOR UPDATEEin SQL-Befehl, der gelesene Zeilen sofort für andere Schreibzugriffe sperrt. auf der Datenbankebene auszugeben. Ohne dieses explizit gesetzte Behavior-Flag setzt ein Standard-Fetch keine exklusive Sperre auf die Zeile, wodurch der Datensatz anfällig für Dirty Reads durch konkurrierende interaktive Anwendungen oder Batch-UBEs bleibt.

Nachdem das Sperrverhalten etabliert ist, führen Sie JDB_FetchKeyed aus, um den spezifischen Datensatz abzurufen und seinen aktuellen Status zu überprüfen, bevor Sie eine benutzerdefinierte Geschäftslogik anwenden. In einer realen benutzerdefinierten Bestandsbuchungsanwendung stellt dieser Schritt sicher, dass sich die verfügbare Menge zwischen der ursprünglichen Anzeige im Suchgitter und dem tatsächlichen Datenbank-Update-Ereignis nicht geändert hat. Sich auf Bildschirmwerte anstatt auf diesen frischen, gesperrten Fetch zu verlassen, ist der Grund, warum sich Bestandsdifferenzen von 5 % bis 10 % in das System einschleichen.

Wenn der Zieldatensatz bereits von einem anderen Datenbank-Thread gesperrt ist, wird die Datenbank-Engine die Anforderung ablehnen. Anstatt den CallObject-Kernel scheitern oder in einen Timeout laufen zu lassen – was die HTML-Sitzung des Benutzers unter Tools ReleaseDie Version der zugrunde liegenden Systemsoftware und technischen Infrastruktur von JD Edwards. 9.2.8 zum Absturz bringen kann – müssen Sie den Fehler JDB_ERR_RECORD_LOCKED in Ihrem C-Code ordnungsgemäß behandeln. Fangen Sie diesen Return-Code ab, rufen Sie jdeSetGBLError auf, um eine benutzerfreundliche Nachricht an die Standard-JDE-Fehlerwarteschlange zu senden, und beenden Sie die Funktion sauber, um die Systemstabilität zu wahren.

Implementierung von Transaktionsgrenzen und Rollbacks

Eine häufige Katastrophe in Umgebungen mit hohem Volumen, wie z. B. der Verarbeitung von 10.000 bis 15.000 Verkaufsauftragszeilen pro Stunde via EDIElectronic Data Interchange; der standardisierte elektronische Austausch von Geschäftsdokumenten zwischen Unternehmen., ist das Auftreten verwaister Datenbank-Sperren. Um dies zu verhindern, muss die benutzerdefinierte C BSFN ihre Datenbankoperationen explizit an die aktive Transaktionsgrenze des Aufrufers binden. Dies wird erreicht, indem das Environment-Transaktions-Handle aus der lpBhvrCom-Struktur an die APIs JDB_OpenTableUser oder JDB_StartTransaction weitergegeben wird, um sicherzustellen, dass die Operationen der benutzerdefinierten Tabelle an der übergeordneten Transaktion teilnehmen.

Wenn eine Geschäftsregelvalidierung nach dem Abrufen des Datensatzes fehlschlägt – z. B. wenn ein unerwarteter Statuscode 560 anstelle von 520 gefunden wird – müssen Sie sofort einen Rollback auslösen. Der Aufruf von JDB_RollbackTransaction unter Verwendung des aktiven Transaktions-Handles stellt sicher, dass alle vorherigen nicht committeten Inserts oder Updates innerhalb dieser spezifischen Grenze auf Datenbankebene sofort rückgängig gemacht werden. Wenn diese API nicht ausgeführt wird, bleibt die Datenbank in einem inkonsistenten Zustand, in dem verwaiste übergeordnete Datensätze ohne ihre entsprechenden untergeordneten Details existieren.

Sobald die Validierung erfolgreich ist und die Operation JDB_UpdateKeyed einen erfolgreichen JDEDB_PASSED-Status zurückgibt, müssen Sie die Transaktion umgehend committen. Die Ausführung von JDB_CommitTransaction schreibt die Änderungen dauerhaft in die Datenbank und gibt entscheidenderweise die exklusive Datenbanksperre frei. In Umgebungen mit hoher Nebenläufigkeit kann die Verzögerung dieses Commits um nur 200 bis 300 Millisekunden zu einer Lock EscalationEin Vorgang, bei dem die Datenbank viele kleine Sperren in eine einzige große Sperre umwandelt, was die Performance bremst. im SQL Server oder in der Oracle-Datenbank führen, was konkurrierende UBEs und interaktive Anwendungen blockiert.

Ein kritischer Fehler bei der Fehlerbehandlung besteht darin, Bereinigungsroutinen zu umgehen, wenn die Funktion vorzeitig beendet wird. Wenn Sie den C-Code bei einem Validierungsfehler verlassen, ohne JDB_CloseTable aufzurufen, hält die JDE-Middleware das Tabellen-Handle im Speicher aktiv. Dieses Versäumnis verursacht ein stilles Speicherleck im CallObject-Kernel, das typischerweise 15 bis 30 KB pro geleaktem Handle verbraucht, und hält Datenbanksperren auf unbestimmte Zeit offen, bis der Kernel-Prozess recycelt wird.

Code-Beispiel: C BSFN Implementierungsdetails

Bei unseren Audits von benutzerdefinierten C Business Functions finden wir häufig Instabilitäten des CallObject-Kernels, die durch nachlässige Pointer-Initialisierung verursacht werden. Um Speicherkorruption innerhalb der JDE-Runtime zu verhindern, müssen Sie lokale Variablen, einschließlich des HUSER-User-Handles und des HREQUEST-Tabellen-Request-Handles, explizit mit Standard-APIs wie memsetEine Programmierfunktion, die einen Speicherbereich mit einem bestimmten Wert (meist Null) vorinitialisiert. initialisieren. Wenn Sie diese Pointer uninitialisiert lassen, wird ein multithreaded CallObject-Kernel auf Ihrem Enterprise Server schließlich auf veraltete Speicheradressen verweisen, was zu zeitweiligen Abstürzen führt, die im Server Manager schwer zu isolieren sind.

Sobald Ihr User-Handle etabliert ist, erfordert das Öffnen der benutzerdefinierten Zieltabelle einen Validierungsschritt, den Entwickler oft überspringen. Sie müssen den Rückgabewert von JDB_OpenTable explizit gegen JDEDB_PASSED prüfen. Ein Fehler an dieser Stelle deutet auf eine Fehlkonfiguration des OCMObject Configuration Manager; verwaltet die Zuordnung von Objekten zu Datenquellen und Servern in JD Edwards. oder ein zugrunde liegendes Datenbankverbindungsproblem hin. Das frühzeitige Abfangen verhindert nachfolgende Operationen auf einem Null-Request-Handle, was eine fatale Zugriffsverletzung im Kernel auslöst.

Bei der Ausführung des eigentlichen Updates muss der Code die API JDB_UpdateKeyed anstelle generischer Update-Funktionen verwenden. Diese API erfordert, dass Sie die exakte Schlüsselstruktur der benutzerdefinierten Tabelle füllen und übergeben, um sicherzustellen, dass die Datenbank-Engine nur die spezifische Zeile anspricht, die Ihrem eindeutigen Schlüssel entspricht. Durch die explizite Definition der Indexstruktur verhindern Sie, dass die Datenbank zu einem Full-Table-Scan eskaliert, was eine häufige Ursache für Lock Escalation bei der Hochvolumenverarbeitung ist.

Schließlich muss Ihre Funktion alle logischen Pfade durch einen dedizierten Bereinigungsblock am Ende des Codes leiten. Diese Exit-Routine muss JDB_CloseTable und JDB_FreeUser aufrufen, um die zugewiesenen Ressourcen freizugeben. Das Versäumnis, diese Handles freizugeben, verursacht eine kumulative Speicherfragmentierung im CallObject-Kernel, was schließlich zu einem Kernel-Recycle während der Hauptbetriebszeiten führt.

Testen und Validieren der Sperrleistung

Um zu beweisen, dass Ihre benutzerdefinierte C Business Function Nebenläufigkeit ohne Deadlocks bewältigt, starten Sie zwei parallele lokale UBE-Läufe, die auf denselben Datensatzbereich abzielen. Öffnen Sie die resultierenden JDEDEBUG.log-Dateien und suchen Sie gezielt nach der SQL-Anweisung, die SELECT ... FOR UPDATE enthält (oder das Äquivalent WITH (UPDLOCK), wenn Sie auf Microsoft SQL Server arbeiten). Wenn Sie diese exakte Syntax nicht unmittelbar vor Ihrer Update-Anweisung sehen, umgeht Ihr Table I/O den nativen Sperrmechanismus der Datenbank-Engine, wodurch Ihre benutzerdefinierte Tabelle anfällig für Dirty Reads bleibt.

Während der Spitzenzeiten, wenn das Transaktionsvolumen 50.000 bis 100.000 Schreibvorgänge pro Stunde überschreitet, überwachen Sie die Eskalation von Datenbanksperren mit der Oracle-View V$LOCKEine Systemansicht in Oracle-Datenbanken zur Überwachung aktiver Sperren und Ressourcenkonflikte. oder den Dynamic Management Views (DMVs) des SQL Servers. Sie müssen sicherstellen, dass Sperren auf Zeilenebene nicht zu Sperren auf Tabellenebene eskalieren, was Benutzersitzungen in Standardanwendungen wie P4210 oder P4312 zum Stillstand bringt. Wenn eine Eskalation auftritt, liegt dies meist daran, dass die Transaktionsgrenze durch einen schlecht platzierten JDB_CommitTransaction-Aufruf zu lange offen gehalten wird.

Um die Dauer dieser Datenbanksperren zu minimieren, ordnen Sie die benutzerdefinierte BSFN im Object Configuration Manager so zu, dass sie exklusiv auf dem Enterprise Server ausgeführt wird. Die lokale Ausführung der Geschäftslogik auf einem HTML-Server oder einer Workstation führt zu Netzwerk-Hops, die die Sperrzeiten verlängern. Ein typischer sicherer Read-Update-Zyklus innerhalb einer gut abgestimmten Enterprise-Server-Umgebung sollte in weniger als 20 Millisekunden ausgeführt werden, verglichen mit weit über 100 Millisekunden bei der Ausführung über ein WANWide Area Network; ein Weitverkehrsnetzwerk, das geografisch weit auseinanderliegende Standorte verbindet. oder ein schlecht geroutetes Subnetz. Halten Sie diese Netzwerklatenz niedrig, um zu verhindern, dass Lock ContentionEin Leistungsengpass, wenn viele Prozesse gleichzeitig auf dieselbe gesperrte Ressource zugreifen wollen. die Leistung konkurrierender interaktiver Anwendungen beeinträchtigt.

Die Implementierung dieser sicheren Table IO-Muster ist unerlässlich, wenn Sie einen Bestand an benutzerdefiniertem Code von 5.000 bis 15.000 Objekten verwalten. Sicherzustellen, dass Ihr Entwicklungsteam diese Transaktionsgrenzen konsistent anwendet, unterscheidet stabile Unternehmensbereitstellungen von solchen, die von zeitweiligen Datenbanksperren und Kernel-Fehlern geplagt werden. Für einen tieferen Einblick in die Optimierung Ihrer benutzerdefinierten C-basierten Business Functions kontaktieren Sie unser Enterprise-Architecture-Team, um ein Code-Audit zu vereinbaren.