La maggior parte dei colli di bottiglia nelle prestazioni delle UBEUniversal Batch Engine, il motore di JD Edwards per l'esecuzione di report e processi batch in background. deriva dal fatto che gli sviluppatori trattano le Event RulesIl linguaggio di programmazione visuale proprietario utilizzato in JD Edwards per definire la logica applicativa. come normale codice procedurale. L'inserimento di una business function COggetto riutilizzabile scritto in linguaggio C per eseguire calcoli o logiche di business complesse. o di una lettura ripetitiva di tabelle nel Do SectionEvento di runtime di una UBE eseguito ciclicamente per ogni record restituito dalla query del database. di un ciclo batch ad alto volume trasforma un'esecuzione di quattro minuti in un sovraccarico del databaseSistema organizzato per la memorizzazione, gestione e recupero rapido dei dati aziendali. di diverse ore. Peggio ancora, il posizionamento errato dei reset delle variabili tra gli eventi di sezione crea una corruzione silenziosa dei dati nelle variabili di accumulo che il debug interattivo standard raramente riesce a individuare.

Per risolvere questo problema è necessaria una solida comprensione di come l'engine di runtime delle UBE controlli l'esecuzione tra gli eventi Initialize SectionEvento di runtime eseguito una sola volta all'avvio di una sezione, prima del recupero dei dati., Do Section e Level BreakEvento attivato quando il valore di un campo chiave cambia durante l'elaborazione sequenziale dei dati.. In questa analisi della logica delle sezioni delle Event Rules di JDE UBE, isoleremo l'esatto ordine di esecuzione tra le sezioni Group, Columnar e Conditional, in modo da poter posizionare l'I/O delle tabelleOperazioni di input/output (lettura, scrittura, aggiornamento) eseguite direttamente sulle tabelle del database., le operazioni di pulizia della cache e le chiamate di soppressione esattamente dove il processore batch se le aspetta.

Il Ciclo di Vita dell'Esecuzione delle Event Rules di Sezione nelle UBE

Il layout visivo in Report Design AidLo strumento di sviluppo visuale di JD Edwards utilizzato per creare e modificare i report UBE. inganna gli sviluppatori, facendo credere che le Event Rules vengano eseguite dall'alto verso il basso così come sono disegnate sullo schermo. In realtà, l'Universal Batch Engine elabora le sezioni attraverso una rigida gerarchia di eventi che inizia con Initialize Section prima ancora che una singola riga di dati venga recuperata dal database. Quando si elaborano i dettagli della contabilità generale dalla tabella F0911 tramite la business viewUna definizione logica che unisce una o più tabelle del database per renderle accessibili alle applicazioni. V0911A, l'Initialize Section viene eseguito esattamente una volta. È qui che si impostano gli override di selezione SQLLinguaggio standard utilizzato per interrogare, gestire e manipolare i dati all'interno di un database relazionale., si azzerano i totalizzatori o si chiamano business function come RetrieveCompanyConstants (B0000007). La mancata comprensione del confine tra il posizionamento visivo in RDA e la sequenza degli eventi a runtime causa la maggior parte dei bug di scope delle variabiliL'ambito di visibilità e validità di una variabile all'interno del codice (es. locale o globale). nei report UBE personalizzati.

Una volta aperto il cursoreUn puntatore logico utilizzato dal database per scorrere e gestire riga per riga i risultati di una query. del database, il Do Section viene eseguito in modo iterativo per ogni singolo record restituito dalla query di sezione. Se una query non riepilogata su F0911 restituisce 250.000 righe di libro giornale, il Do Section viene eseguito 250.000 volte in sequenza. L'inserimento di business function C incondizionate, letture Table I/OOperazioni di input/output (lettura, scrittura, aggiornamento) eseguite direttamente sulle tabelle del database. non indicizzate su F0006 o manipolazioni complesse di stringhe all'interno di questo specifico evento garantisce un grave degrado delle prestazioni, estendendo l'esecuzione del batch da pochi minuti a diverse ore. Il Do Section deve rimanere strettamente riservato alla valutazione a livello di riga, alle assegnazioni di variabili di report e all'invocazione di sezioni condizionali.

