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.

Maîtriser le design de rapports JDE UBEUniversal Batch Engine, un programme d'arrière-plan dans JD Edwards qui traite de gros volumes de données sans intervention humaine. personnalisés pour éviter les traitements longs nécessite de s'attaquer à la cause racine dans la logique des Event RulesLe langage de programmation interne de JD Edwards utilisé pour écrire la logique métier des applications et des rapports. bien avant que le code n'atteigne votre pipeline de Package BuildLe processus de compilation et de préparation du code informatique pour le déployer sur les serveurs JD Edwards.. Sortir les E/S au niveau de la ligne de la Do SectionLa section principale d'un rapport JD Edwards qui s'exécute en boucle pour chaque ligne de données lue., supprimer les colonnes de table inutiles des Business Views et libérer correctement les handles de mémoire des C BSFNBusiness Function écrite en langage C, utilisée dans JD Edwards pour exécuter des calculs rapides ou des fonctions système complexes. permet régulièrement de réduire les temps de traitement des UBE de 80 % à 95 %. Voici la checklist d'audit technique à appliquer aux rapports personnalisés avant de les promouvoir hors du pathcodeUn environnement spécifique dans JD Edwards (comme le développement, le test ou la production) contenant son propre ensemble de codes. de développement (DV).

Optimiser les Business Views pour réduire l'empreinte des requêtes

Les développeurs utilisent couramment des business views standards comme V0911A ou créent des vues personnalisées qui effectuent un SELECT sur l'ensemble des plus de 120 colonnes de la table F0911 Account Ledger aux côtés de la table F0006 Business Unit Master. Lors du traitement de 5 millions d'enregistrements de transactions, le transfert de F0911.GLPOST, F0911.GLALT1 et de dizaines de champs d'audit inutilisés sur le réseau dégrade les performances mémoire sur l'Enterprise Server et sature l'interface réseau de la base de données. JDE génère du SQL en utilisant une liste explicite de colonnes basée sur la définition de la BSVWBusiness View, un objet JD Edwards qui définit la sélection et la jointure des tables de base de données., mais une vue contenant plus de 100 champs répartis sur deux tables gonfle tout de même les allocations de mémoire pour chaque tampon de ligne (row buffer) dans le runtime de l'UBE.

La baisse de performance s'accentue lorsque les développeurs configurent des jointures externes gauches (left outer joins)Une méthode de liaison de tables qui renvoie toutes les lignes de la table principale, même s'il n'y a pas de correspondance dans la table secondaire. entre la F0911 et des tables secondaires comme la F0006 ou la F4111 en utilisant des combinaisons de clés primaires non indexées ou des critères de jointure lâches. Effectuer une jointure sur des champs non indexés force l'optimiseur de requêtes de la base de données à effectuer un scan complet de la table (full table scan)Une opération lente où la base de données lit chaque ligne d'une table pour trouver les données demandées. ou une jointure de hachage (hash join) très coûteuse sur des millions d'enregistrements, contournant complètement l'index composite F0911_1 (GLDCT, GLDOC, GLKCO, GLDGJ, GLJEL). Sur une instance Oracle Database 19c, une requête structurée de cette manière fait régulièrement passer le temps d'exécution de l'UBE de moins d'une minute à plus de deux heures.

Créez une Business View dédiée et minimale dans l'Object Management Workbench (OMW)L'outil de gestion de projet de JD Edwards où les développeurs créent, modifient et contrôlent les objets de programmation., contenant uniquement les clés primaires précises et les champs cibles nécessaires au filtrage ou au traitement. Si votre rapport n'a besoin que de GLAID, GLAA et GLDGJ de la F0911 pour calculer les soldes du grand livre, excluez toutes les autres colonnes de la vue. Réduire une vue de 120 champs à seulement 10 divise la charge utile réseau SQL par ligne d'environ trois quarts et permet à la base de données de conserver les blocs d'index en cache de manière beaucoup plus efficace pendant l'exécution du batch.

Aligner la Data Selection et les index pour une recherche instantanée

