Avviare un debugger CUno strumento software utilizzato dai programmatori per analizzare il codice sorgente e correggere errori durante l'esecuzione. come Microsoft Visual Studio per analizzare una Named Event Rule (NER)Un linguaggio di scripting proprietario di JD Edwards che viene convertito in codice C per eseguire logica di business. è spesso non necessario e dispendioso in termini di tempo. Per la maggior parte degli sviluppatori JD Edwards, un approccio più efficiente al debugging JDE NER consiste nel tracciare le event rules attivate direttamente da una chiamata applicativa utilizzando le funzionalità di logging native del runtime engineIl componente software che gestisce l'esecuzione dei programmi e delle applicazioni durante il loro funzionamento.. Analizzando sistematicamente il call stackLa sequenza ordinata di funzioni o subroutine che il programma sta eseguendo in un determinato momento., la mappatura dei parametri e i codici di ritorno all'interno del log di debug locale, è possibile isolare rapidamente la causa principale dei fallimenti transazionali senza l'onere di compilare simboli di debug o collegare processi esterni.

L'interfaccia APPL-to-NER: Mappare il Call Stack

Quando un utente clicca sul pulsante OK nell'applicazione Sales Order Entry (P4210), il runtime engine esegue un call stack complesso, attivando spesso da 30 a 60 chiamate nidificate di Business Function (BSFN)Routine riutilizzabili scritte in C o NER che eseguono operazioni specifiche all'interno del sistema JD Edwards. e Named Event Rule (NER) all'interno di un singolo confine transazionale. Se la logica personalizzata fallisce durante questo processo, trovare la causa principale richiede la mappatura dell'esatta sequenza della chiamata NER all'interno delle Event Rules (ER) della APPLAbbreviazione utilizzata in JD Edwards per indicare un'applicazione interattiva utilizzata dagli utenti finali.. Gli sviluppatori spesso perdono ore a setacciare i file di log quando dovrebbero prima isolare l'evento specifico, come Post Button Clicked o OK Button Clicked, dove la NER personalizzata è registrata.

Le applicazioni interattive passano i valori alle NER utilizzando un template specifico di Data Structure (DSTR), che in questo scenario è una struttura personalizzata multi-parametro (D554201A) chiamata dalla NER personalizzata N554201A. Un punto di fallimento comune è la discrepanza tra i tipi di dati del Form Control (FC) o della Grid Column (GC) nella APPL e i corrispondenti elementi nel template della NER. Ad esempio, mappare un Form Control stringa di 40 caratteri a un membro della Data StructureUn insieme definito di parametri utilizzato per scambiare informazioni tra diversi oggetti o funzioni. di 30 caratteri (come SZALPH) provoca un troncamento silenzioso della memoria o, peggio, una violazione dell'inizializzazione della memoria che manda in crash il call object kernelUn processo del server JD Edwards responsabile dell'esecuzione delle Business Function e della logica di business. sull'enterprise server.

Per prevenire questi errori di allineamento, verificare sempre la mappatura dei parametri nello strumento Event Rules Design (ERD) prima di generare la NER personalizzata. Se si modifica una Data Structure per aggiungere un parametro addizionale, JDE non aggiorna automaticamente le mappature esistenti nella APPL; le lascia non mappate o disallineate. Riallineare manualmente queste variabili nell'editor ER della APPL ed eseguire una generazione locale è l'unico modo per garantire che il runtime engine inserisca correttamente i parametri nello stack di esecuzione.

Configurare il Runtime Trace per una Cattura Pulita dei Log

Una sessione standard del web client locale in esecuzione su un fat clientUna workstation di sviluppo che contiene una copia locale del software e delle specifiche di JD Edwards. può facilmente generare decine di megabyte di dati di log al minuto, rendendo critica la configurazione precisa del jde.ini locale prima di attivare l'applicazione di destinazione. Se si lasciano le impostazioni predefinite aperte, il sistema inonda il log con comunicazioni middlewareSoftware che funge da intermediario tra diverse applicazioni, strumenti o database per consentire la comunicazione. di sottofondo, seppellendo l'esecuzione specifica della Named Event Rule che è necessario analizzare. Per isolare il percorso di esecuzione, navigare nella sezione [DEBUG] del file jde.ini locale.

All'interno di questa sezione [DEBUG], impostare Output=FILE e DebugLevel=EXT è il requisito fondamentale per catturare i punti granulari di entrata e uscita del motore NER. Il valore EXT garantisce che il runtime JDE registri gli esatti parametri passati nella data structure della business function, insieme ai valori restituiti dopo l'esecuzione. Senza questo livello di dettaglio, si vede solo che la funzione è stata chiamata, ma si perdono i cambiamenti di stato critici delle variabili.

Per mantenere il log leggibile, è necessario disabilitare esplicitamente i componenti di tracciamento non necessari che inquinano l'output. Disattivare il tracciamento SQLIl linguaggio standard utilizzato per comunicare con i database e gestire i dati contenuti. impostando LogSQL=0 nella sezione [DB SYSTEM SETTINGS] e assicurarsi che il tracciamento del security kernel sia disabilitato. L'eliminazione di questi dettagli di fetch del database riduce la dimensione del log di circa due terzi, mantenendo l'attenzione interamente sul flusso di esecuzione delle Event Rules e sul call stack.