Gli sviluppatori commettono spesso l'errore di reinizializzare le variabili di report all'interno del Do Section, causando il reset dei valori aggregati a ogni iterazione. Un'architettura UBE pulita si basa su una rigida separazione: l'Initialize Section imposta i parametri di esecuzione, il Do Section elabora le singole righe e gli eventi di Level Break FooterEvento eseguito dopo l'elaborazione dell'ultimo record di un gruppo, ideale per calcolare e stampare subtotali. gestiscono l'accumulo dei subtotali. Verificare sempre dove si azzerano le variabili nella sequenza degli eventi prima di risolvere problemi di dati mancanti o corrotti nei report.

Logica del Do Section ed Elaborazione dei Dati a Livello di Riga

Una selezione dati principale che restituisce 100.000 righe esegue l'evento Do Section esattamente 100.000 volte. L'inserimento di una query Table I/O non indicizzata su F4102 o l'invocazione di una BSFNBusiness Function: oggetto riutilizzabile scritto in C o Event Rules per eseguire logiche complesse. C pesante come B4200310 all'interno di questo evento crea 100.000 accessi distinti al database o allocazioni di memoria, gonfiando istantaneamente una breve esecuzione batch in un'elaborazione di diverse ore che satura i core della CPU dell'enterprise server. Ogni riga di codice all'interno del Do Section deve essere valutata per il suo costo di esecuzione per riga prima del rilascio.

Il rendering a runtime dipende dall'esatta tempistica procedurale all'interno del Do Section. Le funzioni di sistema che alterano la presentazione del report, in particolare Suppress Section WriteFunzione di sistema che impedisce la stampa o la scrittura nel PDF della sezione corrente del report., devono essere eseguite all'interno di questo evento prima che l'engine batch di JDE scriva il buffer della riga corrente nel flusso PDF. Se la logica di valutazione condizionale si trova al di sotto di una chiamata di sezione nidificata o viene eseguita dopo il completamento dei rami di valutazione, l'engine eseguirà comunque il rendering del record, lasciando righe vuote indesiderate o layout disordinati nel report.

La gestione degli accumulatori tra i confini di esecuzione richiede un rigoroso isolamento degli eventi. Il posizionamento dei reset delle variabili all'interno del Do Section senza controlli condizionali su SV File_IO_Status o flag espliciti di level-break azzera prematuramente i saldi delle righe. Poiché gli eventi di Level Break Footer vengono eseguiti dopo che il Do Section ha completato il passaggio sull'ultimo record di un gruppo, un reset cieco delle variabili in fondo al Do Section azzera gli aggregati matematici proprio prima che l'evento del footer li legga per stampare i subtotali e i totali generali.

Gestione delle Aggregazioni con le Event Rules di Level Break

La logica di aggregazione errata nei report UBE personalizzati rappresenta una parte enorme dei difetti nei riepiloghi finanziari durante gli aggiornamenti di sistema. Allineare rigorosamente le Event Rules ai confini di esecuzione di Level Break HeaderEvento eseguito prima dell'elaborazione del primo record di un nuovo gruppo, ideale per azzerare i totalizzatori. (LBH) e Level Break Footer (LBF) riduce significativamente i difetti di calcolo dei subtotali. Comprendere come l'engine dei report di JDE gestisca questi due eventi elimina gli errori off-by-one e i saldi di riporto fantasma tra le interruzioni di gruppo.

Gli eventi di Level Break Header vengono eseguiti immediatamente prima dell'elaborazione dell'evento Do Section del primo record di un nuovo gruppo. Questa precisa tempistica rende l'LBH l'unico evento valido per azzerare gli accumulatori dei subtotali, come VA sec_MathNumeric_Amount. Reimpostare le variabili all'interno dell'evento footer dopo aver scritto la riga di riepilogo è un difetto comune. In questo modo, l'accumulatore mantiene il valore del primo record del gruppo successivo prima che avvenga il reset, escludendo di fatto quel record iniziale dal calcolo del totale del gruppo.

Gli eventi di Level Break Footer vengono eseguiti solo dopo che l'ultimo record di un gruppo di interruzione è stato completamente elaborato dall'engine. L'LBF funge da unica posizione valida per stampare i subtotali di gruppo, calcolare le medie e scrivere le righe di riepilogo in tabelle personalizzate come F554211. Poiché l'engine differisce l'esecuzione del footer fino a quando il valore del campo di interruzione non cambia, l'esecuzione dei calcoli all'interno dell'LBF garantisce che ogni riga di dettaglio recuperata nel Do Section sia stata accumulata.