Lancez une requête sur une table F4111 Item Ledger contenant 10 millions de lignes sans faire correspondre les premières colonnes d'un index, et l'optimiseur de la base de données se rabattra sur un scan complet de la table ou un scan d'index coûteux (index skip scan). Les rapports d'inventaire personnalisés filtrent fréquemment sur la date de transaction (ILGLDATE) et le site/magasin (ILMCU) tout en omettant le numéro d'article (ILITM), ce qui fait passer le temps d'exécution de quelques secondes à 45 minutes. La Data SelectionLes critères de filtrage définis dans un rapport pour choisir précisément quelles données extraire de la base de données. dans RDA doit strictement refléter la séquence des colonnes de gauche à droite d'une clé d'index pour permettre à l'optimiseur de la base de données d'exécuter un scan de plage d'index direct (index range scan) plutôt que de parcourir des millions de blocs non indexés.

Les opérateurs de comparaison dans le Report Design Aid déterminent si le moteur de base de données utilise un index ou évalue les enregistrements ligne par ligne. L'utilisation des critères NOT EQUAL TO, CONTAINS ou WILD CARD dans la Data Selection du RDA supprime l'optimisation des index en forçant des scans complets sur la table cible. Lors de requêtes sur des tables à fort volume comme F4111 ou F4011, le remplacement d'un opérateur NOT EQUAL TO sur le type de document (ILDOTY) par une liste positive explicite — ou le filtrage des types de documents indésirables dans les Event Rules après la lecture de l'enregistrement — réduit fréquemment les temps d'attente d'E/S de la base de données de 80 % à 90 % sur Oracle ou SQL Server.

Le tri dynamique au moment de l'exécution est un autre tueur silencieux de l'exécution des batchs. Lorsqu'une règle d'événement ou une section de rapport spécifie un Data SequencingL'ordre de tri défini dans un rapport pour organiser l'affichage des données extraites. qui ne correspond pas à un index de base de données actif, EnterpriseOne ajoute une clause ORDER BY qui force la base de données à écrire des ensembles de résultats intermédiaires dans des espaces de table temporaires (tablespaces) avant de renvoyer la première ligne. La création d'un index de table personnalisé ciblé dans l'Object Management Workbench (OMW) qui correspond précisément à la fois à votre Data Selection RDA et à votre structure de Data Sequencing requise élimine la surcharge liée au tri à l'exécution, permettant au moteur UBE de diffuser instantanément des enregistrements pré-triés.

Éliminer la logique ER inefficace et les pièges d'accumulation de clauses

Filtrer les enregistrements à l'aide de la logique des Event Rules dans la Do Section force l'enterprise server à récupérer chaque enregistrement depuis la base de données avant de l'évaluer. Si un rapport de détail des transactions parcourt 500 000 lignes non correspondantes dans le cardex F4111 et les supprime à l'aide d'une fonction système Suppress Section Write à l'intérieur d'un bloc ER IF/ELSE, vous payez tout de même la totalité de la pénalité de latence réseau et de tampon de base de données pour les 500 000 lignes. Le moteur de base de données reste complètement aveugle à vos critères d'évaluation, transmettant des gigaoctets sur le réseau pour que le runtime JDE les rejette ensuite ligne par ligne.

Remontez cette logique de filtrage dans le moteur SQL en appelant Set User SelectionUne fonction système de JD Edwards permettant de modifier dynamiquement les filtres de recherche de la base de données. dans l'Initialize SectionUn événement de programmation qui s'exécute une seule fois au tout début du traitement d'une section de rapport.. Les fonctions système exécutées pendant l'initialisation se traduisent directement en prédicats de clause WHERE SQL dans la requête initiale envoyée à Oracle Database ou SQL Server. L'évaluation des conditions au niveau de la base de données permet à l'optimiseur de requêtes d'utiliser les index composites existants, ne renvoyant que les 20 000 lignes pertinentes à l'enterprise server et éliminant instantanément plus de 90 % de la surcharge réseau et mémoire.

