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.

Pourquoi le Data Dictionary est l'artefact d'upgrade à plus fort levier

Chaque form, chaque UBE, chaque BSFNBusiness Function : code C compilé qui s'exécute dans le kernel JDE Call Object. Les structures BSFN sont construites à partir des définitions des Data Dictionary items, donc tout changement DD impose une rebuild des BSFN. dans JDE lit le DD pour savoir comment interpréter les colonnes de la table qu'il touche. La donnée est dans la table ; le sens de la donnée est dans le DD. Quand le DD indique qu'un item est en 15.2 (15 chiffres, 2 décimales) et que la table contient un entier avec décimales implicites, l'application remet la décimale au bon endroit au moment de l'affichage. Changez le nombre de décimales du DD sans reconstruire tout ce qui le référence, et la même ligne de base de données s'affiche soudain comme 100x ou 1/100x de sa valeur réelle.

D'une release à l'autre, Oracle modifie réellement des DD items. Les longueurs augmentent à mesure que le produit standard évolue (des montants devise qui étaient en 15.2 dans d'anciennes releases sont passés en 18.2 dans certaines tables standard). La précision décimale change sur des items de type taux. Certains items sont dépréciés et remplacés par de nouveaux alias. Rien de tout cela n'est catastrophique si vous le trouvez avant le cut-over ; tout devient catastrophique si vous le trouvez après.

Le point de levier est que l'analyse DD est peu coûteuse par rapport au reste de l'upgrade. Quelques requêtes bien cadrées sur F9200, F9202, F9203, F9210 contre les releases source et cible donnent une vue complète en quelques heures, pas en semaines. Ignorez-la, et ces mêmes heures reviendront plus tard sous forme de tickets de support en production — sauf qu'à ce moment-là, le coût inclut aussi la confiance utilisateur déjà perdue.

Le workflow DD en cinq étapes que j'utilise dans chaque upgrade

Le workflow est le même que vous passiez de B9 à 9.2 ou de 9.2 à une release future. Les volumes changent ; les étapes ne changent pas.

Étape un — baseline diff. Exportez F9200 et F9210 de la release source et de la release cible dans deux schémas côte à côte. Une instance JDE typique contient 15 000 à 20 000 DD items, dont environ 12 000 à 15 000 sont livrés par Oracle et le reste est custom. La requête de diff est simple — left join sur FRDTAI/FROMDTAI, signalement de toute ligne où longueur, décimales ou data type diffèrent — mais le volume de résultats est la surprise. Même entre deux ESU consécutives sur la même release, j'ai vu 50 à 150 changements DD livrés par Oracle ; entre releases complètes, le chiffre atteint quelques milliers.

Étape deux — inventaire custom. Chaque DD item custom devrait se trouver dans la plage de préfixes d'alias 55-69. Exécutez SELECT FRDTAI, FRSY FROM F9200 WHERE FRDTAI BETWEEN '55' AND '69' sur la source. Un environnement custom sain contient 200 à 500 items. Tout chiffre au-dessus de 1 000 indique soit un environnement ancien qui a besoin de nettoyage, soit le signe que quelqu'un a créé des DD items dans la mauvaise plage de préfixes. Dans les deux cas, mieux vaut le savoir avant l'upgrade, pas pendant.

Étape trois — scan des conflits. Croisez l'inventaire custom avec le diff Oracle. La plupart du temps, les items custom et Oracle vivent dans des plages de préfixes distinctes et il n'y a pas de collision. Les cas à surveiller sont : des items custom qui copient ou étendent un item standard qu'Oracle a maintenant modifié, et du code custom (BSFN, NER, UBE) qui hard-code un alias standard dont la définition a changé. Le second cas est le plus dangereux parce que le DD item lui-même n'a pas besoin de correction — c'est le code qui l'utilise qui en a besoin.

Étape quatre — plan de retrofit. Pour chaque conflit, trois options : conserver l'alias standard tel qu'Oracle le livre maintenant et adapter le code custom, conserver l'ancien comportement custom et documenter pourquoi, ou fusionner le custom dans le standard si Oracle a désormais intégré ce pour quoi l'item custom avait été ajouté. Chaque option va dans le plan de projet retrofit avec des estimations d'effort et une validation d'un responsable fonctionnel. L'étape quatre, c'est de la documentation — et cette documentation est ce qui vous sauve dans les discussions après le go-live.

Étape cinq — validation post-upgrade. Après l'exécution de l'upgrade, avant que les utilisateurs se connectent : lancez R9202 (Data Dictionary integrity report) sur la release cible, videz les caches de haut en bas depuis le HTML Server jusqu'aux kernels Enterprise Server, reconstruisez les specs pour tout DD item custom qui en a besoin. Contrôlez 10 à 20 items à forte valeur (montants sur F4211, F0411, F0911) avec une requête qui joint la table à F9210 et confirme que le placement des décimales correspond à ce que l'application affiche maintenant.

Les trois changements DD livrés par Oracle qui cassent les upgrades

Parmi tout ce qui change dans le DD entre les releases, trois schémas expliquent presque tous les incidents post-upgrade que j'ai vus.

La longueur a augmenté. Oracle élargit un item existant — généralement un montant ou une quantité — pour supporter des valeurs plus grandes nécessaires à des clients globaux. La colonne de table est modifiée pour correspondre, vos BSFN custom qui allouent un buffer selon l'ancienne longueur compilent encore mais tronquent à l'exécution. La correction est mécanique mais exhaustive : reconstruire chaque BSFN custom qui référence l'alias affecté. La requête XREF (SELECT FOOBNM, FOMODNAME FROM F980011 WHERE FOPONM = 'AMOUNT_ALIAS') donne la liste. L'effort dépend de la taille du patrimoine custom — un petit environnement custom prend 1 à 2 jours ; un site fortement customisé peut demander 1 à 2 semaines de rebuilds.

Les décimales ont changé. C'est le tueur silencieux. Oracle change un item de type taux de 2 décimales à 4 (ou l'inverse), la colonne de base de données ne change pas, les données ne changent pas, mais l'interprétation de l'application change. Chaque rapport, chaque écran, chaque export affiche désormais la valeur avec un facteur 100 d'écart. Le plus brutal : le système ne déclenche aucune erreur. Le nombre s'affiche, il est correctement formaté, il paraît plausible. La finance ne le remarque que lorsque les totaux cessent de se réconcilier. Incluez toujours les items avec changement de décimales dans l'UAT de cut-over avec comparaison numérique explicite avant/après — l'inspection visuelle ne suffit pas.