L'allineamento di questi eventi richiede una stretta sincronizzazione con le specifiche di data sequenceL'ordine specifico in cui i record vengono estratti dal database e presentati nel report. del report. Se un analista modifica la sequenza dei dati in Report Design Aid senza rivalutare le assegnazioni dei campi di Level Break, l'engine UBE eseguirà gli eventi LBH e LBF in modo imprevedibile. Verificare sempre che la sequenza di level break corrisponda all'esatto ordine delle chiavi di elaborazione nella query della sezione primaria.

Sezioni Condizionali e Controllo Suppress Section Write Control

Contrassegnare una sezione UBE como condizionale la scollega completamente dal ciclo automatico dell'engine. L'engine delle Event Rules non eseguirà mai una sezione condizionale in modo automatico, indipendentemente dalle sue business view associate o dalla selezione dati. È necessario attivare esplicitamente l'esecuzione utilizzando la funzione di sistema Call SectionFunzione di sistema utilizzata per avviare l'esecuzione di una sezione condizionale all'interno di un report. dalle ER di una sezione padre, in genere all'interno del Do Section o di un evento di Level Break.

Questo comportamento diventa potente quando si creano report finanziari complessi di tipo padre-figlio, come un registro dei pagamenti AP che mappa i voucher aperti in F0411 con i record di pagamento in F0414. Posizionando Suppress Section Write nell'evento Do Section della sezione principale guidata da F0411, si valuta la logica prima di eseguire il rendering delle righe. Se un voucher richiede una corrispondenza dettagliata del pagamento, la sezione principale chiama la sezione figlia condizionale guidata da una business view F0414, passa il numero del documento tramite report interconnectMeccanismo per passare parametri e dati tra diverse sezioni di un report o tra report differenti. e lascia che la sezione figlia gestisca l'output. Sostituire le viste piatte multi-tabella con questa struttura nidificata riduce regolarmente i tempi di esecuzione dei batch da oltre mezz'ora a meno di cinque minuti su decine di migliaia di record di voucher, evitando il sovraccarico di outer joinOperazione del database che unisce due tabelle includendo tutti i record di una, anche senza corrispondenze nell'altra. dell'engine del database.

Prestare molta attenzione allo scope delle sezioni per evitare arresti anomali catastrofici del kernel batchIl processo di sistema sul server aziendale che gestisce ed esegue i job batch di JD Edwards.. Se si esegue Call Section dall'evento Do Section della sezione stessa senza valutare flag di terminazione espliciti, o si impostano chiamate circolari tra sezioni padre e figlio, si innescherà una ricorsione infinita. Il processo dell'Enterprise Server esaurirà rapidamente lo space heapArea di memoria dinamica utilizzata dai programmi per allocare risorse durante l'esecuzione., registrerà un ALLOCATION FAILURE nel log della UBE e interromperà istantaneamente il processo RUNUBEIl comando a livello di sistema operativo utilizzato per avviare l'esecuzione di un report batch JDE., lasciando i job batch bloccati a tempo indeterminato nello stato Processing.

Trappole Prestazionali: Table I/O e BSFN nelle ER di Sezione

Inserire una business function come GetUDCBusiness function standard utilizzata per recuperare le descrizioni dei codici definiti dall'utente (UDC). all'interno del Do Section di un report che legge centinaia di migliaia di record su F4211 o F0911 crea centinaia di migliaia di singole istruzioni SQL sulla tabella F0005. In un'installazione enterprise standard, i conseguenti roundtripIl tempo di andata e ritorno di una richiesta dal server applicativo al database e viceversa. del database aggiungono ore di latenza di rete a un'esecuzione batch che dovrebbe completarsi in pochi minuti. L'engine middleware semplicemente non può compensare l'overhead IPCInter-Process Communication, meccanismo che consente a diversi processi di scambiarsi dati e informazioni. dovuto all'inizializzazione ripetuta dei contesti di esecuzione delle BSFN all'interno di un ciclo ad alta cardinalità.