Soyez précis lors de la gestion de la logique de sélection dynamique de l'utilisateur pour éviter l'accumulation de clauses. Appeler Set User Selection de manière répétée dans différentes branches logiques sans configurer Set Selection Append FlagUne fonction système de JD Edwards qui détermine si les nouveaux filtres s'ajoutent ou remplacent les précédents. pour spécifier le mode de remplacement force JDE à concaténer des prédicats redondants dans l'instruction générée. Un rapport s'exécutant dans une boucle qui ajoute continuellement des clauses AND peut facilement construire une clause WHERE de 2 000 caractères avec des conditions redondantes, perturbant l'optimiseur de la base de données et transformant une recherche d'index normalement instantanée en un goulot d'étranglement de plusieurs heures.

Sortir les opérations d'E/S au niveau de la ligne de la Do Section

Placer une opération d'E/S de table (table IOOpérations d'entrée/sortie (lecture, écriture, modification) effectuées directement sur les tables de la base de données.) à l'intérieur de la Do Section d'un UBE est l'erreur la plus courante qui fait tourner les rapports batch d'entreprise pendant des heures au lieu de quelques minutes. Prenons l'exemple d'un rapport de transactions d'inventaire classique parcourant 500 000 enregistrements dans la table F4111. Si un développeur insère un Fetch Single explicite sur la table F4101 Item Master à l'intérieur de la Do Section pour récupérer le texte de recherche ou le type de stockage, le traitement batch exécutera 500 000 requêtes SQL individuelles sur le réseau. Chaque aller-retour introduit de la latence de base de données, transformant une requête de moins de cinq minutesDurée estimée pour un traitement optimisé. en un traitement batch de plusieurs heures qui verrouille les ressources de l'enterprise server et ralentit les files d'attente d'exécution des threads de la base de données.

Combiner les lectures de table requises dans la Business View sous-jacente de la section supprime instantanément ces centaines de milliers d'appels de base de données distincts. Joindre la F4101 à la table principale F4111 au niveau de la vue transfère la charge au moteur de base de données, qui récupère le jeu de données joint via un seul curseur de base de données en utilisant des plans d'exécution précompilés. Si une logique conditionnelle empêche une jointure de vue statique — comme des recherches de correspondances optionnelles —, chargez les données cibles dans un cache mémoire basé sur l'API C pendant l'Initialize Section, ou interrogez les variables d'environnement locales une fois par rupture (level break) plutôt qu'à chaque ligne.

Évitez d'utiliser les Event Rules pour construire des boucles d'itération manuelles avec les commandes Select et Fetch Next sur des tables auxiliaires comme la F4074 ou la F0911 pendant l'exécution des lignes. Les développeurs écrivent fréquemment ces boucles ER manuelles pour agréger des ajustements de prix ou des montants de grand livre, sans se rendre compte qu'ils cumulent de la latence de requête sur chaque enregistrement de détail. Configurez des Level Break Headers et des Level Break Footers pour gérer les sous-totaux et les agrégations cumulées de manière native au sein du moteur UBE. Laisser le runtime gérér les ruptures de section événementielles élimine les accumulateurs ER personnalisés et supprime des millions de handles de table inutiles lors des exécutions de grands batchs.

Gérer les handles de cache et la mémoire des C Business Functions

Un rapport d'entreprise traitant 100 000 enregistrements échouera silencieusement ou entraînera l'enterprise server dans une pagination du noyau (kernel paging) si les C Business FunctionsDes programmes écrits en langage C intégrés à JD Edwards pour exécuter des calculs complexes et rapides. personnalisées exécutées dans la Do Section laissent leurs pointeurs de cache orphelins. Appelez jdeCacheInit ou jdeCacheAddItem à l'intérieur d'une boucle d'Event Rules sans exécuter de jdeCacheTerminate ou jdeCacheFreeCursor correspondant à la fin de la section, et l'empreinte mémoire du processus augmentera de manière linéaire avec le nombre de lignes. Un processus RUNBATCH passant de 40 Mo initiaux à plus de 3 Go pendant l'exécution est presque toujours causé par des allocations de tas (heap allocations) non libérées dans du code C hérité.

