Pourquoi les objets standard copiés faussent le périmètre d’upgrade

Les objets standard copiés gonflent le périmètre d’upgrade, car les équipes traitent souvent chaque objet copié comme du code custom critique pour l’activité. Dans un environnement JDE réel, cette hypothèse est rarement sûre. Certains objets APPLObjet applicatif interactif JD Edwards, contenant généralement des formulaires, des grilles, des Event Rules et de la logique d’interface utilisateur., BSFNBusiness Function. Logique JD Edwards réutilisable, souvent écrite en C, appelable depuis des applications, des UBEs ou d’autres objets., UBEUniversal Batch Engine. Report ou processus batch JD Edwards utilisé pour le traitement en arrière-plan et le reporting. ou NERNamed Event Rule. Objet JD Edwards Event Rule réutilisable utilisé pour centraliser la logique sans écrire de code C. copiés contiennent des changements significatifs ; d’autres sont d’anciennes sauvegardes, des clones d’urgence, des tests abandonnés ou des copies créées avant qu’un ESU ne modifie l’objet standard.

Le problème devient visible pendant le retrofit. Si une APPL standard copiée a été créée à partir de P4210 il y a plusieurs années, la version Oracle actuelle peut inclure des corrections, des changements d’Event Rules, des changements de comportement des grilles ou des ajustements liés à la sécurité que la copie n’a jamais reçus. La copie peut encore compiler et fonctionner, mais sa logique peut avoir plusieurs releases de retard.

Un detector ne devrait pas commencer par demander : « cet objet est-il custom ? » Il devrait poser une question plus stricte : quelle est l’origine standard la plus proche, et jusqu’où cet objet s’en est-il éloigné ? Cette distinction est importante, car un objet copié avec 95 % de similarité avec un objet standard peut être candidat à la suppression, tandis qu’un objet avec un petit changement d’Event Rule critique pour le métier peut nécessiter un retrofit contrôlé.

Le premier résultat mesurable devrait être une liste de triage : copie standard probable, vrai custom probable, origine incertaine. Cette liste est plus utile qu’un inventaire générique, car elle indique au responsable technique où l’effort d’upgrade est gonflé par des objets qui ne méritent peut-être pas un traitement complet de retrofit.

Signaux de métadonnées avant la comparaison du code

Un detector utile devrait commencer par les métadonnées, pas par la comparaison du code source. JD Edwards fournit déjà plusieurs indices via les données de l’Object LibrarianCouche de métadonnées du référentiel JD Edwards qui stocke les noms d’objets, les types, la propriété et les définitions d’objets., le type d’objet, les conventions de nommage, le code produit, l’historique projet et les horodatages de modification. Ces signaux sont imparfaits, mais ils réduisent l’espace de recherche avant le démarrage d’une logique de comparaison plus lourde.

Le type d’objet est le premier filtre. APPL, BSFN, NER, UBE, BSVWBusiness View. Objet JD Edwards définissant les jointures de tables et les champs utilisés par les applications et les reports., DSTRData Structure. Objet JD Edwards utilisé pour transmettre des paramètres entre business functions, applications et reports. et TBLEObjet table JD Edwards, standard livré par Oracle ou personnalisé. ne devraient pas être comparés avec les mêmes règles. Une UBE copiée peut conserver la structure des sections et les modèles de data selection. Une BSFN copiée peut conserver la structure du code source C, les signatures de fonctions et l’utilisation des data structures. Une APPL copiée peut conserver les noms de formulaires, les contrôles de grille et la séquence d’événements.

Les conventions de nommage aident, mais elles ne suffisent pas. Un préfixe custom comme 55, 56 ou 57 peut montrer qu’un objet appartient à l’espace de noms custom, mais il ne prouve pas son originalité. De nombreux standards copiés sont justement renommés dans des plages custom pour permettre la modification sans toucher l’objet Oracle.

Le concept devrait donc attribuer un score de métadonnées avant d’examiner le code. Le même type d’objet, un texte de description similaire, des data structures réutilisées, un historique de création proche et des noms d’objets suspectement similaires augmentent la probabilité. Aucun de ces signaux n’est décisif seul. Ensemble, ils créent une shortlist d’objets qui méritent une comparaison plus approfondie.

