Che cos’è davvero un Custom Code Analyzer

Togli la connotazione marketing e resta una pipeline che acquisisce tre input e produce un output. Gli input sono il repository del cliente, cioè l’intero path code PDAmbiente di produzione in JDE — quello live. Il suo repository è la fonte di verità sugli oggetti custom che esistono realmente lato cliente. o equivalente, la baseline Oracle della release sorgente e la baseline Oracle della release target. L’output è un verdetto per oggetto: tenere, eliminare, fare retrofit, riscrivere.

L’aritmetica è impietosa. In un’installazione matura, il repository del cliente contiene una lunga coda di oggetti tecnicamente custom ma funzionalmente morti — copie di standard mai deployate, prototipi di una proof of concept del 2014, BSFN clonate durante un’indagine UDC nel 2017. Un analyzer di questo tipo impedisce a tutto questo di arrivare alla fase di sviluppo. Applica prima uno smart filter, e solo ciò che supera il filtro può consumare ore di engineering.

Il verdetto per oggetto è ciò che rende il concetto degno di un nome. Senza di esso tratti tutti i 12.000 oggetti come lavoro; con esso tratti 350 come lavoro e il resto come backup-and-restoreStrategia in cui gli oggetti custom non modificati vengono preservati durante l’upgrade semplicemente copiandoli, senza analisi o lavoro di retrofit.. Stesso upgrade, un sesto del budget.

Perché il termine sembra uno strumento

Perché due o tre vendor, a OpenWorld qualche anno fa, hanno iniziato a proporre prodotti con nomi che includono le parole analyzer, code e JDE. Sono prodotti reali, alcuni buoni, nessuno magico. Ciò che ognuno di questi prodotti implementa internamente è la stessa pipeline concettuale descritta sopra — repository diff, fingerprinting, classificazione — avvolta in una UI.

La confusione che questo crea è costosa. Un CIO sente l’espressione e presume che il team debba acquistare una SKU. Il team inizia a confrontare costi di licenza e perde il punto: il valore sta nella disciplina, non nell’involucro. Uno spreadsheet gestito da un senior consultant che ha fatto otto upgrade da 9.1 a 9.2 batterà una licenza a sei cifre gestita da qualcuno che non ne ha fatto nessuno. Lo strumento viene dopo il metodo.

Tratta questa disciplina come la continuous integration. Nessuno chiede “quale CI devo comprare?” senza prima concordare cosa significhi CI. Qui è uguale. Decidi prima il metodo, poi scegli se implementarlo con una suite di script, un’offerta di un partner Oracle o uno degli strumenti con licenza — in quest’ordine.

Lo smart filter: dove scompare il 95% del lavoro

La prima fase di qualunque analyzer degno del nome è lo smart filter, ed è dove ogni progetto salva sé stesso o spreca il proprio budget. Il filtro lavora su un unico principio: un oggetto merita analisi solo se il cliente lo ha modificato E Oracle lo ha modificato tra la release sorgente e quella target.

Applica questo test a un repository tipico da 12.000 oggetti e circa il 70% viene rimosso subito come obsoleto o duplicato — la coda morta della customizzazione cumulativa. Del 30% che sopravvive, la grande maggioranza è stata toccata dal cliente ma non da Oracle nel delta di versione; questo significa che le modifiche del cliente proseguono invariate, senza lavoro di retrofit. Di ciò che resta, solo 200-500 oggetti cadono nella vera intersezione: modificati dal cliente E modificati da Oracle. Questi sono gli oggetti impattati, e questi sono quelli su cui gli sviluppatori lavorano davvero.

Le regole del filtro sembrano semplici. Non lo sono, perché ognuna richiede una lista di eccezioni. Le versioni UBEUniversal Batch Engine — il motore batch report di JDE. Le UBE custom sono comuni perché ogni cliente ha le proprie esigenze di reporting. vengono filtrate diversamente dai template UBE sottostanti, le aggiunte UDCUser Defined Code — il termine JDE per tabelle codice o lookup. Le aggiunte UDC quasi mai richiedono retrofit, perché Oracle non possiede il namespace. quasi mai richiedono retrofit, e le modifiche alle Business View seguono un percorso diverso dalle view stesse. Fare bene queste regole è l’intera competenza della disciplina.

Fingerprinting: come sapere cosa è cambiato davvero

Lo smart filter dice quali oggetti guardare. Il fingerprint dice cosa è davvero diverso dentro di essi. Questa è la parte che molti team saltano e pagano poi durante i test.

Un diff ingenuo confronta la BSFN del cliente con la BSFN Oracle target e segnala ogni riga diversa. Questo produce rumore che copre il segnale: una variabile custom rinominata appare uguale a una modifica logica. Un confronto basato su fingerprint è strutturale — canonicalizza il codice, rimuove differenze di formattazione, normalizza i nomi variabile all’interno di uno scope e produce un hash della forma semantica. Due oggetti con lo stesso fingerprint sono funzionalmente equivalenti anche se appaiono diversi nell’editor.