La même dégradation de mémoire se produit lorsque les développeurs utilisent des fonctions système Open Table ou des handles de base de données bruts dans les Event Rules et omettent de les associer à un appel explicite Close Table dans l'End Section ou l'événement Destroy Global Bank. Laisser un handle de table non fermé par itération entraîne des fuites de curseurs de base de données sur le serveur de base de données tout en figeant les objets de handle dans la mémoire du middleware JDE. Sur un traitement batch de 250 000 lignes, cet épuisement des handles provoque régulièrement l'engorgement du pool de connexions à la base de données, faisant planter les jobs parallèles sur l'enterprise server.

Lorsqu'elles sont gérées correctement, les structures en mémoire jdeCacheUn espace de stockage temporaire en mémoire vive utilisé par JD Edwards pour accélérer l'accès aux données répétitives. offrent des gains de performance spectaculaires plutôt que des fuites de mémoire. Mettre en cache des données de validation statiques — telles que les constantes de site/magasin de la F41001 ou des enregistrements de correspondance — dans un handle de cache C global pendant l'Initialize Section élimine entièrement les appels d'E/S redondants. Remplacer 100 000 opérations SQL SELECT individuelles par des recherches de pointeurs mémoire réduit la latence des appels de base de données de 80 % à 90 % sur les exécutions de batchs à fort volume, ramenant les temps d'exécution de plusieurs heures à quelques minutes.

Exécuter un profilage SQL préliminaire dans les logs de debug

Ne promouvez jamais un UBE personnalisé hors du développement (DV) sans capturer un fichier jdedebug.log de niveau trace lors d'un test représentatif. Ouvrir le log et inspecter l'instruction SQL SELECT littérale construite par le middleware JDE — en particulier la clause WHERE — révèle des scans complets de table masqués sur des tables de plusieurs millions de lignes comme la F0911 ou la F4111 avant même que ce code n'atteigne le Prototype (PY) ou la Production (PD). Les développeurs supposent souvent que le moteur UBE utilise l'index sélectionné dans le Report Design Aid (RDA), mais une sélection de données complexe dans les règles d'événements ou des surcharges SQL dynamiques peuvent supprimer silencieusement les contraintes d'index, forçant le moteur de base de données à effectuer des scans de table coûteux.

Quantifiez les performances en DV en calculant les métriques de temps d'exécution pour 10 000 enregistrements traités. Soustraire l'horodatage du premier appel d'API FET (fetch) du dernier appel de fetch dans le log donne le temps réel de base de données par rapport à la surcharge de traitement des Event Rules. Si le traitement de 10 000 lignes prend plus de 1,5 à 2,0 secondes au niveau de la base de données lors de l'exécution des specs locales, la sélection de l'index ou la condition de jointure est défectueuse. Corriger cela au niveau du poste de travail ne prend que quelques minutes ; dépanner un traitement batch en cours d'exécution qui verrouille la F0101 ou la F4211 en Production coûte des milliers d'euros en impact opérationnel.

Lors de la conception de rapports d'extraction qui écrivent directement dans des tables de travail personnalisées, des fichiers CSV ou des interfaces d'exportation, désactivez complètement le moteur de rendu RDA. Activer l'appel de la fonction système "Suppress Section Writing" sur les sections de détail et marquer les sections utilitaires comme "Hide Section" réduit la surcharge de traitement de 30 % à 50 %. L'Enterprise Server consacre des cycles CPU substantiels à formater les tampons de page PDF, évaluer les métriques de police et calculer le nombre de lignes, même si la sortie du batch n'est jamais imprimée. Désactiver les éléments de rendu visuel transforme un rapport lourd en mise en page en un traitement batch rationalisé à haut débit.

L'application de ces standards de checklist avant de promouvoir les specs de batch personnalisées hors de DV garantit que les temps d'exécution des rapports restent de l'ordre de quelques minutes plutôt que de bloquer les files d'attente de l'entreprise pendant des heures.