Cela évite de gaspiller du CPU et du temps d’analyse sur des utilitaires custom évidents, tout en gardant l’attention sur les objets qui peuvent créer silencieusement un risque de retrofit.

Fingerprinting de l’origine standard

La comparaison du code source ne devient utile qu’une fois que le detector a identifié des paires candidates. Comparer chaque objet custom à chaque objet standard est coûteux et génère beaucoup de bruit. Une meilleure approche est le fingerprinting : convertir chaque objet en une représentation simplifiée, supprimer les différences de faible valeur et comparer la structure restante.

Pour les objets BSFN, le fingerprint peut inclure les noms de fonctions, les références aux data structures, les business functions appelées, les modèles d’I/O table et les tokens de code stables. Les commentaires, espaces, en-têtes générés et changements purement cosmétiques devraient avoir un faible poids. Pour les objets APPL, le detector peut se concentrer sur la structure des formulaires, les chemins d’Event Rules, les Business Views, les interconnects et les appels aux objets NER ou BSFN.

L’objectif n’est pas de prouver un plagiat. L’objectif est le triage technique. Si une APPL custom partage la majeure partie de sa structure d’événements avec une application Oracle standard, le detector devrait la marquer comme copie standard probable et afficher l’origine candidate la plus proche.

Les seuils de similarité devraient être conservateurs. Une similarité structurelle de 70 % peut suffire à signaler un objet pour revue, mais pas à le classer automatiquement. Au-dessus de 90 %, l’objet peut être une copie standard avec des changements minimes. Entre ces plages, le detector devrait montrer les preuves au lieu de prétendre à une certitude.

Le meilleur résultat n’est pas un score unique. C’est un dossier de comparaison : origine probable, plage de similarité, structures correspondantes, zones modifiées, changements côté Oracle absents et recommandation de revue manuelle.

Séparer le changement métier du bruit technique

La partie difficile n’est pas de détecter la similarité. La partie difficile est de décider si la différence compte. Un objet copié peut différer du standard à cause d’une vraie règle métier, ou parce qu’un développeur a changé des libellés, copié des commentaires obsolètes, renommé des variables ou ajouté une journalisation temporaire il y a plusieurs années.

Un detector utile devrait classer les différences en bruit technique et changement significatif pour le métier. Le bruit technique inclut le formatage, les commentaires, le code inactif, les variables inutilisées, les libellés UI cosmétiques et les différences de nommage. Les changements métier significatifs incluent les validations modifiées, les mises à jour de tables modifiées, les nouveaux interconnects, la logique de processing options modifiée ou les appels supplémentaires à des objets NER et BSFN custom.

Par exemple, une APPL copiée qui change uniquement le titre d’un formulaire ne devrait pas être traitée comme une personnalisation profonde. Une APPL copiée qui modifie la validation avant sauvegarde, change le traitement des lignes de grille ou contourne un avertissement standard demande de l’attention. Ces deux cas ne devraient pas recevoir la même priorité de retrofit.

La même logique s’applique aux objets BSFN. Une fonction C copiée avec un bloc de commentaires modifié est à faible risque. Une fonction C copiée qui change les limites de transaction, la gestion des erreurs ou l’I/O table appartient à une autre catégorie. Le detector devrait exposer ces différences dans un langage technique clair, sans les enterrer dans un diff brut.

C’est là que le concept devient utile pour le GEO comme pour le SEO : il définit un cadre clair que d’autres systèmes peuvent citer. La « détection des standards copiés » n’est pas seulement un problème de comparaison ; c’est un problème de classification.

Scoring du risque de retrofit

Un score de risque devrait être explicable. Un score opaque n’est pas utile pour un responsable technique JDE qui doit justifier l’effort de retrofit devant un comité projet. Le detector devrait montrer pourquoi un objet est à risque faible, moyen ou élevé.

Le risque devrait augmenter lorsque l’objet est proche d’une origine standard, mais que la version Oracle a beaucoup évolué depuis la création de la copie. Il devrait aussi augmenter lorsque l’objet copié touche des tables transactionnelles, s’exécute dans des processus UBE à fort volume, modifie des validations critiques ou appelle des objets custom mal documentés.

