La plupart des post-mortems d'applications batch que je réalise remontent à la même faille : un développeur valide un UBEUniversal Batch Engine : le moteur d'exécution des traitements par lots (batchs) de JD Edwards. personnalisé dans DV920L'environnement de développement standard dans JD Edwards 9.2. sur 50 lignes de données de test isolées, marque le projet Object Management WorkbenchL'outil de gestion du cycle de vie et de promotion des objets dans JD Edwards. comme terminé et passe à autre chose. En l'espace de deux jours, ce même rapport tente de traiter 100 000 enregistrements dans PY920L'environnement de test et de prototypage dans JD Edwards 9.2., provoque un interblocage (deadlock)Situation où deux processus s'attendent mutuellement en bloquant des ressources, ce qui fige l'exécution. sur F41021 en raison de limites de transaction non validées (uncommitted), ou sature la file d'attente mono-thread configurée dans F986110.
Lors d'audits d'entreprise approfondis, les équipes techniques constatent régulièrement que la majorité des rapports Universal Batch Engine (UBE)Moteur de traitement par lots de JD Edwards utilisé pour générer des rapports et exécuter des processus en arrière-plan. personnalisés contournent involontairement le noyau de sécurité JDE (F00950Table système centrale de JD Edwards qui stocke toutes les règles de sécurité applicatives, par objet et par ligne.). Les directions ERP supposent souvent qu'une sécurité par ligne active sur des tables comme F060116 (Payroll) ou F4105 (Item Cost) limite intrinsèquement les résultats des traitements par lots. Ce n'est pas le cas. Dès qu'un développeur utilise des Table I/OOpérations d'entrée/sortie permettant de lire, écrire ou mettre à jour directement les données des tables dans JD Edwards. directs dans les Event RulesLangage de programmation propriétaire de JD Edwards utilisé pour coder la logique métier des applications et des rapports. ou appelle une Business FunctionComposant logiciel réutilisable, écrit en C ou en Event Rules, exécutant des calculs ou des processus métier spécifiques. C personnalisée exécutant JDB_OpenTable sans transmettre explicitement le contexte de sécurité de l'utilisateur, la sécurité par ligne au niveau du moteur est ignorée.
Lorsqu'une file d'attente de traitements batch se bloque sur l'Enterprise ServerLe serveur central qui exécute les calculs, la logique métier et les traitements lourds (batchs) de JD Edwards. à 2h00 du matin, le premier réflexe de nombreuses équipes est d'augmenter le nombre maximal de jobs simultanés dans la configuration de l'environnement JDEJD Edwards, un progiciel de gestion intégré (ERP) utilisé par les entreprises pour gérer leurs opérations.. Neuf fois sur dix, il s'agit d'un mauvais diagnostic. Le véritable goulot d'étranglement est presque toujours une conception défectueuse dans le Report Design Aid (RDA)L'outil de développement interne de JD Edwards utilisé pour créer et modifier des rapports et des programmes batch. qui exécute des millions de lectures de base de données non indexées. Joindre la table F4111 Item Ledger à la table F0911 General Ledger dans une seule Business ViewUne interface dans JD Edwards qui sélectionne et lie les tables de la base de données pour les rendre utilisables par les rapports. personnalisée sans correspondance stricte d'indexUne structure de données qui accélère la recherche d'enregistrements dans une table, comme l'index d'un livre. transforme ce qui devrait être un traitement de 90 secondes en un blocage de file d'attente de 4 heures.
La tendance à contourner le middleware JDECouche logicielle qui gère les communications et la logique métier entre les applications JD Edwards et la base de données. et à exécuter du SQLLangage standard utilisé pour interagir avec les bases de données relationnelles. direct sur des tables comme F0911Table centrale du Grand Livre (Account Ledger) dans JD Edwards, contenant toutes les écritures comptables. ou F4211Table de détail des commandes de vente (Sales Order Detail) dans JD Edwards. provient généralement de la vitesse d'exécution brute : une requête SQL optimisée peut extraire 500 000 lignes en moins de quinze secondes, alors qu'un UBEUniversal Batch Engine : moteur d'exécution des rapports et des traitements par lots dans JD Edwards. personnalisé peut prendre près d'une heure pour traiter le même ensemble de données. Cependant, évaluer une extraction de données personnalisée JDE UBE par rapport au SQL direct uniquement sur la vitesse d'exécution est une erreur d'architecture qui perturbe régulièrement les rapports financiers en aval.
Un UBEUniversal Batch Engine : moteur d'exécution de JD Edwards pour les traitements de masse et les rapports en arrière-plan. standard conçu pour 5 000 enregistrements échouera de manière catastrophique lorsque les volumes nocturnes dépasseront 100 000 transactions. La plupart des exécutions par lots personnalisées échouent non pas à cause d'une logique métier erronée, mais en raison de délais d'attente de la base de données, de conflits d'index et de fuites de mémoire dans les fonctions métier C personnalisées (BSFNsBusiness Functions : modules de code (souvent en C) exécutant des règles métier spécifiques au sein de l'ERP.). Lors de l'exécution de volumes élevés dans EnterpriseOne 9.2, s'appuyer sur des conceptions de rapports linéaires standard est un risque opérationnel. Parvenir à une conception de traitement par lots JDE UBE personnalisée et résiliente pour le traitement nocturne nécessite de s'éloigner des boucles de règles d'événements (EREvent Rules : langage de script interne à JD Edwards permettant de programmer des actions sur des événements précis.) de base et d'adopter des architectures pilotées par la base de données.
Page 2 sur 3