Modificare l'indice di una BSVWBusiness View: un oggetto JD Edwards che unisce una o più tabelle ed espone alle applicazioni e ai report un insieme fisso di colonne e un indice scelto. sembra un intervento da cinque minuti in BVDABusiness View Design Aid: lo strumento JD Edwards usato per definire quali colonne di tabella e quale chiave la Business View espone alle applicazioni., ed è esattamente per questo che rovina più report di qualsiasi altra singola modifica in JD Edwards EnterpriseOne. Una BSVW può essere letta da decine di UBE, APPL e form interconnect; cambiare la sua chiave dall'indice 2 all'indice 4 in OMWObject Management Workbench: la console JD Edwards che controlla check-out, check-in, tracciamento dei progetti e promozione degli oggetti tra path code. cambia l'ordine delle righe visto da ogni consumer e, se anche solo uno di essi si basava sull'ordinamento precedente, hai appena introdotto un difetto dati silenzioso in produzione.

Questa è la procedura che uso per una modifica dell'indice di una BSVW JD Edwards con OMW e BVDA — la sequenza esatta, il controllo delle dipendenze che eseguo prima di toccare l'oggetto e il percorso di rebuild che mantiene pulita la modifica attraverso DVAmbiente di sviluppo in JD Edwards: il path code in cui gli sviluppatori fanno check-out, modificano, compilano ed eseguono unit test sugli oggetti prima della promozione., PYAmbiente Prototype in JD Edwards: il path code usato per integration testing e accettazione utente prima che gli oggetti siano promossi in produzione. e PDPath code di produzione in JD Edwards EnterpriseOne. L'ambiente live in cui gli utenti business registrano transazioni; le modifiche qui vengono distribuite tramite promozione OMW da PY..

Perché una modifica dell'indice BSVW non è mai solo una modifica BSVW

Una BSVW non archivia dati. È una definizione SQLStructured Query Language: il linguaggio standard usato per interrogare e manipolare database relazionali. JDE genera SQL dietro ogni BSVW, fetch e UBE. salvata su una o più tabelle sottostanti, con un indice scelto che determina due cose: la forma della clausola WHERE e l'ORDER BY predefinito. Quando cambi l'indice, per esempio dalla chiave basata sulla data alla chiave basata sul numero documento, le clausole WHERE generate dal runtime cambiano forma, e con loro cambia l'ordine in cui le righe ritornano. Qualsiasi consumer che scorreva i risultati presumendo un ordinamento per data ora li scorre in ordine di numero documento, e aggregazioni, break e logiche di tipo "first record wins" cambiano senza avviso.

Il secondo problema è il numero di consumer. Una singola BSVW usata in un tipico ambiente operativo può alimentare 10–30 UBE e 5–15 application form. Il lavoro di 30 secondi per cambiare la chiave in BVDA diventa un lavoro di 3–4 ore per trovare ogni consumer, aprirlo e confermare che nessuno dipenda dall'ordinamento precedente. Saltare questo passaggio è ciò che trasforma una pulita ottimizzazione dell'indice in un incidente di produzione due settimane dopo, quando i report di aggregazione di fine mese iniziano a inserire righe nel gruppo sbagliato.

Il terzo problema è che l'indice deve esistere davvero sulla tabella sottostante. La finestra "Select Key" di BVDA elenca ogni indice definito sulla tabella primaria a livello di data dictionaryJD Edwards Data Dictionary: il repository centrale delle definizioni dei data item (tabelle Fxxxx, campi work GTxxxx) che governa validazione, visualizzazione e metadati delle colonne.. Se ti serve una chiave che non esiste ancora, non stai facendo una modifica BSVW — stai facendo una modifica tabella, che è di un ordine di grandezza più invasiva e richiede il coinvolgimento del team CNCConfigurable Network Computing: la disciplina amministrativa di JD Edwards che possiede ambienti, path code, server package e deployment database..

Il controllo delle dipendenze che eseguo prima di toccare l'oggetto

Prima di qualsiasi check-out, esegui la ricerca cross-reference in P980011Applicazione Cross Application Reference Repository in JD Edwards: permette di elencare ogni oggetto (UBE, APPL, NER, BSFN) che fa riferimento a una determinata BSVW, BSFN o tabella. sul nome della BSVW. L'output è l'elenco completo di UBE, APPL e NER che la referenziano. Per ogni consumer, due domande: itera il result set? Ha logica che dipende dall'ordine? Se la risposta a entrambe è sì, quel consumer deve essere inserito nella lista di regressione prima che la modifica venga approvata.