Spostare le ricerche di configurazione statica in variabili a livello di report popolate una sola volta durante l'Initialize Section elimina completamente questo traffico inutile verso il database. Se si stanno valutando codici di categoria fissi, costanti di sistema o decimali di precisione della valuta che rimangono costanti durante l'esecuzione, recuperarli prima che il driver principale della Business View inizi a iterare. Spostare le ricerche ripetitive su F0005 fuori dal ciclo di elaborazione delle righe e inserirle nella logica di Initialize Section produce regolarmente un'accelerazione fino a 10 volte dell'esecuzione del batch su job ad alto volume.

Un secondo difetto di prestazioni e integrità si verifica quando gli sviluppatori inseriscono chiamate Table I/O manuali di Select e Fetch Next all'interno del Do Section senza gestire gli handleUn identificatore o puntatore logico utilizzato per gestire una connessione o una risorsa specifica del database. interni. Se una Select manuale interroga la tabella principale senza una variabile handle esplicita, EnterpriseOne riutilizza l'handle di istruzione implicito assegnato al cursore della Business View. La successiva esecuzione del Do Section tenterà una Fetch Next su un cursore modificato, con conseguente perdita di record, logica di sequenza alterata o terminazione prematura e silenziosa del batch.

Istanziate sempre variabili handle esplicite quando eseguite Table I/O manuali nelle Event Rules di sezione, oppure delegate i join multi-tabella complessi a BSFN C dedicate che gestiscono i propri puntatori HUSER e HREQUEST. Per qualsiasi UBE che elabori elevati volumi di record, il controllo del file jde.log alla ricerca di chiamate JDB_Execute ripetute all'interno dei cicli di sezione isola i colli di bottiglia ER auto-inflitti prima che si perda tempo a tentare l'ottimizzazione degli indici del database.

Esempio di Codice ER Concreto: Aggregazione degli Ordini di Vendita

L'aggregazione di 100.000 record di dettaglio delle vendite F4211 direttamente all'interno delle Event Rules delle UBE richiede una sequenza rigida attraverso tre eventi distinti per evitare la perdita di dati tra i confini degli ordini. Stabilite la vostra business view su F4211 con sequenza primaria su Order Company (SDKCOO), Document Type (SDDCTO) e Document Number (SDDOCO), impostando SDDOCO as your level break field. Nel Level Break Header per SDDOCO, azzerate esplicitamente le variabili matematiche personalizzate prima di elaborare la prima riga del nuovo set di chiavi: VA rpt_mnOrderTotal_MATH16 = 0. Saltare questa reinizializzazione esplicita nell'LBH è la causa più comune di accumulo errato dei totali tra le intestazioni d'ordine nei report personalizzati.

All'interno del Do Section, eseguite i calcoli a livello di riga senza produrre elementi visivi. Accumulate l'importo esteso utilizzando una semplice logica ER: VA rpt_mnOrderTotal_MATH16 = [VA rpt_mnOrderTotal_MATH16] + [BC Amount - Extended Price (F4211)(AEXP)]. Chiamate immediatamente la funzione di sistema Suppress Section Write nel Do Section per eliminare il rendering delle righe di dettaglio, riducendo l'overhead di generazione del flusso PDF dal 60% all'80% nelle esecuzioni batch ad alto volume. Questo sposta interamente il focus dell'esecuzione sui calcoli in memoria anziché sulla generazione del layout.

Il layout di output si attiva esclusivamente nel Level Break Footer per SDDOCO. Mappate VA rpt_mnOrderTotal_MATH16 sulle variabili di visualizzazione del report, eseguite la scrittura della sezione e incrementate l'accumulatore a livello di report: VA rpt_mnGrandTotal_MATH16 = [VA rpt_mnGrandTotal_MATH16] + [VA rpt_mnOrderTotal_MATH16]. Per i calcoli dei totali finali, evitate di utilizzare l'evento End of Section — che può essere eseguito prima del completamento dell'ultimo Level Break Footer su UBE multi-sezione — ed eseguite la scrittura del riepilogo all'interno dell'evento Report Footer o in una sezione condizionale autonoma chiamata direttamente dalla logica di interruzione finale.

Padroneggiare la sequenza di esecuzione delle Event Rules delle UBE — in particolare il modo in cui l'engine di runtime elabora le sezioni nidificate e i join condizionali — è fondamentale quando si ottimizzano le esecuzioni batch che elaborano grandi volumi di record.