L'item a été supprimé. Oracle déprécie un alias et livre un remplaçant, en s'attendant à ce que les consommateurs migrent. L'alias déprécié peut rester dans F9200/F9210 pendant une ou deux releases par courtoisie, mais les nouveaux objets utilisent le nouvel alias. Le code custom qui a hard-codé l'ancien alias continue de fonctionner jusqu'à la fermeture de la fenêtre de dépréciation, puis casse. Planifiez la migration pendant l'upgrade lui-même, pas pendant la release qui supprime la ligne dépréciée.

Faire le lien entre les DD items et les objets qui en dépendent

Le DD seul ne vous dit pas ce qui va casser — F980011, la table de cross-reference, le fait. Après chaque checkout qui modifie l'utilisation du DD, JDE met à jour F980011 avec la relation entre les objets et les DD items qu'ils référencent. L'index XREF est reconstruit par R980011 (ou son équivalent moderne sur les Tools Releases actuelles) ; avec un index obsolète, la cross-reference est incomplète et l'analyse d'impact sous-estime.

La requête qui pilote l'analyse est directe :

SELECT FOOBNM, FOMODNAME, FOOBJTYPE
FROM   F980011
WHERE  FOPONM = 'TARGET_ALIAS'
ORDER  BY FOOBJTYPE, FOOBNM;

La sortie est la liste complète des UBE, APPL, NER et BSFN qui référencent l'alias, regroupés par object type. Pour un alias utilisé dans une douzaine d'objets, c'est une revue d'impact claire de deux heures. Pour un alias comme AN8 (Address Number) — référencé dans des milliers d'objets du produit standard — la liste est illisible telle quelle et la meilleure approche est de confirmer qu'Oracle n'a pas modifié la définition de l'item, puis de passer à autre chose. AN8 ne change pas ; les items les plus susceptibles de changer sont ceux spécifiques à un domaine fonctionnel.

Pour les DD items à forte valeur (montants devise, quantités, coût unitaire, taux de change) sur les tables standard finance et distribution, faites la cross-reference manuellement même si le diff indique qu'Oracle ne les a pas modifiés. Les 20 DD items les plus importants méritent chacun 20 minutes d'attention — bien moins cher que de découvrir un retrofit manqué en troisième semaine après le go-live.

