Ein benutzerdefinierter Batch-Bericht, der über 100.000 F0911Die zentrale Tabelle für Hauptbuchtransaktionen in JD Edwards.-Datensätze verarbeitet, sollte nicht vier bis sechs Stunden laufen. Wenn dies der Fall ist, liegt die Ursache selten an der Datenbankindizierung oder an Hardwarebeschränkungen, sondern an einer mangelhaften Konstruktion der Event Rules (ER)Die proprietäre Skriptsprache von JD Edwards zur Definition von Geschäftslogik.. Ein systematisches JD Edwards UBEUniversal Batch Engine; das Werkzeug in JD Edwards zur Erstellung von Berichten und zur Stapelverarbeitung von Daten. Performance-Tuning zur Reduzierung von Tabellenzugriffen erfordert die Abkehr von der zeilenweisen Verarbeitung. Häufig platzieren Entwickler Fetch SingleEin Befehl in den Event Rules, der gezielt einen einzelnen Datensatz aus einer Datenbanktabelle abruft. oder Select/Fetch Next Statements innerhalb der Do Section oder Do Loop Events eines UBEs, was den Enterprise Server dazu zwingt, Hunderttausende redundante SQL-SELECT-Statements gegen die Datenbank auszuführen. Durch die Analyse von JDEDEBUG-LogsProtokolldateien, die detaillierte technische Informationen über die internen Abläufe eines JD Edwards-Prozesses aufzeichnen. können wir diese Schleifen isolieren, die Datenselektion der Driver Section präzisieren und die ER-Logik so umgestalten, dass JDE Memory Cache oder benutzerdefinierte C Business FunctionsIn C geschriebene Programme, die komplexe Logik schneller ausführen als Standard-Event-Rules. verwendet werden, anstatt ständige Datenbank-Roundtrips zu verursachen.