Un approccio affidabile consiste nell'utilizzare l'utility JDE AppControl o attivare manualmente lo stato del log di debug subito prima di cliccare sul pulsante specifico o sull'uscita che attiva l'evento applicativo. Il debugging attivo dovrebbe essere eseguito solo per i 3-5 secondi necessari per eseguire la logica di business target. Attivare dinamicamente lo stato del log tramite le APIInterfacce di programmazione che permettono a diverse applicazioni di interagire e scambiare dati tra loro. di runtime o un'utility locale mantiene il file di traccia sotto i 5-10 megabyte, consentendo di aprirlo istantaneamente in qualsiasi editor di testo senza mandare in crash l'applicazione.

Isolare l'Entrata e l'Uscita della NER nel jdedebug.log

Isolare una Named Event Rule personalizzata all'interno di un file di log di grandi dimensioni, spesso di diverse centinaia di megabyte, richiede un filtraggio immediato e chirurgico. Se si cerca la stringa Entering JDE_NER: N554201A, si individuerà l'esatto millisecondo in cui il runtime passa l'esecuzione dall'applicazione interattiva alla logica personalizzata di elaborazione delle vendite. Questo punto di ingresso è accompagnato da un identificatore specifico, come il thread IDUn numero univoco assegnato dal sistema operativo per identificare un singolo flusso di esecuzione all'interno di un processo. 4512, che funge da ancora. È necessario isolare immediatamente questo thread specifico; in caso contrario, i log intrecciati di business function asincrone, UBEProcessi batch di JD Edwards utilizzati per l'elaborazione massiva di dati o la generazione di report. in background o subroutine di sistema in esecuzione su thread paralleli corromperanno l'analisi del percorso di esecuzione.

Una volta isolato le thread 4512, il runtime JDE espone la profondità del call stack utilizzando indicatori di livello nidificati come --> per l'entrata e <-- per l'uscita. Ogni livello nidificato rappresenta un passo più profondo nella gerarchia di esecuzione, come quando N554201A chiama business function standard di vendita come B4200310. Contare questi indicatori a freccia permette di mappare l'esatta relazione padre-figlio delle business function senza tirare a indovinare. Quando si trova il corrispondente marcatore Exiting JDE_NER: N554201A sullo stesso thread, si è delimitata con successo la finestra di esecuzione per quella specifica chiamata.

Confrontare le differenze di timestampUna sequenza di caratteri che indica la data e l'ora esatta in cui si è verificato un evento. tra questi marcatori di entrata e uscita è il modo più veloce per diagnosticare il degrado delle prestazioni. Una singola esecuzione di N554201A dovrebbe essere elaborata in meno di 50-100 millisecondi, ma se il delta tra i marcatori di entrata e uscita si estende a diversi secondi, si è di fronte a un collo di bottiglia critico. Questo ritardo in genere indica fetch personalizzati non indicizzati all'interno di un ciclo Select/Fetch Next o operazioni di I/O su tabella ripetitive e ridondanti all'interno delle event rules. Calcolando questi delta su più iterazioni nel log, è possibile dimostrare se un problema di prestazioni è sistemico o legato a un payload di dati specifico.

Ispezionare la Mappatura dei Parametri e le Data Structure

L'esatto stato della data structure al momento dell'esecuzione è visibile nel jdedebug.log immediatamente dopo la riga Entering JDE_NER. Il motore scarica ogni membro della data structure di destinazione, mostrando esattamente cosa la APPL chiamante ha inserito nello stack. Se si sta risolvendo un problema di calcolo che fallisce solo quando eseguito da una specifica power form, questo dump è il punto in cui isolare il delta tra gli input attesi e quelli effettivi.

Un colpevole frequente in questi dump è un parametro MATH_NUMERIC che arriva come una stringa vuota non inizializzata invece di uno zero pulito. Nelle business function basate su C e nelle NER, uno spazio vuoto in una struttura matematica non diventa automaticamente zero; invece, scavalca la logica di inizializzazione, causando il fallimento silenzioso delle operazioni matematiche a valle o lanciando violazioni di memoria. Quando si ispeziona il log, cercare una riga come IN [1] <Math Numeric> : [] che conferma che l'applicazione chiamante non è riuscita a inizializzare la variabile prima di passarla alla data structure.

I parametri flag di tipo carattere come EV01 richiedono lo stesso scrutinio. Una APPL potrebbe passare una 'y' minuscola invece di una 'Y' maiuscola, o un campo carattere potrebbe contenere uno spazio finale che sfugge alle regole di validazione di base. Il log di traccia espone questi valori letterali all'interno di parentesi quadre, rendendo facile individuare se un'istruzione condizionale all'interno della NER sta fallendo semplicemente perché ha valutato 'y' == 'Y' come falso.

