La plupart des équipes JDE considèrent l'Object Management WorkbenchOutil centralisé de JD Edwards pour la gestion du cycle de vie des projets et du code source. comme une simple interface de contrôle de code source dotée de boutons de check-in et check-out. En réalité, gérer le cycle de vie d'un projet JD Edwards OMW, du développement à la promotion, consiste à orchestrer une machine à états relationnelle entre l'attribution de jetons (tokens), les modifications de spécifications dans les Central ObjectsRéférentiel en base de données stockant les spécifications et définitions centrales des objets JDE. et la synchronisation des pathcodesEnvironnements logiciels de JDE (comme DV, PY ou PD) associant des répertoires de code et des bases de données. via les tables de contrôle F98220 et F98222. Traiter ce processus avec négligence explique pourquoi environ 15 % à 20 % des échecs de promotion de développements spécifiques proviennent directement de jetons orphelins, de fichiers d'en-tête C BSFNBusiness Function : composant logiciel exécutant la logique métier dans JD Edwards. non validés ou d'une dérive silencieuse des spécifications locales.
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.
Page 19 sur 19