La conseguenza pratica: con il fingerprinting puoi distinguere in un solo passaggio tra un vero conflitto e un conflitto fantasma. Un vero conflitto significa che Oracle ha modificato la logica A, il cliente ha modificato la logica A, e le due modifiche interagiscono. Un conflitto fantasma significa che Oracle ha riformattato, il cliente ha rinominato una variabile, e non c’è alcuna interazione reale. I conflitti reali vanno a uno sviluppatore; i conflitti fantasma vengono risolti automaticamente. In un recente passaggio di retrofit abbiamo visto il rapporto fantasma/reale avvicinarsi a tre a uno — la differenza tra tre settimane di sviluppo e una.

Classificazione: il verdetto per oggetto

Una volta capito cosa è cambiato, si classifica. Ogni oggetto sopravvissuto finisce esattamente in uno di quattro bucket, e il bucket determina il lavoro. La fase di classificazione chiude il cerchio e trasforma l’analisi in un piano di progetto.

I quattro verdetti sono: keep — l’oggetto è custom ma la baseline Oracle non è cambiata nel delta, quindi si porta avanti senza lavoro; drop — l’oggetto era custom ma l’equivalente Oracle nella release target copre la stessa funzionalità, quindi si elimina il custom e si usa Oracle; retrofit — Oracle lo ha modificato, il cliente lo ha modificato, le modifiche sono compatibili, quindi si fa merge; rewrite — le modifiche confliggono, oppure la customizzazione assume un comportamento runtime che la nuova Tools Release non fornisce più, quindi si ricomincia.

Il bucket drop è quello che i team sottovalutano. A ogni release Oracle assorbe funzionalità che i clienti avevano costruito custom nelle versioni precedenti: un Orchestrator ora fa ciò che faceva una BSFN custom, un UDO standard sostituisce una form extension custom, un endpoint AIS sostituisce un’interfaccia custom. Un analyzer che non verifica la release target per equivalenti nativi lascia soldi sul tavolo — fai retrofit di codice che avrebbe dovuto essere eliminato. Passando da 9.1 a 9.2.7, in un’installazione matura, il bucket drop rappresenta tipicamente il 10-20% degli oggetti sopravvissuti.

Cosa vive upstream e downstream

La pipeline non esiste in isolamento. A monte ci sono il Planner ESUL’ESU speciale che aggiorna gli schema planner prima che qualunque altro ESU possa essere applicato. È la base del processo di upgrade. e lo snapshot dell’ambiente sorgente — senza uno snapshot pulito l’analyzer non ha input affidabile. A valle ci sono la fase di sviluppo, il passaggio di regression test e il cutover.

L’artefatto che l’analyzer consegna al team dev è ciò che determina le successive 6-9 settimane. Un buon handoff è un work order per oggetto: nome oggetto, verdetto, path della baseline Oracle target, punti di conflitto identificati e stima. Un cattivo handoff è uno spreadsheet da 12.000 righe con una colonna “review needed”. I team che gestiscono bene le connessioni upstream e downstream completano un upgrade da 9.1 a 9.2 in nove settimane di sviluppo; quelli che le sbagliano finiscono in ventisei.

Un’altra cosa sul downstream. L’output dell’analyzer dovrebbe alimentare anche la selezione dei regression test. Se l’analyzer dice che solo 320 oggetti sono impattati, la regressione dovrebbe concentrarsi sui casi d’uso che esercitano quei 320 — non su un full-suite test di sei settimane che rivalida il 90% di un sistema invariato. Questo è il secondo punto in cui la disciplina ripaga, ed è dove la maggior parte dei CIO capisce di aver comprato il metodo giusto.

Cosa significa per il tuo piano di upgrade

Se stai definendo lo scope di un upgrade JDE in questo momento e la proposta davanti a te non descrive una pipeline di analyzer con qualche nome, la proposta è incompleta. L’espressione non deve apparire letteralmente — sinonimi come retrofit analysis, customization assessment o code impact study descrivono la stessa disciplina — ma le quattro fasi della pipeline devono esserci: snapshot, smart filter, fingerprint, classify.

Chiedi al partner di mostrarti il suo analyzer su un campione di cinquanta dei tuoi oggetti. Se riesce a produrre un verdetto per oggetto in un pomeriggio, possiede la disciplina. Se ha bisogno di tre settimane e di un workshop, la riscoprirà sul tuo tempo e sui tuoi soldi. La differenza, in un’installazione matura con dodicimila oggetti custom, è lo spazio tra una fase di sviluppo di nove settimane e una di sei mesi — e quello spazio è esattamente il valore che il concetto serve a catturare.

Se vuoi una seconda opinione su come dovrebbe apparire una pipeline di questo tipo per il tuo repository specifico — la scomposizione del tuo parco custom, il numero realistico di oggetti impattati per il tuo delta e i bucket in cui finirà il tuo retrofit — prenota una consulenza gratuita. Analizzeremo insieme il tuo ambiente e uscirai con un’immagine concreta del lavoro che ti aspetta davvero, e del lavoro che puoi lasciare da parte con sicurezza.