Una BSFNBusiness Function: un'unità di logica di business riutilizzabile in JD Edwards, scritta in linguaggio C o NER. personalizzata per l'allocazione dell'inventario che elabora da 10.000 a 15.000 righe di ordini di vendita dovrebbe essere eseguita in meno di un minuto. Tuttavia, in molti ambienti JDE 9.2, questa stessa esecuzione richiede più di mezz'ora a causa di un classico anti-pattern: l'esecuzione di istruzioni Select e Fetch Next ripetitive su F4101 o F4102 all'interno di un loop. Quando una Named Event Rule (NER)Un linguaggio di programmazione visuale proprietario di JD Edwards utilizzato per creare logica di business senza scrivere codice C. o una business function C attiva un roundtripIl ciclo completo di una richiesta inviata dal server applicativo al database e la relativa risposta ricevuta. al database per ogni singola iterazione, la latenza di rete tra l'Enterprise Server e il database tierIl livello dell'infrastruttura informatica dedicato esclusivamente alla gestione e conservazione dei dati. degrada gravemente le prestazioni.
Risolvere questo collo di bottiglia richiede molto più della semplice aggiunta di indici SQL Server o Oracle DB. La vera ottimizzazione delle performance JDE BSFN per ridurre l'I/OInput/Output: le operazioni di lettura e scrittura dati tra il sistema e il supporto di memorizzazione. delle tabelle nei loop richiede cambiamenti architetturali, specificamente sostituendo l'I/O del database riga per riga con le API JDE user cacheInterfacce di programmazione che permettono di memorizzare dati temporanei nella memoria RAM per un accesso ultra-veloce. (come jdeCacheInit) o il prefetching dei dati in memoria. Caricando i dati anagrafici in memoria una sola volta, si eliminano migliaia di esecuzioni SQL ridondanti e si riducono i tempi di esecuzione dal 90% al 95%.
Il costo nascosto dell'I/O annidato delle tabelle nei loop
In una Sales Order Entry standard (P42101) o in un UBEUniversal Batch Engine: il motore di JD Edwards per l'esecuzione di report e processi massivi di elaborazione dati. di post-elaborazione batch personalizzato, gli sviluppatori spesso annidano le ricerche nel database all'interno di un loop principale. Ogni singolo JDB_FetchKeyed o istruzione select eseguita all'interno di quel loop attiva un singolo roundtrip di rete e una fase di parsing del database. Questa architettura aggrava la latenza in modo esponenziale perché il middlewareSoftware che funge da intermediario tra diverse applicazioni o tra l'applicazione e il database. deve negoziare un ciclo completo di richiesta-risposta per ogni riga, anche se il server del database ha memorizzato nella cache il piano di esecuzione.
Considera uno scenario che elabora un batch di 5.000-10.000 record, come le rettifiche giornaliere dell'inventario in F4111. Se la business function esegue diverse ricerche su singole righe di tabella — ad esempio, controllando i parametri dell'item branch in F4102, le conversioni delle unità di misura in F41002 e i dettagli della posizione in F41021 — il loop esegue decine di migliaia di operazioni distinte sul database. Questo volume di traffico satura rapidamente la scheda di rete e può paralizzare il kernel JDE CallObjectIl processo di sistema che gestisce l'esecuzione delle Business Function sul server Enterprise., lasciandolo in uno stato di attesa prolungato mentre gli utenti sperimentano blocchi dell'applicazione interattiva.
I team infrastrutturali spesso tentano di risolvere questo degrado delle prestazioni ricostruendo gli indici SQL o regolando i pool di memoria del database. Sebbene una corretta indicizzazione ottimizzi le velocità di lettura del disco, non fa nulla per mitigare la latenza fisica della rete o il context switchingL'operazione con cui la CPU sospende un processo per eseguirne un altro, che se eccessiva rallenta il sistema. della CPU che avviene tra l'Enterprise Server e il database server. Il collo di bottiglia non è la capacità del database di trovare la riga; è il volume di context switch che il kernel CallObject deve eseguire per avviare, eseguire e chiudere migliaia di chiamate API JDB discrete.
Prima di scrivere un'altra riga di codice C o NER, analizza la densità delle transazioni. Se il log di esecuzione mostra migliaia di query SQL sequenziali per una singola transazione interattiva, è necessario rifattorizzare la logica per caricare le tabelle statiche in memoria una sola volta.
Misurare l'overhead con Performance Workbench
Non rifattorizzare mai una riga di codice C o una Named Event Rule (NER) basandoti su un'intuizione su quale tabella stia rallentando le prestazioni del sistema. Per isolare la causa principale, modifica il file jde.ini locale, navigando nella sezione [DEBUG] e impostando Output=FILE insieme a Keep logs=0 per catturare un percorso di esecuzione pulito. L'esecuzione dell'UBE target o dell'applicazione interattiva in questo stato genera un file jdedebug.log dettagliato che può facilmente superare diversi gigabyte, mappando ogni singola chiamata API del database, confine della business function e istruzione SQL eseguita dal kernel call object.
Inserendo questo file di log di grandi dimensioni nell'utility Oracle Performance Workbench, è possibile analizzare milioni di righe di dati di traccia grezzi in pochi minuti. Lo strumento aggrega le metriche di performance, isolando specificamente la durata esatta delle chiamate API JDB_SelectKeyed, JDB_Fetch e JDB_OpenTable. Classifica queste operazioni del database in base al tempo di esecuzione cumulativo, esponendo immediatamente quali tabelle, come una tabella tag personalizzata F551101, stiano generando round-trip sproporzionati durante l'elaborazione.
Un errore diagnostico comune è cercare solo istruzioni SQL pesanti e a lunga esecuzione che richiedono diversi secondi per essere eseguite. Nei colli di bottiglia basati sui loop, vedrai l'esatto contrario: una singola istruzione SELECT su F4101 che viene eseguita in meno di un millisecondo, ma che ha un conteggio di esecuzioni nell'ordine delle decine di migliaia. Questo alto numero di esecuzioni con una bassa durata individuale è la firma definitiva di un collo di bottiglia I/O basato su loop. Identificare questo pattern indica esattamente dove sostituire i fetch ripetitivi del database con una strategia di caching basata sulla memoria prima di promuovere il codice nell'ambiente PY.
Implementazione della JDE Cache per i dati anagrafici statici
Un UBE di elaborazione vendite personalizzato che gestisce decine di migliaia di righe d'ordine non dovrebbe eseguire decine di migliaia di istruzioni SQL SELECT separate contro la F4101 per gli stessi pochi centinaia di articoli ad alta rotazione. Per tabelle statiche o semi-statiche come la F4101 Item Master o la F0010 Company Constants, caricare i dati in una JDE User CacheUn'area di memoria temporanea gestita da JD Edwards per conservare record e ridurre gli accessi al database. una volta per transazione elimina completamente i roundtrip al database. Ciò sposta il collo di bottiglia delle prestazioni dalla latenza di I/O del database — che tipicamente consuma da 2 a 5 millisecondi per query sulla rete — a ricerche in memoria misurate in microsecondi. In un'architettura standard a 3 livelli, questo caching locale previene i ritardi di serializzazione della rete tra l'enterprise server e il database engine.
Le funzioni della JDE Cache API come jdeCacheInit, jdeCacheAdd e jdeCacheFetchPosition memorizzano record strutturati direttamente nello spazio di memoria del kernel CallObject. Quando una business function C inizializza una cache, definisce una struttura di chiave univoca corrispondente agli indici della tabella di destinazione, come lo short item number (ITM) e la branch/plant (MCU). Le ricerche successive bypassano completamente il middleware del database, recuperando la struttura dati F4101 precaricata direttamente dalla RAM locale. Questa architettura scala linearmente, mantenendo tempi di risposta inferiori al millisecondo anche sotto un carico di diverse centinaia di sessioni HTML simultanee.
I guadagni di velocità sono inutili se i server enterprise crashano a causa dell'esaurimento della memoria. Gli sviluppatori devono implementare un rigoroso pattern di pulizia utilizzando jdeCacheTerminate nel blocco di distruzione della BSFN per prevenire memory leakUn errore di gestione della memoria in cui un'applicazione non rilascia la RAM non più necessaria, portando all'esaurimento delle risorse. nel middleware JDE. Se un kernel CallObject elabora migliaia di transazioni senza terminare le sue istanze di cache, questi segmenti di memoria orfani si accumuleranno. Ciò costringerà alla fine a un evento di riciclo del kernel amministrativo, facendo cadere le sessioni utente attive durante le ore di punta operativa. Associa sempre ogni jdeCacheInit a una corrispondente chiamata di terminazione nello stesso thread di esecuzione.
Il pattern Prefetch per le relazioni uno-a-molti
Elaborare migliaia di righe di dettaglio F4211 interrogando la tabella header F4201 all'interno del loop è un classico killer delle prestazioni che si verifica in una significativa maggioranza degli UBE personalizzati di conferma spedizione o fatturazione, nella nostra esperienza circa i tre quarti. Questo pattern di query N+1Un problema di efficienza in cui il sistema esegue una query iniziale e poi una query aggiuntiva per ogni record trovato. genera migliaia di singoli round-trip al database, gonfiando i tempi di esecuzione da secondi a minuti. Il prefetching dei record padre F4201 in blocco prima di entrare nel loop dei dettagli elimina completamente questo traffico database eccessivo.
Invece di eseguire JDB_FetchKeyed all'interno del loop F4211, estrai prima l'elenco univoco dei numeri di documento (DOCO), tipi (DCTO) e società (KCOO). Esegui quindi una singola istruzione SELECT con una clausola IN — o utilizza un join a chiave parziale — per caricare questi record header F4201 in un array di memoria ordinato o in una JDE user cache leggera. Per un tipico batch di 200-500 ordini di vendita, questo sostituisce migliaia di singole istruzioni select del database con una singola scansione dell'indice altamente ottimizzata sulla chiave primaria della F4201.
Una volta che i dati dell'header risiedono nella memoria locale, le prestazioni di ricerca scalano logaritmicamente anziché linearmente. L'iterazione attraverso l'array di memoria ordinato utilizzando un algoritmo di ricerca binariaUn metodo efficiente per trovare un elemento in una lista ordinata, dimezzando lo spazio di ricerca ad ogni passaggio., come la funzione bsearch della libreria C standard, riduce la latenza di ricerca da 2-5 millisecondi per fetch del database a meno di un microsecondo. Se stai elaborando un'interfaccia EDI ad alto volume con decine di migliaia di righe, questa ottimizzazione del prefetch riduce i tempi di esecuzione degli UBE dell'80%-90%, portandoli da diversi minuti a meno di due minuti senza cambiare un singolo indice sul database.
Rifattorizzazione da NER a C BSFN per il controllo della memoria
Le Named Event Rules (NER) sono un importante collo di bottiglia nell'elaborazione ad alto volume perché non hanno accesso diretto alle API JDE Cache. Quando gli sviluppatori devono memorizzare uno stato transazionale temporaneo tra le iterazioni in una NER, sono costretti a utilizzare workaround inefficienti come tabelle di lavoro personalizzate (ad esempio, una tabella F5501UI personalizzata) o viste database ripetute. Questo design pattern introduce pesanti I/O su disco e lock del database, trasformando quella che dovrebbe essere una ricerca in memoria inferiore al millisecondo in un accesso fisico al database di diversi millisecondi per ogni singola iterazione del loop.
Convertire queste NER ad alta frequenza in business function C risolve questa limitazione fornendo manipolazione nativa dei puntatori, definizioni di strutture personalizzate e gestione diretta della memoria. Invece di lasciare che il Toolset generi codice C gonfio e non ottimizzato dietro le quinte, scrivere in C nativo consente di allocare la memoria dinamicamente utilizzando jdeAllocLa funzione API di JD Edwards utilizzata per allocare dinamicamente blocchi di memoria RAM durante l'esecuzione. e definire strutture precise che rispecchiano la logica di business. Questa transizione riduce tipicamente l'utilizzo della CPU sull'enterprise server dal 40% al 60% per i job batch che elaborano grandi set di dati come F4211 o F4111.
Il vero vantaggio architetturale di una BSFN C è la sua capacità di mantenere lo stato attraverso chiamate multiple utilizzando i puntatoriVariabili che contengono l'indirizzo di memoria di un'altra risorsa, permettendo un accesso diretto e veloce ai dati. lpDs->hUser o lpVoid. In una tipica esecuzione di un UBE multi-step, è possibile inizializzare una cache JDE nella prima chiamata, memorizzare l'indirizzo di memoria di quel bucket di cache nel puntatore riservato all'utente e recuperarlo istantaneamente nelle successive chiamate di elaborazione dei dettagli. Ciò elimina l'overhead della ricerca nell'elenco globale delle cache per nome ad ogni invocazione, consentendo l'accesso persistente alla cache attraverso diversi step di esecuzione senza un singolo round-trip al database.
Validazione dei guadagni di performance in ambienti PY
Eseguire la validazione delle prestazioni in un ambiente di Sviluppo (DV) locale con un database ridotto è una perdita di tempo. Per catturare la latenza reale della rete e del database, è necessario eseguire questi test di validazione in un ambiente di Prototipo (PY) che contenga un database ripristinato con dimensioni di produzione. Senza la distanza fisica tra l'enterprise server e il database server, e senza tabelle su scala di produzione come la F0911 o la F4211, i tuoi hit della cache locale maschereranno la latenza del mondo reale che si verifica quando migliaia di utenti simultanei colpiscono il sistema.
Per stabilire una baseline pulita, costruisci un driver UBE semplice e standardizzato — come un report R5501I6 personalizzato — progettato per eseguire la business function target sequenzialmente su un batch di 5.000-10.000 record. Esegui questo driver una volta utilizzando la configurazione BSFN legacy, svuota la cache del database JDE tramite Server Manager per evitare che i risultati memorizzati nella cache alterino l'esecuzione successiva, quindi esegui lo stesso driver con il codice rifattorizzato. Questo confronto diretto isola l'esecuzione della logica di business dai tempi di rendering delle schermate APPL interattive, fornendo file di log puliti e trasparenti nella coda di stampa.
Un rifacimento basato su cache o prefetch di successo deve produrre una riduzione del 90%-95% del tempo di esecuzione del database per essere considerato completo. In una recente ottimizzazione di un loop di disponibilità articoli F41021 durante un aggiornamento alla 9.2, questo approccio specifico ha ridotto il tempo totale di esecuzione della BSFN da oltre dieci minuti a meno di mezzo minuto per un blocco di 10.000 righe. Quando si eliminano migliaia di singole istruzioni SQL SELECT e le si sostituisce con ricerche tramite puntatori di memoria, l'utilizzo della CPU del database si appiattisce e l'overhead del trasporto di rete scende quasi a zero.
Se il tuo parco di codice personalizzato supera i tremila oggetti, il rallentamento cumulativo di un I/O di tabella inefficiente all'interno dei loop BSFN può facilmente rappresentare una parte significativa del tempo di esecuzione degli UBE, nella nostra esperienza da un terzo a metà.
