Lors de l'application d'une mise à jour logicielle électronique (ESUMise à jour logicielle corrective ou évolutive fournie par Oracle pour JD Edwards.) de base majeure — telle que la JN19112 pour la Finance — les organisations découvrent fréquemment qu'environ 10 % à 15 % de leurs fonctions de gestion C (BSFNComposant de logique métier réutilisable, écrit en langage C ou en NER.) standard modifiées ont été réinitialisées silencieusement au standard Oracle. L'utilitaire de fusion natif de l'Object Management Workbench (OMWInterface de gestion du cycle de vie des objets et du développement dans JD Edwards.) échoue régulièrement à réconcilier les manipulations complexes de pointeurs CVariables contenant l'adresse mémoire d'une donnée, permettant une manipulation directe et rapide. ou les modifications de structures de données personnalisées, introduisant des fuites de mémoireDéfaillance d'un programme qui ne libère pas la mémoire vive après utilisation, risquant de saturer le serveur. ou des processus zombiesProcessus terminés qui restent présents dans le système, consommant des ressources inutilement. immédiats sur l'Enterprise ServerServeur central gérant la logique métier, les bases de données et les traitements JD Edwards. lors de l'exécution.
Une BSFNUne Business Function est un objet JD Edwards contenant du code (C ou NER) pour exécuter une logique métier spécifique sur le serveur. personnalisée d'allocation d'inventaire traitant 10 000 à 15 000 lignes de commande client devrait s'exécuter en moins d'une minute. Pourtant, dans de nombreux environnements JDE 9.2, cette même exécution prend plus d'une demi-heure à cause d'un anti-pattern classique : l'exécution répétitive d'instructions Select et Fetch Next sur F4101 ou F4102 à l'intérieur d'une boucle. Lorsqu'une Named Event Rule (NER)Langage de programmation propriétaire de JD Edwards permettant de créer de la logique métier sans écrire directement en code C. ou une fonction C déclenche un aller-retour vers la base de données pour chaque itération, la latence réseau entre l'Enterprise Server et le niveau base de données dégrade considérablement les performances.
Considérer le nommage des business functionsComposants de code réutilisables qui exécutent des calculs ou des processus métier spécifiques dans JD Edwards. comme un simple choix esthétique introduit une surcharge opérationnelle directe qui gonfle les temps de rétrofitAction de réappliquer des modifications personnalisées sur une nouvelle version d'un logiciel. lors des mises à jour, de l'ordre d'un tiers ou plus selon notre expérience. Lorsque les développeurs nomment arbitrairement les BSFN CFonctions métier écrites en langage de programmation C pour des performances accrues. ou les NERNamed Event Rules : langage de programmation propriétaire de JD Edwards permettant de créer de la logique sans écrire en C. personnalisées, ils créent une dette techniqueCoût futur engendré par des décisions de conception logicielle rapides ou de mauvaise qualité. qui alourdit silencieusement la phase typique de développement de mise à jour de 6 à 9 semaines. L'implémentation de conventions de nommage JDE BSFN strictes pour les objets personnalisés maintenables garantit que les objets B55, B56 et B57 signalent instantanément leur système parent, leur domaine fonctionnel et leur lieu d'exécution (client ou serveur) au sein de l'Object Management Workbench (OMW)Interface centrale de JD Edwards pour gérer le cycle de vie, le développement et le transfert des objets..
Une seule mauvaise gestion de jdeAllocUne API JD Edwards utilisée pour allouer dynamiquement de la mémoire sur le serveur. ou un handle de cache non libéré dans une BSFNBusiness Function : un objet contenant du code logique (souvent en C) exécuté par le serveur JD Edwards. personnalisée appelée au sein d'un UBEUniversal Batch Engine : le moteur de JD Edwards responsable de l'exécution des rapports et des traitements par lots. à haut volume comme R42565 peut faire planter un kernel CallObjectUn processus serveur JD Edwards qui gère l'exécution des fonctions métier (BSFN) demandées par les utilisateurs. en quelques minutes, mettant fin instantanément à des dizaines de sessions utilisateur actives sur cette JVMJava Virtual Machine : l'environnement d'exécution nécessaire pour faire tourner les applications Java de JD Edwards. spécifique. Lors du dépannage d'environnements EnterpriseOne 9.2 instables, nous traçons fréquemment des processus zombies persistants et des fuites de mémoire vers des erreurs courantes de gestion de mémoire JDE BSFN dans le code personnalisé, plutôt que vers des problèmes sous-jacents de base de données ou de middleware OCILogiciels intermédiaires fonctionnant sur Oracle Cloud Infrastructure pour assurer la communication entre applications..
Dans nos revues de code sur des dizaines d'environnements JDE 9.2Version moderne de l'ERP JD Edwards EnterpriseOne d'Oracle, intégrant des fonctionnalités cloud et de livraison continue., nous constatons régulièrement qu'une partie importante des fonctions métier C personnalisées (BSFNBusiness Function : module de code réutilisable écrit en C ou Event Rules pour exécuter des processus métier dans JD Edwards.) — souvent d'un tiers à la moitié — dupliquent inutilement la logique Oracle standard. Les développeurs clonent souvent des modules entiers comme B4200310 ou B1200010 juste pour exécuter une seule validation, au lieu d'implémenter un appel propre via un exemple jdeCallObject JDE BSFN pour exécuter une fonction métier réutilisable. Ce code redondant pose problème lors des mises à jour car il contourne les mises à jour de livraison continue d'Oracle. L'approche la plus propre consiste à appeler dynamiquement la fonction métier standard depuis votre code C personnalisé.
Page 3 sur 6