Les outils et scripts qui rentabilisent leur coût à chaque upgrade

Quelques outils ciblés transforment l'analyse DD d'un travail de plusieurs jours en un exercice d'une demi-journée. La forme de ces outils est plus importante que leur implémentation spécifique — ce qui compte, c'est de les avoir, et qu'ils survivent entre les upgrades pour être prêts pour le suivant.

Un baseline differ qui consomme deux exports F9200/F9210 et produit un diff catégorisé (changements de longueur, décimales, data type, edit rule, glossaire) est la pièce la plus réutilisée. SQL suffit ; un script de 200 lignes en Python ou pandas donne une sortie de type spreadsheet que l'équipe fonctionnelle peut revoir.

Un script d'inventaire des préfixes custom (la requête 55-69 plus la cross-reference avec F980011) donne l'empreinte DD custom par object type. Tout item avec plus de 100 objets dépendants est signalé explicitement ; tout orphelin (DD item avec zéro référence F980011) est marqué pour nettoyage avant l'upgrade plutôt qu'après.

Un decimal-change validator s'exécute après l'upgrade sur les tables à forte valeur : pour chaque ligne dans, par exemple, F0911, il calcule la valeur affichée avec l'ancienne et la nouvelle définition décimale, et signale toute ligne où les deux diffèrent. Exécuté sur un échantillon de 10 000 à 50 000 lignes, il prend quelques secondes et donne une réponse oui/non sur le fait que l'upgrade ait déplacé l'interprétation des montants.

Ces trois outils combinés transforment le travail DD d'upgrade en une tâche d'ingénierie maîtrisable plutôt qu'en une ligne vague du type « nous vérifierons le DD » dans le plan de projet.

Les erreurs qui prolongent silencieusement un upgrade de plusieurs semaines

La première consiste à traiter l'analyse DD comme une tâche du seul team CNC. Le team CNC possède la promotion technique des changements DD à travers les environnements ; le team fonctionnel possède la décision de savoir si un passage de 2dp à 4dp sur un taux de change est acceptable pour le business. Les deux teams doivent participer à la revue DD, sinon la validation technique met en production des changements que le business n'a jamais acceptés.

La deuxième consiste à ignorer l'inventaire des préfixes custom parce que « nous n'avons pas beaucoup de customisations ». Les environnements JDE anciens accumulent des DD items custom pendant des décennies — items créés par des consultants partis depuis longtemps, items ajoutés pour des projets annulés, items dupliqués parce que deux teams ignoraient leur existence mutuelle. Le premier inventaire d'un environnement de dix ans surprend toujours quelqu'un.

La troisième consiste à faire le diff entre les releases source et cible, mais pas entre la Tools Release actuelle et la Tools Release cible sur la même product release. Les Tools Releases livrent leurs propres changements DD — généralement faibles en volume mais forts en impact parce qu'ils touchent des items runtime standard que chaque objet référence. Le diff de Tools Release est une requête séparée et une revue séparée.

La quatrième consiste à oublier que F9202 et F9203 (alpha description et traductions) nécessitent aussi un passage d'upgrade. Les nouveaux DD items livrés par Oracle arrivent avec des descriptions en anglais et parfois un sous-ensemble de traductions. Si votre environnement est multilingue, la gap analysis post-upgrade sur F9203 évite aux utilisateurs des libellés vides dès le premier jour.

La cinquième consiste à ne pas geler le DD pendant le cut-over. La fenêtre entre le démarrage de l'upgrade et la fin de la validation post-go-live n'est pas le moment pour quelqu'un d'ajouter un nouveau DD item « pour une correction rapide ». Verrouillez P92001 via la sécurité, et déverrouillez-le uniquement lorsque l'upgrade est validé.

Si ce type d'analyse côté upgrade est ce dont vous avez besoin pour votre propre estate JDE, les articles associés sur ce site couvrent les patterns de projet OMW, les scripts custom code analyzer pour le cadrage des upgrades, et le dashboard de risque retrofit qui synthétise ce type de travail pour les steering committees. Le portfolio projets montre où ces techniques ont été appliquées à de vrais upgrades de B9 vers 9.2 et de 9.2 vers des releases futures.