Una scorciatoia utile: leggi direttamente le tabelle F9860 (Object Librarian Master) e F980011 (XREF) con un client SQL. Una query semplice — SELECT FOOBNM, FOMODNAME FROM F980011 WHERE FOPONM = 'V55XXXXA' — ti dà la stessa risposta in un secondo invece di sfogliare i risultati di ricerca OMW. L'indice XREF deve essere ricostruito periodicamente in JDE; se l'ultimo rebuild risale a mesi fa, la lista è obsoleta e perderai consumer aggiunti di recente. Esegui prima il refresh XREF.

Per ogni consumer che dipende dall'ordine, acquisisci uno snapshot "before". Esegui l'UBE in DV contro un dataset congelato, salva l'output. Lo stesso dataset e lo stesso UBE verranno eseguiti di nuovo dopo la modifica; il diff tra i due output è il tuo criterio di accettazione. Saltare questo snapshot è il modo in cui i team finiscono per discutere con gli utenti se il report "sembra diverso" — non c'è misurazione, solo opinioni.

La sequenza OMW e BVDA, passo dopo passo

La meccanica effettiva prevede otto passaggi, tutti in DV, tutti tramite OMW:

1. Apri OMW (P98220W) e individua la BSVW per nome (ad es. V55XXXXA).
2. Aggiungi l'oggetto a un progetto OMW attivo. Se non possiedi un progetto, creane uno; non fare check-out dell'oggetto nel progetto di qualcun altro.
3. Fai check-out della BSVW. OMW avviserà se è già in check-out da un altro sviluppatore — non forzare mai quel lock senza confermare con lui.
4. Aprila in Business View Design Aid (BVDA).
5. Dal menu: View → Select Table Columns. Conferma che la tabella primaria e la lista colonne siano esattamente quelle che ti aspetti. Non cambiare la selezione delle colonne nello stesso checkout di una modifica indice — mantieni le modifiche atomiche.
6. View → Select Key. La finestra elenca ogni indice definito sulla tabella primaria. Scegli il nuovo key item. Annota il numero della chiave che stai lasciando e quello verso cui stai passando; ti serviranno entrambi per il change log OMW.
7. Salva e fai build della BSVW. Un build BSVW è veloce (secondi), ma deve riuscire localmente prima che tu possa fare check-in.
8. Fai check-in. Nel commento OMW, documenta la vecchia chiave, la nuova chiave e il numero di consumer dalla ricerca XREF. Questa è la traccia di audit che ti salva quando qualcuno chiede sei mesi dopo perché l'ordinamento è cambiato.

Se il build fallisce, la causa è quasi sempre che la lista colonne fa ancora riferimento a una colonna che non esiste sulla tabella della nuova chiave — tipico quando la tabella primaria è stata modificata in un checkout precedente e non è stata committata in modo pulito. La correzione è fare revert, non forzare.

Quando l'indice di cui hai bisogno non esiste ancora

Se "Select Key" non mostra l'indice di cui hai bisogno, hai due opzioni, e hanno blast radius molto diversi. Opzione uno: scegliere l'indice esistente più vicino e accettare il compromesso. Opzione due: creare un nuovo indice sulla tabella stessa. La seconda opzione significa una modifica tabella, e una modifica tabella JDE è fondamentalmente diversa da una modifica BSVW.

Una modifica tabella tocca TDATable Design Aid: lo strumento JD Edwards usato per definire colonne tabella, indici, chiavi primarie e per generare il DDL che crea o altera la tabella fisica nel database. (Table Design Aid), genera un nuovo DDL e richiede che il database venga fisicamente ricostruito o alterato in ogni ambiente. Il nuovo indice deve esistere in DV, PY e PD prima che qualsiasi BSVW o UBE che lo punta funzioni. Il deployment è responsabilità del CNC, non dello sviluppatore che ha bisogno dell'indice. Pianifica un ciclo di generazione e deployment del server package di solito pari a 1–3 giorni, a seconda del calendario di rilascio dell'ambiente.

L'altro rischio è che aggiungere un indice a una tabella JDE standard (ad es. F4211, F0911, F4101) sia qualcosa di cui il supporto Oracle discuterà con te se un futuro ESU tocca la stessa tabella. Non stai cambiando colonne di schema — stai aggiungendo un indice — ma l'impatto sul throughput di insert/update su una tabella ad alto volume è reale e misurabile. Aggiungere un indice a F4211 in un'azienda di distribuzione che processa 100.000 righe ordine vendita al giorno è una conversazione CNC, non una decisione solo dello sviluppatore.