Prima di scorrere oltre il blocco di chiamata, tracciare fino alla corrispondente riga Exiting JDE_NER per verificare i parametri in uscita. Se la logica interna è stata eseguita correttamente, il log deve mostrare i parametri di output popolati con i loro nuovi valori immediatamente prima di questo marcatore di uscita. Se gli output rimangono vuoti o invariati nonostante i log non mostrino errori di database, il problema risiede nel routing condizionale delle event rules interne della NER, non nel livello del database.

Tracciare i Codici di Ritorno e la Propagazione dell'Error Stack

Una NER comunica il suo stato di esecuzione alla APPL chiamante attraverso un protocollo rigoroso di valori di ritorno: ER_SUCCESS (0) indica un'esecuzione pulita, mentre ER_ERROR (2) segnala un errore bloccante. Quando una validazione fallisce all'interno della NER, il motore non interrompe automaticamente le event rules dell'applicazione chiamante a meno che questo codice di ritorno non sia esplicitamente valutato dal chiamante. Nel jdedebug.log, si vedrà questo manifestarsi immediatamente dopo la riga Return value is del blocco di esecuzione della BSFN, dove un 2 indica che la form chiamante deve interrompere la sua sequenza di commit.

All'interno del codice C generato della NER, le Event Rules native come "Set Action Error" si mappano direttamente alle API dell'error stack del motore JDE. Quando si traccia un fallimento di validazione, cercare nel log la riga di tracciamento COB0000012 o la chiamata API jdeErrorSet, che registra lo specifico elemento del Data DictionaryIl repository centrale di JD Edwards che definisce le caratteristiche e le regole di validazione di tutti i campi dati. — come 0002 per "Record Invalid" — direttamente nella memoria del thread. La riga di log mostrerà esplicitamente l'elemento DD di destinazione e la tabella o l'alias associato, confermando che la business function ha registrato con successo l'errore ancor prima che il controllo ritorni al runtime interattivo.

Un errore comune si verifica quando la APPL chiamante sopprime o non valuta questo codice di ritorno, portando a un fallimento silenzioso in cui la schermata si blocca senza visualizzare il classico testo di errore rosso. Questa discrepanza accade perché l'error stack contiene l'elemento DD registrato 0002, ma il flusso di controllo della form scavalca la logica di visualizzazione dell'errore a causa di una variabile di ritorno non mappata nelle Event Rules della APPL. Per risolvere questo problema, verificare che le event rules chiamanti controllino il puntatore di ritorno della BSFN e attivino esplicitamente un Set Action Error a livello di controllo se la NER restituisce 2.

Ricompilare e Distribuire la NER Corretta tramite OWM

Quando si trova il bug di allineamento nella NER personalizzata della Sales Order Entry, ad esempio N554201A, non è sufficiente salvare e uscire dall'Event Rules designer. Gli sviluppatori JDE spesso dimenticano che il salvataggio delle ER aggiorna solo le specifiche; è necessario attivare esplicitamente il processo di generazione all'interno dell'Object Management Workbench (OWM)Lo strumento principale di JD Edwards per la gestione del ciclo di vita degli oggetti, dallo sviluppo alla promozione. per tradurre quelle regole visive nei file sorgente effettivi n554201a.c e n554201a.h. Se si salta questo passaggio di generazione, il compilatore costruirà il vecchio codice C, ignorando completamente le modifiche visive alle ER.

Dopo la generazione, eseguire una build locale della business function all'interno di OWM per compilare il nuovo codice C nella directory runtime del proprio ambiente di sviluppo locale, il che è critico se si utilizza una Tools Release a 64 bit come la 9.2.6. Per testare questa modifica localmente sul client di sviluppo, è necessario bypassare il meccanismo di caching delle specifiche locali. Eliminare il file spec.db locale situato nella directory del path codeUna cartella specifica che contiene i file sorgente e le specifiche degli oggetti per un determinato ambiente (es. DV920). locale (tipicamente sotto E920\DV920\spec\) e riavviare il client Web Dev locale per forzare EnterpriseOne a serializzare le specifiche appena compilate.

Una volta che la validazione locale ha successo, promuovere N554201A tramite OWM allo stato del progetto di test, tipicamente lo stato 26 per il QA. È necessario eseguire una build di un pacchetto di aggiornamento selettivo per il path code di destinazione, come PY920, e distribuirlo sia all'Enterprise Server che alle istanze dell'HTML Server. Saltare questo passaggio di distribuzione è la causa più comune della sindrome "funziona sulla mia macchina", in cui l'enterprise server continua a eseguire la vecchia DLLDynamic Link Library: un file che contiene librerie di funzioni utilizzate da uno o più programmi contemporaneamente. o shared library memorizzata nella cache, portando a fallimenti immediati a runtime.

Padroneggiare il call stack e interpretare l'output del jdedebug.log è essenziale quando si risolvono problemi complessi nella logica NER nelle Tools ReleaseL'insieme di componenti tecnologici e infrastrutturali su cui poggia l'applicazione JD Edwards EnterpriseOne. 9.2.8 e successive. Isolando sistematicamente i thread ID, verificando le mappature dei parametri e monitorando l'error stack, gli sviluppatori possono risolvere i colli di bottiglia dell'integrazione e garantire l'integrità delle transazioni in tutta l'azienda.