Parmi tous les artefacts qui déterminent si un upgrade JD Edwards est livré à temps, le Data DictionaryLa couche de métadonnées JDE qui définit chaque data item — alias, longueur, décimales, glossaire, edit rules. C'est le contrat sur lequel reposent chaque form, BSFN, UBE et intégration. est celui que la plupart des plans d'upgrade sous-estiment. Le DD est l'endroit où les changements Oracle d'une release à l'autre rencontrent votre code custom, et une seule modification du nombre de décimales sur un data item standard, passée inaperçue pendant le cut-over, a déjà coûté à plus d'une équipe finance un mois de travail de réconciliation après le go-live.

Voici comment je traite le Data Dictionary dans un vrai upgrade : comment construire le diff entre la release source et la release cible, comment inventorier les items custom avec préfixe 55-69 qui vous suivront indéfiniment, comment repérer les dérives silencieuses de longueur et de décimales qui cassent le retrofittingLe processus qui consiste à réappliquer des modifications custom au-dessus d'une nouvelle release JDE, après qu'Oracle a livré ses propres changements sur les mêmes objets standard., et comment valider le résultat avant que le premier utilisateur se connecte.

Tout système JD Edwards ayant quelques années d'existence porte en lui une question sans réponse facile : combien des objets personnalisés développés au fil du temps sont encore fondamentalement identiques au standard Oracle dont ils sont issus, et combien ont évolué au point de devenir quelque chose de complètement différent ? Cette question devient urgente lors d'un upgrade, d'une migration ou d'un audit des personnalisations. Dans la plupart des cas, la réponse n'existe pas — parce que personne ne l'a jamais cherchée de façon systématique. Dans cet article, je décris comment j'aborde ce problème dans mon travail, et l'outil propriétaire que j'ai développé pour le résoudre.