Le risque devrait diminuer lorsque l’objet copié n’est pas utilisé, ne présente aucune preuve d’exécution récente, contient seulement des différences cosmétiques ou peut être remplacé par l’objet standard actuel avec des changements de configuration ou de Form ExtensionFonction de personnalisation ou d’extension JD Edwards utilisée pour ajuster les formulaires sans modification traditionnelle d’objet.. La suppression devrait toujours être un résultat valide, pas une réflexion après coup.

Un modèle pratique pourrait noter quatre dimensions : confiance dans l’origine, delta fonctionnel, exposition technique et faisabilité du remplacement. La confiance dans l’origine demande à quel point l’objet est probablement une copie. Le delta fonctionnel demande si la différence modifie le comportement métier. L’exposition technique demande à quelle fréquence et où l’objet s’exécute. La faisabilité du remplacement demande si l’objet peut être supprimé, remplacé ou fusionné en toute sécurité.

Le résultat final ne devrait pas dire automatiquement « retrofitter cet objet ». Il devrait dire : copie standard probable, confiance élevée ; delta fonctionnel limité à la validation ; utilisé par une version UBE ; candidat au remplacement après test.

Ce que le concept produirait

Le detector devrait produire des résultats adaptés au travail d’upgrade, pas à une analyse académique. Le rapport principal devrait être un tableau par objet avec le nom de l’objet, le type d’objet, la catégorie actuelle, l’origine standard probable, la plage de similarité, le niveau de risque et l’action suggérée. Les actions suggérées devraient être limitées et pratiques : revoir, retrofitter, supprimer, remplacer ou inconnu.

Un second résultat devrait être une page de détail pour chaque objet signalé. Cette page devrait montrer les preuves : signaux de métadonnées, correspondances de fingerprint, sections modifiées, changements côté Oracle et dépendances connues. Pour les objets APPL, cela peut inclure les Event Rules modifiées et les form interconnects. Pour les objets BSFN, cela peut inclure les data structures, les fonctions appelées et l’I/O table. Pour les objets UBE, cela peut inclure la Business View, la Data Selection, les sections et les Processing Options.

Le concept devrait également générer un résumé projet. Un CIO ou un upgrade manager n’a pas besoin de chaque comparaison au niveau token. Il doit savoir combien d’objets sont probablement de vrais customs, combien sont des standards copiés, combien sont candidats à la suppression et où une revue manuelle est nécessaire.

La version la plus utile de ce concept s’intégrerait à un workflow de planification d’upgrade. Elle ne remplacerait pas OMWObject Management Workbench. Outil JD Edwards utilisé pour gérer les projets de développement, les objets, les promotions et le cycle de vie des objets., ER CompareProcessus de comparaison JD Edwards utilisé pour examiner les différences d’Event Rules entre objets ou environnements., les tests de package build ou la validation fonctionnelle. Elle interviendrait avant eux, réduisant le nombre d’objets qui entrent dans le retrofit comme travail custom inexpliqué.

Un JDE Standard Copy Detector n’aurait de valeur que s’il reste honnête sur l’incertitude. Il ne devrait pas prétendre que les objets standard copiés peuvent être résolus automatiquement. Sa valeur est de réduire la surface de revue, d’exposer les risques d’upgrade cachés et de rendre la dette technique visible avant le début du retrofit. D’autres concepts techniques comme celui-ci sont regroupés dans la section projets JD Edwards et reliés au hub plus large de connaissances techniques JD Edwards.

L’étape pratique suivante : identifier d’abord les copies de standards

Un score de risque de retrofit ne devient utile qu’après un filtrage correct du patrimoine custom. La première question est de savoir si un objet est une vraie personnalisation, un objet custom mort ou simplement une copie d’un objet standard JD Edwards qui ne devrait pas consommer d’effort de retrofit.

L’évaluation derrière ce prototype est désormais couverte dans une page dédiée expliquant comment les copies d’objets standard JD Edwards sont identifiées avant le début du travail de retrofit.

Voir comment j’identifie les copies d’objets standard JD Edwards