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.

L'application d'un ESUMise à jour logicielle électronique fournie par Oracle pour corriger des bogues ou ajouter des fonctionnalités dans JD Edwards. Oracle à une application de base fortement modifiée comme la Saisie des Commandes de Vente (P4210) ou la Saisie des Réquisitions (P4312) est l'étape où les délais de mise à jour déraillent fréquemment. Bien que des outils comme ER CompareOutil de JD Edwards permettant de comparer et de fusionner les différences entre deux versions de règles d'événements. existent depuis des décennies, les développeurs corrompent encore régulièrement les spécificationsMétadonnées stockées dans la base de données qui définissent le comportement et l'apparence des objets JD Edwards. locales ou perdent de la logique métier critique car ils traitent la fusion comme un simple exercice de copier-coller mécanique. Dans une mise à jour typique de 9.1 vers 9.2, les applications interactives (APPLAbréviation pour Application Interactive, un programme avec lequel l'utilisateur interagit via une interface graphique.) représentent une part relativement faible des objets modifiés, environ 10 % à 20 %, mais elles comptent pour plus d'un tiers des rapports d'incidents post-mise en service en raison de fusions manuelles mal exécutées.

En plus de deux décennies de sauvetage de bases de code JDE personnalisées, l'échec architectural le plus persistant que je vois est de traiter les versions d'applications interactives (APPLApplications interactives de JD Edwards permettant aux utilisateurs de consulter et modifier des données via une interface graphique.) comme des versions d'applications batch (UBEUniversal Batch Engine : programmes de traitement par lots utilisés pour générer des rapports ou traiter de gros volumes de données.). Alors qu'une version UBE contient des spécifications indépendantes de sélection de données et de séquençage, une version APPL est simplement un pointeur vers des valeurs de Processing OptionsParamètres permettant de modifier le comportement d'un programme sans modifier son code source. stockées dans la table F983051Table système centrale stockant les définitions des versions et leurs options de traitement.. Une mauvaise compréhension de cette distinction conduit les développeurs à coder en dur les noms de versions dans les Event RulesLangage de programmation spécifique à JD Edwards utilisé pour définir la logique métier des applications et rapports., ce qui fragmente le code (forking) et alourdit l'empreinte de vos mises à niveau.

Lors de l'exécution d'un ER CompareOutil de comparaison et de fusion de code entre différentes versions d'objets JD Edwards. sur un P4210Application standard JD Edwards dédiée à la gestion des commandes de vente. ou P4310 fortement modifié pendant une mise à niveau de 9.1 vers 9.2, le coût des mauvaises habitudes de développement devient immédiatement évident. Des variables cryptiques comme evt_szName_WD01 ou des Event Rules (ER)Langage de programmation interne à JD Edwards pour définir la logique métier des applications. non documentées transforment un rétrofitProcessus consistant à réappliquer des modifications personnalisées sur une nouvelle version logicielle standard. standard de quelques heures en un cycle de débogage de plusieurs jours. L'outil de fusion visuelle ne parvient pas à aligner la logique lorsque les variables personnalisées manquent de contexte structurel, ce qui entraîne des corruptions de mémoire silencieuses au moment de l'exécution ou des ruptures d'interconnexions de formulaires.