La maggior parte dei team JDE tratta l'Object Management WorkbenchStrumento di JD Edwards per gestire il ciclo di vita, il controllo versione e la promozione degli oggetti applicativi. come una semplice interfaccia di controllo versione dotata di pulsanti di check-in e check-out. In realtà, gestire il ciclo di vita di un progetto JD Edwards OMW dallo sviluppo alla promozione significa orchestrare una macchina a stati relazionale basata su token holdBlocco esclusivo che consente a un solo progetto di modificare e rilasciare un determinato oggetto., modifiche alle specifiche dei Central ObjectsDatabase centrale contenente le specifiche tecniche e i metadati di tutti gli oggetti del sistema. e sincronizzazione dei pathcodeInsieme di percorsi di database e file che definisce le specifiche software per un dato ambiente (es. DV, PY, PD). attraverso le tabelle di controllo F98220 e F98222. Trattare questo processo con superficialità è il motivo per cui circa il 15-20% dei fallimenti nelle promozioni custom deriva direttamente da token orfani, file header di C BSFNBusiness Function: modulo di logica applicativa incapsulata, scritto in linguaggio C o NER. non committati o spec driftDisallineamento tra le specifiche salvate sul client locale e quelle archiviate sul database centrale. locali non rilevati.
Ogni sistema JD Edwards che ha qualche anno di vita porta con sé una domanda senza risposta facile: quanti degli oggetti custom sviluppati nel tempo sono ancora sostanzialmente identici allo standard Oracle da cui derivano, e quanti si sono evoluti fino a diventare qualcosa di completamente diverso? È una domanda che diventa urgente quando si affronta un upgrade, una migrazione o semplicemente un audit della customizzazione. La risposta, nella maggior parte dei casi, non esiste — perché nessuno l'ha mai cercata sistematicamente. In questo articolo descrivo come affronto questo problema nel mio lavoro, e lo strumento proprietario che ho sviluppato per risolverlo
Pagina 16 di 16