Se percorri questa strada: fai check-out della tabella in OMW, apri TDA, aggiungi l'indice con le colonne nell'ordine esatto richiesto dalla forma della clausola WHERE che vuoi, salva e fai build, poi promuovi attraverso i path code standard. Solo allora la BSVW può essere modificata per usarlo. Due progetti OMW separati, due check-in separati, due finestre di deployment separate.

Build e deployment della modifica attraverso DV, PY, PD

Una volta fatto check-in della BSVW in DV, la modifica non è visibile a nessuno tranne che a uno sviluppatore che testa in DV. Per farla arrivare agli utenti finali, il progetto OMW deve essere promosso: DV → PY → PD. Ogni promozione richiede un build del server package guidato dal CNC per il path code di destinazione. Una sola BSVW non richiede un full package build se stai usando specs over JavaSOJ (Specs Over Java): la modalità di deployment JDE in cui le specifiche degli oggetti vengono servite dal deployment server invece di essere incorporate in un full client package, eliminando la necessità di un full package build a ogni modifica. (SOJ) — questo è uno dei principali vantaggi di SOJ, ed è il default su ogni Tools Release moderna.

Negli ambienti abilitati a SOJ, la spec BSVW viene presa dallo store centrale delle spec non appena arriva la promozione OMW. La modifica è live immediatamente per il path code di destinazione. In un deployment non-SOJ (raro sulle Tools Release attuali ma ancora presente in alcuni siti), è necessario un full client package build e deployment prima che la modifica sia visibile — una finestra di build da 30–60 minuti a seconda della dimensione dell'ambiente.

Il test di regressione avviene in PY, non in DV. PY ha volumi dati simili alla produzione e gli UBE consumer effettivi schedulati nel modo in cui li eseguono gli utenti. Esegui ogni consumer nella lista di regressione contro lo snapshot congelato preso prima della modifica. Confronta riga per riga. Solo dopo che ogni consumer corrisponde alle aspettative la modifica ottiene il via libera per PD.

In PD, la finestra di deployment è quella prevista dalla tua policy di change management. La modifica BSVW in sé impiega pochi secondi ad arrivare. Il rischio non è il deployment — è il primo UBE che gira dopo il deployment e mostra un risultato che nessuno si aspettava. Tieni pronto il progetto OMW di rollback: un secondo progetto che contiene la spec BSVW precedente, in check-in ma non ancora promossa, così un ingegnere CNC può fare demote in pochi minuti se un utente segnala una regressione nella prima ora.

Gli errori che rompono questa procedura nella pratica

La modalità di fallimento più comune è saltare il passaggio XREF. Uno sviluppatore cambia la chiave in BVDA, fa build, promuove e scopre solo due settimane dopo che un UBE di fine mese si basava sul vecchio ordinamento. A quel punto, un intero mese di report è stato emesso con l'ordine righe sbagliato, e riemetterli diventa una conversazione finance, non development.

Il secondo errore è raggruppare una modifica chiave con una modifica colonne nello stesso checkout. Quando qualcosa si rompe, non puoi sapere quale modifica l'ha causato. I checkout atomici non sono burocrazia — sono il modo in cui mantieni semplice la storia del rollback. Una modifica per checkout, un progetto OMW per modifica.

Il terzo è creare il nuovo indice su una tabella JDE standard senza consultare il CNC. Una tabella custom con prefisso B55 è dominio dello sviluppatore; F4211 no. Aggiungere un indice a una tabella standard senza sign-off CNC è una strada verso un indice rimosso silenziosamente durante la prossima applicazione ESU o, peggio, verso un problema di performance in produzione su un percorso di codice che non hai misurato.

Il quarto è trattare la promozione BSVW come un compito puramente da sviluppatore. Negli ambienti SOJ il click è piccolo, ma la modifica raggiunge ogni UBE consumer nell'istante in cui la spec arriva. Non c'è soft launch. La disciplina che rende sicura questa modifica è la lista di regressione e lo snapshot del dataset congelato, non la UI OMW stessa.

Se questo tipo di dettaglio procedurale è ciò che ti serve per il lavoro operativo quotidiano su JD Edwards, gli articoli correlati su questo sito coprono analisi dati SQL su tabelle standard e custom, misurazione delle performance BSFN con log e timing, e i pattern di progetto OMW che rendono sicuri gli ambienti multi-sviluppatore. Il portfolio progetti mostra dove queste tecniche sono state applicate a veri lavori di upgrade e retrofit.