Lorsqu'une fenêtre d'exécution batch nocturne de quatre heures déborde après 06h00 du matin et entre en collision avec le poste du matin, le jeu des accusations est prévisible. La CNCConfigurable Network Computing : l'architecture technique et d'administration système de JD Edwards. rejette la faute sur des rapports personnalisés incontrôlés, tandis que les développeurs insistent sur le fait que l'équipe d'infrastructure doit simplement attribuer plus de threads aux files d'attente de travaux ou ajouter un serveur d'entreprise (Enterprise ServerServeur dédié à l'exécution des traitements batch et de la logique métier JDE.). À travers des décennies de déploiements d'entreprise, l'ajout de matériel pour résoudre un retard de traitement batch ne fonctionne presque jamais ; c'est en réalité la mauvaise exécution des responsabilités des développeurs concernant la performance de l'ordonnanceur UBEUniversal Batch Engine : le moteur de génération de rapports et de traitements par lots dans JDE. JDEJD Edwards : progiciel de gestion intégré (ERP) développé par Oracle. qui bloque les files d'attente et asphyxie les moteurs de base de données.
Les ingénieurs CNC configurent les règles de concurrence, les groupes de serveurs et les définitions de planification, mais ils ne peuvent pas corriger les E/SEntrées/Sorties : opérations de lecture et écriture sur le disque ou la base de données. sur des tables non indexées, les périmètres de transaction non limités ou les fuites de mémoire compilées dans des fonctions métier C personnalisées. Traiter la dégradation de la planification batch strictly comme un problème d'infrastructure garantit des ruptures récurrentes de SLAService Level Agreement : niveau de service garanti en termes de délais et de disponibilité.. Pour résoudre ce problème, il convient de tracer une frontière stricte entre les contrôles opérationnels des files d'attente par la CNC et le devoir du développeur de concevoir des pipelines de données propres et un cycle de vie mémoire résilient au sein de la logique UBE.
Définir la frontière : Périmètre des développeurs vs Opérations CNC
Lorsqu'un calendrier batch nocturne à fort volume dépasse son SLA, les administrateurs CNC reçoivent généralement le premier appel, mais les contrôles d'infrastructure ne peuvent pas corriger un code inefficace. La CNC gère l'environnement d'exécution : l'ajustement des entrées d'ordonnanceur F91300, le mappage des définitions de file d'attente de travaux F986130 et l'équilibrage des affectations de groupes de serveurs. Ils surveillent les états d'exécution des traitements dans la table de contrôle des travaux F986110, mais la repriorisation des files et la mise à l'échelle matérielle ne peuvent résoudre le cas d'un rapport qui boucle continuellement sur des opérations de tables non indexées.
Les développeurs sont responsables de l'efficacité d'exécution interne du code s'exécutant dans ces files d'attente batch. Ce périmètre englobe l'architecture de sélection des données, les stratégies d'indexation des vues métier (Business ViewsVues de base de données définies dans JDE pour lier et filtrer les tables.), la fréquence d'exécution des E/S sur les tables et la gestion de la mémoire au sein des Business FunctionsModules de code (C ou ER) réalisant des traitements métier réutilisables. personnalisées. Si un développeur place un « Fetch Single » à l'intérieur d'une Do Section qui évalue des centaines de milliers d'enregistrements sans utiliser d'index de table appropriés ou de handles mis en cache, la couche de base de données devient le goulot d'étranglement, quelles que soient les allocations de CPU du serveur hôte.
La friction opérationnelle s'aggrave lorsque les équipes considèrent le multi-threadingExécution simultanée de plusieurs instructions ou threads de traitement. comme une solution universelle pour un code lent. Configurer une file d'attente multi-threadée pour un UBE non partitionné provoque des collisions de données, des attentes de verrouillage (lock waits) et de la corruption de données au lieu de gains de performance. Lorsque des threads parallèles tentent de mettre à jour des enregistrements identiques dans des tables comme F0902 ou F4111 sans contrôle explicite des limites de données, le blocage des threads immobilise totalement le moteur de file d'attente.
Un transfert opérationnel propre exige des développeurs qu'ils spécifient des profils d'exécution avant qu'un traitement batch personnalisé n'atteigne l'ordonnanceur. Les développeurs doivent documenter explicitement les modèles de dépendance des données, les durées d'exécution cibles, les plafonds de mémoire d'exécution et les contraintes de thread unique pour chaque rapport personnalisé. La fourniture de ce profil technique permet à la CNC de construire des architectures de files d'attente basées sur la conception applicative plutôt que sur des conjectures faites après des pannes.
Défauts de logique des développeurs qui engorgent les files batch
Les goulots d'étranglement dans les files d'attente batch sont rarement causés par des limites matérielles du serveur d'entreprise JDE Enterprise Server ; ils sont créés ligne par ligne dans les Event RulesLangage de script interne utilisé pour programmer dans JD Edwards.. La faille la plus coûteuse survient lorsque le code personnalisé exécute des E/S sur les tables à l'intérieur de la Do Section sans s'aligner sur un index valide de Business View. Sur une grande table F0911 contenant des dizaines de millions d'enregistrements, une instruction Select non indexée force le moteur de base de données à effectuer un balayage complet de la table (full table scanAnalyse ligne par ligne de toute la table par la base de données, impactant fortement la vitesse.) pour chaque ligne évaluée par le section driver, transformant une exécution rapide en un blocage de file de plusieurs heures.
Placer des boucles redondantes Fetch Single ou Select/Fetch Next à l'intérieur de la Do Section crée des millions d'aller-retour inutiles vers la base de données. Si une section driver évalue 200 000 lignes de détail de commandes de vente dans F4211 et appelle des E/S de table personnalisées dans la boucle, le traitement passe d'une jointure SQL optimisée à 200 000 requêtes SQL distinctes. Cela monopolise le thread d'exécution batch et consomme la capacité de la file pendant que d'autres travaux planifiés dépassent leurs SLA.
Les développeurs écrivent également des cumuls manuels dans les Event Rules au lieu de s'appuyer sur l'agrégation native de la base de données ou sur la fonctionnalité de totalisation de section. Le calcul ligne par ligne dans la logique ER entraîne un surcoût important d'interpréteur, augmentant considérablement l'utilisation du CPU sur les grands jeux de données. Décharger les agrégations sur des vues de base de données ou des BSFN C réduit de manière significative les cycles CPU de l'interpréteur ER, souvent de 60 % à 80 % sur les exécutions à fort volume.
L'utilisation abusive de Suppress Section Write aggrave ces problèmes opérationnels lors d'E/S en arrière-plan intensives. Masquer la sortie de section pendant un traitement en arrière-plan de longue durée empêche les opérateurs et l'équipe CNC de voir la croissance des journaux de sortie, ce qui les amène à supposer que le traitement est verrouillé (deadlock). Avant de mettre fin à un UBE non répondant dans Server Manager, interrogez les états d'attente de session de la base de données pour vérifier s'il y a des E/S physiques actives avant de conclure que le thread est bloqué.
Gestion des limites de commit et des fuites de mémoire dans les traitements batch
Lorsqu'un UBE personnalisé traite 50 000 lignes de détail de commandes de vente au sein d'une seule limite de transaction manuelle, il verrouille chaque ligne impactée dans F4211 jusqu'à ce que le traitement se termine. Ce bloc de transaction non limité conserve des verrouillages exclusifs de lignes pendant des heures, provoquant une grave asphyxie des files d'attente pour les UBE planifiés en aval comme R42800 ou R47031 qui tentent d'accéder à ces tables standard. Les développeurs doivent implémenter des intervallles de validation (commitValidation définitive des opérations d'écriture dans la base de données.) déterministes — généralement tous les 500 à 1 000 enregistrements — en utilisant les API JDB_BeginTransaction et JDB_CommitTransaction plutôt que de compter sur le commit automatique à la fin du traitement.
La gestion de la mémoire dans les BSFN C personnalisées appelées de manière répétée à l'intérieur des boucles principales de recherche UBE représente un risque structurel tout aussi dangereux. L'absence d'exécution de jdeCacheTerminate ou de libération des structures C allouées via jdeFree à travers des milliers d'itérations d'enregistrements génère des fuites de mémoire constantes. Ce comportement s'intensifie jusqu'à ce que l'empreinte mémoire du kernelProcessus système fondamental assurant l'exécution des traitements sur le serveur JDE. UBE de l'Enterprise Server dépasse 2 Go. Sur les environnements d'exécution standard 32 bits de JDE Enterprise Server, le dépassement de cette limite de processus de 2 Go déclenche un crash immédiat du kernel, laissant l'UBE planifié indéfiniment bloqué au statut « Processing » dans la table F986110.
Prévenir ce gonflement de kernel lors de traitements batch intensifs exige d'isoler les caches de recherche en lecture seule des tampons d'écriture transactionnels. Les données de référence statiques, telles que les constantes d'établissement (branch/plant) ou les taux de change, doivent être chargées dans un handle jdeCache en lecture seule lors de Initialize Section et détruites explicitement dans End Section. Mélanger des tampons d'écriture transactionnels avec des structures de recherche à longue durée de vie à l'intérieur de la boucle principale d'enregistrements accumule des pointeurs de cache non libérés. Cela augmente la mémoire tas (heap) du processus, dégrade les performances de pagination du système d'exploitation et finit par priver de ressources les files batch adjacentes partageant les ressources de l'Enterprise Server.
Conception d'UBE pour les files d'attente multi-threadées et les groupes de serveurs
Pour faire évoluer horizontalement les traitements batch lourds sur des files d'attente multi-threadées, les développeurs doivent partitionner explicitement les limites de données au niveau architectural. Une exécution unique et massive évaluant des centaines de milliers d'enregistrements de grand livre des ventes sur l'ensemble des unités opérationnelles engorge une file d'attente, tandis que le découpage de la charge de travail en plages de données distinctes — telles que des regroupements par établissement ou des préfixes de compte — permet un traitement parallèle sans contention de verrouillage de table. L'UBE driver évalue le volume total d'enregistrements et génère dynamiquement des instances UBE worker à l'aide de LaunchBatchProcessEx (B9800240), en passant des valeurs d'interconnexion localisées à chaque thread pour garantir l'absence de chevauchement des jeux d'enregistrements.
Coder en dur les noms d'hôtes des serveurs d'entreprise dans les fonctions métier C personnalisées rompt la conception d'infrastructure CNC. Lorsque la CNC configure des topologies de groupes de serveurs P98617 distribuant des UBE worker parallèles sur plusieurs nœuds Enterprise Server, des cibles codées en dur forcent l'exécution des threads sur un seul hôte, contournant les algorithmes de répartition de charge de JDE et créant des pics de CPU artificiels sur un nœud alors que d'autres restent inactifs. Transmettre des configurations de groupes de serveurs dynamiques permet au middleware JDE d'attribuer chaque instance worker au nœud le moins utilisé en temps réel.
L'exécution parallèle met en évidence des défauts de conception de données que les exécutions single-thread dissimulent. Si des UBE worker parallèles insèrent simultanément des enregistrements dans des tables personnalisées, le schéma de table sous-jacent doit intégrer des clés primaires déterministes — combinant généralement un ID unique d'exécution batch, un numéro de séquence et un horodatage de transaction — pour gérer en toute sécurité le traitement hors ordre. Des composants de clé primaire manquants ou l'utilisation de Next Numbers séquentiels sans mise en cache dédiée déclenchent des collisions de clés primaires JDB3100011 immédiates lors d'exécutions parallèles à haut débit.
Traitement par subsystem vs architecture batch planifiée
Les UBE de type subsystemTraitement d'arrière-plan permanent à l'écoute de nouveaux événements à traiter. fonctionnent comme des processus d'exécution persistants qui interrogent en continu la table Subsystem Job Master (F986113), nécessitant une architecture totalement différente de celle des travaux batch ponctuels. Une erreur courante dans le développement de subsystem personnalisés est l'omission d'états d'attente explicites au sein de la boucle de traitement. Sur les serveurs d'entreprise sous Tools Release 9.2.7, un UBE subsystem sans BSFN C jdeSleep intégrée ou sans intervalle de réveil configuré verrouille un thread d'exécution à une utilisation CPU élevée. Le processus exécute des millions de requêtes SQL SELECT inactives contre F986113 par heure, privant de ressources les files d'attente batch légitimes du serveur Enterprise Server.
Inversement, configurer un UBE standard pour qu'il s'exécute toutes les 60 secondes via l'ordonnanceur JDE sous forme de pseudo-subsystem est un anti-pattern qui dégrade les performances globales du système. Exécuter un seul travail sur une boucle d'une minute génère 1 440 enregistrements dans la table Job Control Status Master (F986110) chaque jour. Sur une période de 90 jours, ce seul rapport crée plus de 129 000 lignes de travaux caducs. Le démon de l'ordonnanceur JDE doit analyser cette table F986110 gonflée à chaque cycle de réveil, dégradant la réactivité de l'ordonnanceur et retardant les plannings de traitement batch nocturnes critiques.
La conception des Event Rules au sein des subsystems légitimes exige une libération immédiate des verrous d'enregistrements. Lorsqu'un processus subsystem lit des enregistrements de travail, exécute la logique métier et met à jour des tables cibles comme F4111 ou F0911, les limites de transaction doivent être strictly contenues au sein de l'itération. Laisser des verrous d'enregistrements ouverts en attendant le prochain cycle de réveil de la F986113 génère de graves blocages de base de données. Les développeurs doivent exécuter des mises à jour explicites de tables SQL et valider (commit) les transactions immédiatement après le traitement de chaque enregistrement, garantissant ainsi que les utilisateurs interactifs et les files batch secondaires ne rencontrent pas de cascades de blocages (deadlocks) pendant les heures de pointe.
Triage structuré des dépassements de SLA de planification batch
Lorsqu'un traitement batch nocturne planifié dépasse sa fenêtre d'exécution, le triage commence par l'analyse du fichier jdedebug.log et du journal d'exécution de l'UBE à travers un profileur d'exécution pour établir la répartition exacte entre le temps d'exécution SQL et le temps de traitement des Event Rules. Un état d'attente de 80 % sur des E/S de tables non indexées pointe directement vers un index manquant ou une structure de requête inefficace plutôt que vers un goulot d'étranglement d'infrastructure.
Si l'exécution SQL dépasse 70 % du temps total d'exécution, la responsabilité de la résolution incombe au développeur. Cela nécessite d'analyser les clauses WHERE générées à l'exécution, de créer un index composé ciblé dans Object Management Workbench, ou de refactoriser une Business View trop lourde pour éliminer les jointures de tables redondantes. Extraire 40 colonnes sur quatre tables jointes alors que le rapport n'évalue que deux champs génère un surcoût massif d'E/S de base de données qu'aucun serveur d'entreprise ne peut surmonter.
Lorsque les données de profilage montrent que l'exécution des Event Rules et des BSFN consomme la majorité du temps d'exécution, le problème réside entièrement dans la structure du code. Les développeurs doivent profiler l'arbre d'exécution pour éliminer les appels récursifs de BSFN, les recherches dans les User Cache non indexés et les boucles Do Section imbriquées qui déclenchent des aller-retour vers la base de données à chaque enregistrement. Refactoriser les recherches répétitives pour les extraire d'un cache en mémoire réduit systématiquement le temps de traitement logique.
Ajuster les paramètres de file d'attente ou attribuer des threads supplémentaires à une file batch doit être l'ultime étape. L'intervention de la CNC intervient à la fin de la séquence de triage, appliquée uniquement après que la validation du développeur confirme que l'UBE ne contient aucune faille algorithmique ni aucun problème de verrouillage. Créer des files d'attente multi-threadées face à un code non optimisé ne fait que multiplier les requêtes inefficaces sur la base de données, déplaçant le goulot d'étranglement au lieu de le résoudre.
Si votre équipe refactorise des rapports batch existants, repense des pipelines de données UBE à longue durée d'exécution ou établit des profils d'exécution pour vos files d'ordonnanceur d'entreprise, contactez notre équipe d'architecture JDE pour une revue technique.
