JD Edwards est un nom qui signifie des choses légèrement différentes selon les publics. Pour un directeur financier d'une entreprise manufacturière, c'est le système ERP que l'équipe finance utilise depuis quinze ans. Pour un DSI évaluant les options de modernisation, c'est l'une des plateformes en concurrence pour un budget de transformation. Pour un développeur ayant un CV dans l'écosystème, c'est une pile spécifique d'outils, de langages et de couches de métadonnées construite autour d'une base de données relationnelle. Ces trois points de vue décrivent le même produit, et toute conversation qui les aplatit en un seul risque le même malentendu que le terme produit depuis des décennies. Cet article parcourt le produit de bout en bout tel qu'il se présente aujourd'hui, qui l'utilise, ce qu'il est réellement techniquement, et à quoi ressemblent les options réalistes à son sujet dans la décennie actuelle.
Le produit a survécu à trois propriétaires d'entreprise, à de multiples réécritures d'architecture et à un changement générationnel de l'apparence des logiciels d'entreprise. Il est toujours activement développé par Oracle sous le nom de JD Edwards EnterpriseOne, avec un produit hérité parallèle appelé JD Edwards World recevant toujours du support. Les questions cruciales — devons-nous y rester, devons-nous nous moderniser avec lui, devons-nous le remplacer — dépendent de la compréhension de quel JD Edwards vous avez devant vous et de quelle est réellement sa trajectoire actuelle.
Le développement custom dans JD Edwards — BSFN, NER, APPL et automatisation ERP — est le point où la plupart des implémentations jouent soit leur réussite, soit leur dette technique pour les dix années suivantes. La plateforme offre quatre outils principaux pour étendre le comportement standard, et chaque mauvais choix sur l’outil à utiliser pour un cas d’usage donné produit des conséquences qui n’apparaissent que lorsqu’il est déjà trop coûteux de changer de direction : pendant un upgrade, pendant un retrofit, ou pendant un Tools Release qui modifie le comportement sous-jacent de façon non documentée.
Cet article aligne les quatre outils — Business Functions en C, Named Event Rules, applications FDA et Orchestrator — décrit ce pour quoi chacun est réellement adapté, et présente les modèles de décision qui fonctionnent en production chez de vrais clients. Aucun de ces quatre outils n’est universellement meilleur que les autres ; chacun couvre un espace de problèmes spécifique, et la discipline consiste à reconnaître cet espace avant d’écrire la première ligne de code.
La création d'une application JD Edwards (JDE) nécessite une compréhension approfondie de ce système de planification des ressources de l'entreprise (ERP) et de ses fonctionnalités. JDE est réputé pour être hautement personnalisable et extensible grâce au langage de programmation JDE C BSFN (Business Function), ou grâce à l'utilisation d'outils tels qu'Orchestrator. Voici un exemple de comment vous pourriez commencer à écrire une application personnalisée dans JD Edwards en utilisant JDE C BSFN :
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 1 sur 6