Quando una coda batch si blocca sull'Enterprise ServerIl server centrale che esegue la logica applicativa e i processi batch di JD Edwards. alle 2:00 del mattino, il riflesso immediato di molti team è quello di aumentare il numero massimo di job simultanei nella configurazione dell'ambiente JDEJD Edwards, un sistema ERP (Enterprise Resource Planning) di Oracle per la gestione aziendale.. Nove volte su dieci, si tratta di una diagnosi errata. Il vero collo di bottiglia è quasi sempre un layout Report Design Aid (RDA)Lo strumento di sviluppo integrato in JD Edwards per progettare report e processi batch. difettoso che esegue milioni di fetchL'operazione di recupero di una o più righe di dati dal database. di database non indicizzati. Unire la tabella F4111 Item Ledger alla F0911 General Ledger in una singola Business ViewUna vista logica che definisce la relazione e i campi selezionati tra una o più tabelle del database. personalizzata senza una corrispondenza rigorosa degli indici trasforma quella che dovrebbe essere un'esecuzione batch di 90 secondi in un blocco della coda di 4 ore.
Padroneggiare la progettazione di report personalizzati JDE UBE per evitare job lunghi richiede di affrontare la causa principale nella logica delle Event RulesIl linguaggio di programmazione visuale utilizzato in JD Edwards per definire la logica di business. molto prima che il codice raggiunga la pipeline di Package BuildIl processo di compilazione e pacchettizzazione del codice personalizzato per la distribuzione sui server.. Spostare l'I/O a livello di riga fuori dalla Do SectionLa sezione principale di un report che viene eseguita ciclicamente per ogni record elaborato., eliminare le colonne di tabella non necessarie dalle Business Views e rilasciare correttamente gli handle di memoria delle C BSFNBusiness Function scritte in linguaggio C per eseguire logiche complesse ad alte prestazioni. riduce regolarmente i tempi di elaborazione degli UBE dall'80% al 95%. Ecco la checklist di audit tecnico da eseguire sui report personalizzati prima di promuoverli fuori dal pathcode di Development (DV)L'ambiente di sviluppo in JD Edwards utilizzato per creare e testare le personalizzazioni..
Optimize Business Views to Reduce Query Footprint
Gli sviluppatori utilizzano comunemente business view standard come V0911A o creano viste personalizzate che eseguono una SELECT su tutte le oltre 120 colonne della F0911 Account Ledger insieme alla F0006 Business Unit Master. Quando si elaborano 5 milioni di record di transazione, il trasferimento di F0911.GLPOST, F0911.GLALT1 e decine di campi di audit inutilizzati degrada le prestazioni della memoria sull'Enterprise Server e intasa l'interfaccia di rete del database. JDE genera l'SQL utilizzando un elenco esplicito di colonne basato sulla definizione della BSVW, ma una vista con più di 100 campi su due tabelle gonfia comunque le allocazioni di memoria per ogni buffer di riga nel runtime dell'UBE.
Il calo delle prestazioni peggiora quando gli sviluppatori configurano left outer joinOperazione SQL che unisce due tabelle restituendo tutti i record della prima e solo quelli corrispondenti della seconda. tra la F0911 e tabelle secondarie come F0006 o F4111 utilizzando combinazioni di chiavi primarie non indicizzate o criteri di join generici. L'unione su campi non indicizzati costringe l'ottimizzatore delle query del database a eseguire una scansione completa della tabella (full table scanUn'operazione in cui il database legge ogni singola riga di una tabella per trovare i dati, rallentando le prestazioni.) o un hash joinUn metodo utilizzato dal database per unire due tabelle creando una tabella hash temporanea in memoria. ad alto costo su milioni di record, ignorando completamente l'indice composito F0911_1 (GLDCT, GLDOC, GLKCO, GLDGJ, GLJEL). Su un'istanza Oracle Database 19c, una query strutturata in questo modo aumenta regolarmente il tempo di esecuzione dell'UBE da meno di un minuto a oltre due ore.
Crea una Business View dedicata e minimale in Object Management Workbench (OMW)Lo strumento di JD Edwards per la gestione del ciclo di vita degli oggetti e dello sviluppo. contenente solo le chiavi primarie precise e i campi di destinazione necessari per il filtraggio o l'elaborazione. Se il report richiede solo GLAID, GLAA e GLDGJ dalla F0911 per calcolare i saldi della contabilità generale, escludi tutte le altre colonne dalla vista. Ridurre una vista da 120 campi a 10 taglia il payload di rete SQL per riga di circa tre quarti e consente al database di mantenere i blocchi di indice in cache in modo molto più efficiente durante l'esecuzione del batch.
Align Data Selection and Indices for Instant Lookup
Esegui una query sulla tabella F4111 Item Ledger contenente 10 milioni di righe senza far corrispondere le colonne principali di un indice, e l'ottimizzatore del database ricorrerà a una scansione completa della tabella o a una costosa scansione skip dell'indice. I report di inventario personalizzati spesso filtrano sulla data di transazione (ILGLDATE) e sulla filiale/stabilimento (ILMCU) omettendo il codice articolo (ILITM), portando il tempo di esecuzione da pochi secondi fino a 45 minuti. La Data SelectionI criteri di filtro applicati a un report per limitare i dati estratti dal database. in RDA deve rispecchiare rigorosamente la sequenza di colonne da sinistra a destra di una chiave di indice per consentire all'ottimizzatore del database di eseguire una scansione diretta dell'intervallo di indici (index range scanUn'operazione efficiente in cui il database legge solo un intervallo specifico di record usando un indice.) anziché analizzare milioni di blocchi non indicizzati.
Gli operatori di confronto in Report Design Aid determinano se il motore del database utilizza un indice o valuta i record riga per riga. L'uso di criteri come NOT EQUAL TO, CONTAINS o WILD CARD nella Data Selection di RDA sopprime l'ottimizzazione degli indici forzando scansioni complete sulla tabella di destinazione. Quando si interrogano tabelle ad alto volume come F4111 o F4011, la sostituzione di un operatore NOT EQUAL TO sul tipo documento (ILDOTY) con un elenco positivo esplicito — o il filtraggio dei tipi documento non desiderati nelle Event Rules dopo il fetch del record — riduce frequentemente i tempi di attesa dell'I/O del database dall'80% al 90% su Oracle o SQL Server.
L'ordinamento dinamico a runtime è un altro killer silenzioso dell'esecuzione batch. Quando una regola di evento o una sezione di report specifica un Data SequencingL'ordinamento dei dati definito all'interno di un report JD Edwards. che non corrisponde a un indice di database attivo, EnterpriseOne aggiunge una clausola ORDER BY che costringe il database a scrivere set di risultati intermedi in tablespaceLo spazio di archiviazione logico utilizzato da un database per memorizzare tabelle e dati temporanei. temporanei prima di restituire la prima riga. La creazione di un indice di tabella personalizzato mirato in Object Management Workbench (OMW) che corrisponda esattamente sia alla Data Selection di RDA sia al layout di Data Sequencing richiesto elimina il sovraccarico di ordinamento a runtime, consentendo al motore UBE di trasmettere istantaneamente record pre-ordinati.
Eliminate Low-Efficiency ER Logic and Clause Traps
Filtrare i record utilizzando la logica delle Event Rules nella Do Section costringe l'enterprise server a recuperare ogni singolo record dal livello database prima di valutarlo. Se un report di dettaglio delle transazioni scansiona 500.000 righe non corrispondenti sul cardex F4111 e le sopprime utilizzando la funzione di sistema Suppress Section WriteFunzione di sistema che impedisce la scrittura o la stampa di una specifica sezione di report. all'interno di un blocco IF/ELSE delle ER, si paga comunque l'intera penale di latenza di rete e buffer del database per tutte le 500.000 righe. Il motore del database rimane completamente cieco rispetto ai criteri di valutazione, trasmettendo gigabyte sulla rete solo affinché il runtime JDE li scarti riga per riga.
Sposta questa logica di filtraggio nel motore SQL richiamando Set User SelectionFunzione di sistema per aggiungere dinamicamente filtri SQL alla query del report. nella Initialize SectionLa sezione di un report eseguita una sola volta all'inizio del processo per le configurazioni iniziali.. Le funzioni di sistema eseguite durante l'inizializzazione si traducono direttamente in predicati della clausola WHERE di SQL nel payload della query iniziale inviato a Oracle Database o SQL Server. La valutazione delle condizioni a livello di database consente all'ottimizzatore delle query di utilizzare gli indici compositi esistenti, restituendo solo le 20.000 righe rilevanti all'enterprise server ed eliminando istantaneamente oltre il 90% del sovraccarico di rete e memoria.
Sii preciso nella gestione della logica di selezione dinamica dell'utente per evitare l'accumulo di clausole. Chiamare ripetutamente Set User Selection tra i rami logici senza impostare Set Selection Append FlagFunzione che determina se i nuovi filtri devono essere aggiunti a quelli esistenti o sostituirli. per specificare la modalità di sostituzione costringe JDE a concatenare predicati ridondanti nell'istruzione generata. Un report eseguito in un ciclo che aggiunge continuamente clausole AND può facilmente costruire una clausola WHERE di 2.000 caratteri con condizioni ridondanti, confondendo l'ottimizzatore del database e degradando una ricerca su indice altrimenti istantanea in un collo di bottiglia batch di diverse ore.
Move Row-Level I/O Operations Out of Do Section
Inserire un'operazione di I/O su tabella all'interno della Do Section di un UBE è l'errore singolo più comune che causa l'esecuzione di report batch aziendali per ore anziché minuti. Considera un tipico report di transazione di inventario che scansiona 500.000 record nella tabella F4111. Se uno sviluppatore inserisce un Fetch SingleOperazione di database che recupera un singolo record specifico basato su una chiave univoca. esplicito sulla F4101 Item Master all'interno della Do Section per recuperare il testo di ricerca o il tipo di stoccaggio, il processo batch esegue 500.000 query SQL individuali sulla rete. Ogni round trip introduce latenza del database, convertendo una query da meno di cinque minuti in un job batch di diverse ore che blocca le risorse dell'enterprise server e rallenta le code di esecuzione dei thread del database.
Combinare le letture di tabella richieste nella Business View sottostante della sezione rimuove istantaneamente quelle centinaia di тысячи di chiamate di database discrete. L'unione della F4101 alla tabella driver primaria F4111 a livello di vista sposta l'onere sul motore del database, che recupera il dataset unito tramite un singolo cursore di database utilizzando piani di esecuzione precompilati. Se la logica condizionale impedisce un join di vista statico — come le ricerche di corrispondenza opzionali — carica i dati di destinazione in una cache di memoria API basata su C durante la Initialize Section, oppure interroga le variabili di ambiente locali una volta per interruzione di livello (level breakEvento che si attiva quando cambia il valore di un campo di ordinamento, usato per subtotali o intestazioni.) anziché una volta per riga.
Evita di utilizzare le Event Rules per costruire cicli di iterazione manuali con i comandi Select e Fetch Next su tabelle ausiliarie come la F4074 o la F0911 durante l'esecuzione delle righe. Gli sviluppatori scrivono frequentemente questi cicli ER manuali per aggregare rettifiche di prezzo o importi di libro mastro, inconsapevoli del fatto che stanno moltiplicando la latenza delle query su ogni singolo record di dettaglio. Configura Level Break Headers e Level Break Footers per gestire i subtotali e le aggregazioni progressive in modo nativo all'interno del motore UBE. Lasciare che il runtime gestisca le interruzioni di sezione basate su eventi elimina gli accumulatori ER personalizzati e rimuove milioni di handle di tabella non necessari durante le grandi esecuzioni batch.
Manage Cache Handles and C Business Function Memory
Un report aziendale che elabora 100.000 record fallirà silenziosamente o trascinerà l'enterprise server nel paging del kernel se le Business Function in C personalizzate eseguite nella Do Section lasciano orfani i loro puntatori di cache. Chiamare jdeCacheInitFunzione API in C di JD Edwards utilizzata per inizializzare una cache in memoria. o jdeCacheAddItem all'interno di un ciclo di Event Rules senza eseguire un corrispondente jdeCacheTerminate o jdeCacheFreeCursor al completamento della sezione fa sì che l'impronta di memoria del processo cresca linearmente con il numero di righe. Un processo RUNBATCHIl processo di sistema sui server JD Edwards che esegue i report e i job batch. che cresce da un valore iniziale di 40 MB a oltre 3 GB durante l'esecuzione è quasi sempre causato da allocazioni heap non rilasciate all'interno del codice C legacy.
Lo stesso degrado della memoria si verifica quando gli sviluppatori utilizzano le funzioni di sistema Open TableFunzione di sistema per aprire manualmente una tabella di database all'interno delle Event Rules. o handle di database grezzi all'interno delle Event Rules e non riescono ad associarli a una chiamata esplicita Close Table nella End Section o nell'evento Destroy Global Bank. Lasciare un handle di tabella non chiuso per iterazione causa la perdita di cursori di database sul server del database, bloccando al contempo gli oggetti handle nella memoria del middleware JDE. Su un'esecuzione batch di 250.000 righe, questo esaurimento degli handle causa regolarmente il blocco del pool di connessioni al database, facendo fallire i job paralleli sull'enterprise server.
Se gestite correttamente, le strutture jdeCache in memoria offrono straordinari miglioramenti delle prestazioni anziché perdite di memoria. Memorizzare nella cache i dati di convalida statici — come le costanti di filiale/stabilimento da F41001 o i record di corrispondenza — in un handle di cache C globale durante la Initialize Section elimina completamente le chiamate di I/O ridondanti. Sostituire 100.000 singole operazioni SQL SELECT con ricerche tramite puntatori di memoria riduce la latenza delle chiamate al database dall'80% al 90% sulle esecuzioni batch ad alto volume, riducendo i tempi di esecuzione da ore a minuti.
Execute Pre-Flight SQL Profiling in Debug Logs
Non promuovere mai un UBE personalizzato fuori da Development (DV) senza acquisire un jdedebug.logIl file di log dettagliato generato da JD Edwards per il tracciamento e il debug delle attività e delle query SQL. a livello di traccia durante un'esecuzione di test rappresentativa. Aprire il log e ispezionare l'istruzione SQL SELECT letterale costruita dal middleware JDE — in particolare la clausola WHERE — rivela scansioni complete della tabella nascoste su tabelle con milioni di righe come la F0911 o la F4111 prima ancora che il codice tocchi Prototype (PY)L'ambiente di test e collaudo in JD Edwards. o Production (PD)L'ambiente di produzione live in JD Edwards utilizzato dagli utenti finali.. Gli sviluppatori spesso presumono che il motore UBE utilizzi l'indice selezionato in Report Design Aid (RDA), ma una selezione dati complessa nelle regole di evento o sovrascritture SQL dinamiche possono rimuovere silenziosamente i vincoli dell'indice, costringendo il motore del database a eseguire costose scansioni di tabella.
Quantifica le prestazioni in DV calcolando le metriche del tempo di esecuzione per ogni 10.000 record elaborati. Sottraendo il timestamp della prima chiamata API FET (fetch) dall'ultima chiamata di fetch nel log si ottiene il tempo effettivo del database rispetto al sovraccarico di elaborazione delle Event Rules. Se l'elaborazione di 10.000 righe richiede più di 1,5 - 2,0 secondi a livello di database durante l'esecuzione delle specifiche locali, la selezione dell'indice o la condizione di join è errata. Risolvere questo problema a livello di workstation richiede pochi minuti; risolvere i problemi di un job batch in esecuzione che blocca la F0101 o la F4211 in Production costa migliaia di euro in termini di impatto operativo.
Quando si progettano report di estrazione che scrivono direttamente su tabelle di lavoro personalizzate, file CSV o interfacce di esportazione, disabilita completamente il motore di rendering di RDA. Attivare la chiamata alla funzione di sistema "Suppress Section Writing" sulle sezioni di dettaglio e contrassegnare le sezioni di utilità come "Hide Section" riduce il sovraccarico di elaborazione dal 30% al 50%. L'Enterprise Server consuma cicli di CPU significativi per formattare i buffer delle pagine PDF, valutare le metriche dei caratteri e calcolare il numero di righe, anche se l'output batch non viene mai stampato. Disattivare gli elementi di rendering visivo trasforma un report pesante dal punto di vista del layout in un processo batch snello e ad alta velocità.
L'applicazione di questi standard di checklist prima di promuovere le specifiche batch personalizzate fuori da DV garantisce che i tempi di esecuzione dei report rimangano nell'ordine dei minuti, anziché bloccare le code aziendali per ore.
