Nelle nostre attività di audit dei codebase JDE 9.2Versione della suite ERP JD Edwards EnterpriseOne di Oracle. personalizzati, riscontriamo regolarmente che una parte significativa dei colli di bottiglia nelle prestazioni delle applicazioni interattive custom — spesso tra il 30% e il 50% — deriva da Form InterconnectMeccanismo tecnico per passare dati e aprire una nuova schermata da un'altra applicazione. implementati in modo errato. Gli sviluppatori spesso configurano una row exitPulsante di navigazione che permette di eseguire azioni specifiche su una riga selezionata in una griglia. JDE APPL per aprire un'applicazione standard correlata come una semplice mappatura punta-e-clicca, ma chiamare un'applicazione standard complessa come P4210 (Sales Order Entry) da una grid personalizzata senza isolare i limiti della transazione può portare a lock di databaseBlocco temporaneo di un record per impedire che altri utenti lo modifichino contemporaneamente. orfani nelle tabelle F41021 o F4211.
Per prevenire questi problemi di locking e i leak di memoriaErrore in cui un programma non rilascia la memoria RAM non più necessaria, rallentando il sistema., è necessario controllare con precisione come le variabili GCGrid Column: variabili che contengono i dati presenti nelle colonne di una griglia JDE. vengono mappate nella struttura FI di destinazione. Questo esempio tecnico dimostra come passare in sicurezza il contesto da una grid personalizzata, gestire i rischi di puntatori nulli nell'evento Dialog Is Initialized della form di destinazione e garantire che l'applicazione chiamante rilasci immediatamente il cursore del database. L'implementazione di queste precise mappature nelle Event Rules (ER)Linguaggio di programmazione visuale utilizzato per definire la logica di business in JD Edwards. elimina i lock fantasma che spesso affliggono le sessioni client HTML multi-thread.
Anatomia di un Form Interconnect da Row Exit
Un punto di fallimento comune nello sviluppo FDAForm Design Aid: lo strumento di sviluppo utilizzato per creare e modificare le interfacce utente in JDE. personalizzato è trattare una row exit come il semplice clic di un pulsante piuttosto che come una transazione consapevole del contesto. Quando un utente seleziona una riga in una grid e clicca su una row exit, il runtime engineIl componente software che esegue le applicazioni e gestisce l'interazione con l'utente. esegue le event rules sottostanti nell'ambito di quella specifica riga, utilizzando le variabili Grid Column (GC). Se l'applicazione personalizzata ha più righe selezionate o se l'utente clicca sulla exit senza una selezione attiva, il runtime passerà valori nulli o errati al Form Interconnect (FI). Per evitare ciò, è necessario convalidare esplicitamente che una riga sia selezionata controllando la variabile di sistema SV Selected_Grid_Row prima di attivare la chiamata.
La meccanica della transizione si basa interamente sulla mappatura di queste variabili GC nella Data Structure (DSTR)Insieme di parametri definiti per scambiare informazioni tra diversi oggetti software. della form di destinazione. Quando si configura il Form Interconnect in FDA, lo strumento espone la struttura ricevente della form di destinazione, che funge da contratto rigoroso tra l'applicazione chiamante e quella ricevente. Tipi di dati non corrispondenti o campi chiave non mappati in questo interconnect non genereranno un errore del compilatore nelle Event Rules, ma causeranno errori di runtime silenziosi o porteranno l'applicazione di destinazione a utilizzare un action code errato, come Add invece di Update. Ad esempio, passare un numero di documento math numeric in un parametro stringa causerà il fallimento silenzioso del caricamento della business viewOggetto che mette in relazione le tabelle del database con l'interfaccia dell'applicazione. della form di destinazione.
Le applicazioni standard come P4210 (Sales Order Entry) o P0911 (Journal Entry) richiedono un set completo di chiavi primarieInsieme di campi che identificano in modo univoco un singolo record in una tabella. per bypassare le schermate iniziali di ricerca (find/browse) e caricare un record direttamente nella form di revisione. Per P4210, ciò significa mappare l'Order Number (DOCO), l'Order Type (DCTO) e l'Order Company (KCOO) dalle colonne della grid personalizzata direttamente ai corrispondenti parametri FI della form di destinazione, tipicamente W4210A o W4210B. Omettere anche una sola chiave, come KCOO, costringe l'applicazione di destinazione a passare a uno stato di interrogazione predefinito o a visualizzare un errore "Record Not Found". Questa mappatura diretta bypassa la tipica latenza di ricerca e selezione, facendo risparmiare agli utenti da 3 a 5 secondi per transazione e prevenendo query di database non necessarie.
Estrarre il Contesto della Riga Selezionata in FDA
Revisiono regolarmente codice FDA personalizzato in cui gli sviluppatori prelevano valori dalle variabili Form Control (FC) o Event Rules (ER) invece che dalle variabili Grid Column (GC) durante l'esecuzione di una row exit. Nell'evento Button Clicked di una Row Exit, il runtime engine punta specificamente alla riga attiva della grid. Se si fa riferimento a una variabile ER obsoleta popolata durante un precedente ciclo 'Grid Rec is Fetched', si passeranno le chiavi sbagliate — come un vecchio numero di Address Book (AN8) o un Order Number (DOCO) — all'applicazione di destinazione. Questo disallineamento si traduce in una schermata vuota o, peggio, nell'aggiornamento del record di database sbagliato da parte dell'utente.
Quando gli utenti selezionano più righe — ad esempio, 5 o 10 righe in una grid di spedizione personalizzata — la logica predefinita per riga singola si interrompe. Per gestire questa selezione in sicurezza, è necessario implementare un ciclo utilizzando le funzioni di sistema Get Selected Grid Row Count e Get Next Selected Row. Inizializzate un contatore usando Get Selected Grid Row Count per determinare se c'è del lavoro da fare, quindi scorrete ogni indice usando Get Next Selected Row per recuperare i valori GC specifici per quel puntatore di riga.
Prima di invocare il Form Interconnect all'interno di questo ciclo, eseguite un controllo rigoroso sui valori nulli per le chiavi GC critiche come Company (CO) o Document Type (DCTO). Il passaggio di una chiave non inizializzata o nulla attiva una query aperta (senza filtri) nelle applicazioni standard di destinazione come P4210 o P4310, che può bloccare la sessione HTML dell'utente o degradare le prestazioni del database sull'Enterprise ServerIl server centrale che elabora la logica di business e le richieste al database.. Se la form di destinazione non supporta la selezione multipla, il codice deve intercettare il ciclo quando il conteggio delle righe supera 1, avvisando l'utente con un messaggio di errore standard JDE invece di generare sequenzialmente più finestre dell'applicazione e mandare in crash il call stack del browser.
Esempio di Codice: Chiamare P4210 da APPL Personalizzata
Nello sviluppo 9.2, collegare un workbench personalizzato come P554211 all'applicazione standard Sales Order Entry (P4210) richiede il rigoroso rispetto delle regole di mappatura di Form Design Aid (FDA) per prevenire leak di memoria o stati di thread interrotti. Quando un utente attiva la row exit, il runtime deve passare la chiave univoca della riga selezionata nella grid direttamente nella data structure della form di destinazione. Per P4210, questa destinazione è tipicamente la form W4210A, che si aspetta una chiave composta da tre campi precisi per individuare il record corretto nelle tabelle F4201 e F4211.
All'interno dell'evento "Row Exit & Changed - Instant" della vostra row exit personalizzata, dovete mappare esplicitamente i valori Grid Column (GC) alle variabili Form Interconnect (FI) di W4210A. La mancata mappatura di tutti e tre i campi chiave — numero ordine, tipo ordine e società ordine — costringe P4210 a inizializzare un ordine vuoto, una fonte frequente di ticket di assistenza. La mappatura esatta delle Event Rules in FDA appare così:
// Chiamata Sales Order Entry (P4210) da Row Exit personalizzata
Call(App:P4210, Form:W4210A)
GC OrderNumber -> FI mnOrderNumber
GC OrderType -> FI szOrderType
GC OrderCompany -> FI szOrderCompany
"2" -> FI cVersionMode
"1" -> FI cActionCodeLa scelta del flag di esecuzione corretto determina il modo in cui il client HTML gestisce lo stack dei thread. Se P554211 deve aggiornare immediatamente la sua grid con quantità o codici di stato aggiornati quando l'utente ritorna, è necessario impostare il Form Interconnect su esecuzione ModalModalità di apertura di una finestra che impedisce di tornare alla precedente finché non viene chiusa.. Questo blocca il thread chiamante, assicurando che l'utente completi il lavoro in P4210 prima che il controllo torni all'applicazione personalizzata dove un evento Press Button(HC Find) può aggiornare la grid. Al contrario, se l'utente ha bisogno di P4210 solo come finestra di riferimento parallela per verificare i dettagli della riga senza bloccare il thread del chiamante, configurate l'interconnect come Non-Modal. Ciò consente all'utente di trascinare la finestra P4210 su un secondo monitor mantenendo attiva la grid P554211 per l'inserimento continuo dei dati.
Errori Comuni nelle Row Exit verso App Standard
Una svista comune in Form Design Aid (FDA) si verifica quando uno sviluppatore passa una variabile vuota o non inizializzata nella struttura della chiave primaria di una form di destinazione. Nelle applicazioni standard come P4101 o P4210, la ricezione di una chiave vuota fa sì che il runtime engine di destinazione passi per impostazione predefinita alla modalità 'Add' invece della modalità 'Update' o 'Inquiry' prevista. Per evitare ciò, è necessario verificare esplicitamente le 'Form Properties' della form di destinazione per assicurarsi che sia configurata per accettare lo specifico action code — come Change o Inquiry — che l'applicazione personalizzata sta passando. Se la form di destinazione non è configurata per consentire l'azione in entrata, il runtime fallirà silenziosamente o porterà l'utente in una schermata di inserimento errata.
La gestione dei limiti delle transazioni tra diverse form è fondamentale per prevenire la contesa del database. Quando si attiva un interconnect modale, l'applicazione chiamata viene eseguita all'interno del thread del chiamante e ne condivide il limite di transazione. Se l'applicazione personalizzata ha già aggiornato un record nella tabella Item Location (F41021) e poi chiama un'applicazione standard come P4112 in modalità modale, l'applicazione secondaria potrebbe tentare di bloccare lo stesso record F41021. Questo disallineamento nei limiti del transaction processingGestione di una serie di operazioni sul database come un'unica unità indivisibile. si traduce in un deadlockSituazione di stallo in cui due processi si bloccano a vicenda aspettando il rilascio di risorse. immediato del database, congelando la sessione dell'utente fino al timeout del database engine.
Un altro problema frequente si verifica quando gli sviluppatori elaborano le righe della grid in sequenza all'interno di un ciclo, ma non riescono a cancellare le variabili della struttura Form Interconnect prima dell'iterazione successiva. Se una riga successiva ha un valore vuoto in un campo come Location (LOCN), la struttura Form Interconnect manterrà il valore della riga precedente. Ciò porta al passaggio di dati obsoleti all'applicazione di destinazione, corrompendo il contesto della transazione secondaria. Cancellare esplicitamente le variabili della data structure all'inizio di ogni iterazione del ciclo è l'unico modo affidabile per garantire l'integrità dei dati attraverso percorsi di esecuzione multi-riga.
Debug dello Stack del Form Interconnect
Quando una row exit verso un'applicazione standard come P4210 non riesce a passare i dati chiave in modo silenzioso, cercare di indovinare quale variabile sia nulla è una perdita di tempo. Aprite il file jdedebug.log locale e cercate direttamente la stringa "Form Interconnect" per isolare gli esatti parametri della data structure passati al runtime. Questa traccia del log espone i valori precisi delle strutture in entrata e in uscita, consentendo di verificare se i valori delle colonne della grid sono stati effettivamente mappati nella data structure della form di destinazione durante l'evento button clicked.
Se i valori appaiono corretti nel log ma la form di destinazione carica comunque dati vuoti, il problema si verifica durante l'inizializzazione dell'applicazione di destinazione. Collegate il debugger C locale e inserite un breakpoint all'interno dell'evento Dialog Is Initialized dell'applicazione standard o nelle business function C sottostanti come B4200310. Ciò consente di scorrere il thread di esecuzione e confermare se le variabili interne dell'applicazione di destinazione stanno sovrascrivendo i valori del form interconnect in entrata prima che la form venga renderizzata.
I disallineamenti delle specifiche (spec) tra gli ambienti causano frequentemente fallimenti silenziosi in cui la row exit funziona nel client di sviluppo ma va in crash sul web. Ispezionate i file e1root.log del server HTML; troverete avvisi di "Form Structure Mismatch" se le specifiche locali sul client di sviluppo non sono allineate con i pacchetti serializzati distribuiti sull'enterprise server. Questo disallineamento si verifica in genere quando uno sviluppatore modifica una data structure di una form standard o aggiunge parametri personalizzati senza ricostruire e distribuire sia i pacchetti client che quelli server.
Quando la row exit viene eseguita perfettamente sulla macchina di sviluppo locale ma fallisce completamente il lancio dell'applicazione standard sul client web HTML, controllate le mappature dell'OCMObject Configuration Manager: strumento che definisce dove risiedono i dati e dove viene eseguita la logica. (Object Configuration Manager). Assicuratevi che le mappature OCM per l'applicazione di destinazione siano attive e puntino alla data source corretta per l'ambiente in cui state testando, come DV920. Una mappatura OCM configurata in modo errato impedirà al runtime engine web di risolvere la chiamata del form interconnect, lasciando l'utente bloccato sulla grid di origine senza alcun feedback visivo.
Affinare la logica delle row exit in Form Design Aid è un passo fondamentale verso la creazione di applicazioni che sopravvivano al prossimo aggiornamento di Tools Release senza interventi manuali. Per i responsabili IT aziendali che gestiscono un parco applicativo JDE personalizzato, stabilire questi rigorosi standard di sviluppo è essenziale per garantire l'aggiornabilità a lungo termine e la stabilità del sistema.
