Lorsqu'un traitement batchExécution automatique d'un ensemble de tâches informatiques sans intervention humaine. personnalisé de 50 000 enregistrements rencontre une exception mémoireErreur survenant lorsqu'un programme tente d'accéder à une mémoire indisponible ou invalide. non gérée ou un verrouillage de base de donnéesMécanisme empêchant plusieurs processus d'interférer lors de la modification simultanée des mêmes données. à l'enregistrement 38 000, un enregistrement d'audit naïf transforme une reprise propre en un désastre opérationnel. Ajouter des instructions Insert ou Update brutes dans l'événement Do Section sans limites de transaction explicites garantit des erreurs de clé en doubleErreur produite lors de la tentative d'insertion d'une valeur de clé primaire déjà existante. (erreur JDB 0002) ou des lignes d'audit orphelines dans des tables personnalisées telles que F550911A dès que l'équipe d'exploitation redémarre le traitement.

Implémenter un exemple fiable de Table IOOpérations d'entrée/sortie (lecture, écriture, mise à jour) directement sur les tables dans JD Edwards. JDE UBEUniversal Batch Engine : composant de JD Edwards exécutant les traitements batch. pour mettre à jour une table d'audit personnalisée en toute sécurité nécessite une logique d'Event RulesLangage de règles métier et d'évènements propre à JD Edwards. strictly idempotentePropriété d'une opération produisant le même résultat, qu'elle soit exécutée une ou plusieurs fois., des recherches de clé défensives et un alignement délibéré avec les limites du contrôle d'engagementGestion des transactions (commitment control) garantissant la cohérence des opérations. EnterpriseOneProgiciel de gestion intégré (ERP) développé par Oracle. (commitment control). Si une exécution batch interrompue oblige un développeur à exécuter un nettoyage SQL manuel avant que l'UBE ne puisse être réexécuté, l'architecture Table I/O est fondamentalement défaillante.

Conception de tables d'audit personnalisées pour la réexécution d'UBE

La plupart des échecs d'audit en traitement batch proviennent d'une conception de clé primaireIdentifiant unique d'un enregistrement dans une table de base de données. défectueuse plutôt que de règles d'événements (Event Rules) erronées. Si vous construisez la table d'audit personnalisée F550911A en utilisant une clé primaire de remplacement (UKID) récupérée via X00022, l'exploitation générera des lignes d'audit en double à chaque fois qu'un traitement nocturne s'interrompt au milieu d'une exécution de 500 000 enregistrements et se trouve redémarré. La base de données attribue de nouveaux numéros de séquence lors de la seconde passe, ce qui fragmente le suivi historique et fausse les rapports de réconciliation.

L'imposition d'une clé naturelle compositeClé primaire formée par la combinaison de plusieurs colonnes métier existantes. comprenant le numéro de document (DOCO), le type de document (DCTO), la société du document (KCO), le numéro de ligne (LNID) et la date de mise à jour (UPMJ) offre une idempotenceGarantie qu'exécuter un traitement plusieurs fois donne le même résultat sans altération. structurelle directement au niveau de la base de données. Lorsqu'une réexécution traite une transaction déjà gérée, l'UBE rencontre une collision de clés existante au lieu d'écrire des lignes de journal fantômes. Cette architecture permet à la logique du batch de rediriger proprement l'exécution vers une branche de mise à jour ou d'enregistrer un contournement bénin sans suivi d'état externe.

Contrairement aux applications interactives dans Form Design AidOutil de développement d'interfaces utilisateur interactives dans JD Edwards. (FDA) où le moteur d'exécution alimente automatiquement les colonnes d'audit, la Table I/O dans Event Rules exige un mappage explicite pour chaque opération d'écriture. Vous devez mapper manuellement SL UserId (USER), SL ProgramId (PID), SL MachineKey (JOBN), SL DateToday (UPMJ) et SL TimeOfDay (TDAY) dans le tampon de Table I/O. Laisser ces champs non mappés écrit des métadonnées vides ou remplies de zéros dans la base de données de l'entreprise, ce qui invalide immédiatement les audits de conformité.

Le choix de l'index dicte directement la granularité des verrous et le débit lors du parcours de jeux de données à fort volume. Si la séquence de l'index principal ne correspond pas exactement aux critères de clés dans vos appels de mise à jour Table I/O, le gestionnaire de base de données passe d'un verrouillage fin au niveau de la ligne à un verrouillage plus large de page ou de table. Aligner précisément la définition de votre index Table I/O sur la clé naturelle composite élimine la contention de verrous et évite les deadlocksInterblocages où deux processus s'attendent mutuellement, bloquant l'exécution. (verrous moraux) avec d'autres traitements batch concurrents.

Emplacement de la Table IO : logique Do Section vs End Section

Exécuter un Fetch Single, Insert ou Update explicite en Table I/O directement à l'intérieur de l'événement Do Section exécute un cycle de curseur de base de données distinct pour chaque itération de la vue métierVue de base de données associant des tables pour alimenter un rapport ou traitement JDE. principale (driver business view). Sur un traitement batch de 100 000 lignes — typique pour le traitement de commandes de vente ou les réconciliations de stock en fin de nuit —, cela se traduit par 100 000 aller-retours individuels à la base de données sur le réseau. À moins que les exigences de conformité n'imposent strictement la journalisation d'audit transactionnel enregistrement par enregistrement, ce choix de conception dégrade le débit du batch, faisant facilement passer une exécution UBE de 4 minutes à plus de 45 minutes.

Vous pouvez réduire de plus de moitié les aller-retours vers la base de données en pilotant la Table I/O de manière conditionnelle plutôt qu'en l'exécutant à chaque cycle d'enregistrement. Évaluez les indicateurs d'état — comme le statut de commande LTTR ou le fanion de traitement EDI EDSP — et n'émettez des écritures d'audit que lorsque des changements d'état surviennent. Surtout, conservez la Table I/O totalement à l'écart de l'événement After Record is Fetched. JDE traite cet événement avant d'évaluer les critères de filtrage au niveau de la section ou la logique Suppress Section Write au niveau du moteur. Écrire des enregistrements d'audit dans After Record is Fetched garantit que votre table d'audit enregistrera des lignes que le moteur d'édition éliminera au final.

L'écriture des métriques d'agrégation et des états d'exécution finaux appartient strictly à l'événement End Section. Cet événement ne se déclenche qu'une seule fois après la fin de la boucle de traitement principale sur l'ensemble du jeu de données, sans erreur non gérée. Utilisez End Section pour écrire les totaux récapitulatifs du batch, les valeurs financières globales et les horodatages d'exécution finaux dans votre table d'audit personnalisée. Restreindre les écritures de synthèse à l'événement End Section évite d'introduire des verrous de base de données en cours de traitement dans la boucle principale tout en garantissant que votre enregistrement d'audit final reflète fidèlement le cycle d'exécution terminé.

Structuration des conditions d'écriture pour éviter les enregistrements en double

Exécuter un Insert aveugle en Table I/O dans une table d'audit personnalisée garantit un échec non géré dès qu'un traitement batch est exécuté sur des données existantes. Le runtime JDE intercepte la violation de contrainte d'unicité sous-jacente lors de JDB_InsertTable, écrit une erreur dans le fichier jde.log et met le batch en échec. Dans des traitements volumineux de 50 000 enregistrements, une seule clé en double sur l'enregistrement 49 999 transforme une exécution de 40 minutes en un traitement interrompu qui laisse les tables cibles désynchronisées par rapport à votre journal d'audit.

Éliminer ce mode d'échec nécessite d'appliquer un modèle de lecture défensive (defensive fetch) explicite avant d'émettre des appels d'écriture. Dans vos Event Rules, passez la clé primaire complète — généralement des champs comme DOCO, DCTO, KCOO et un numéro de ligne ou de séquence — dans un Fetch Single Table I/O ciblant directement l'index principal. Cette opération interroge l'état de la table sans verrouiller la ligne et renseigne immédiatement la variable système SV File_IO_Status pour piloter la logique d'exécution.

Évaluez SV File_IO_Status immédiatement après la lecture. Lorsque le statut vaut CO SUCCESS, la ligne d'audit existe déjà suite à une étape précédente ou une exécution interrompue. Orientez votre logique ER vers un Update en Table I/O mappé strictement sur les champs de clé primaire exacts, rafraîchissant les horodatages d'audit, les compteurs de tentatives ou les valeurs de données utiles.

Lorsque SV File_IO_Status prend la valeur CO RECORD_NOT_FOUND, dotez le flux d'exécution d'un Insert Table I/O. Alimentez le tampon d'insertion avec des variables d'Event Rules réinitialisées de manière explicite, plutôt qu'avec des variables de rapport non assignées conservant une mémoire résiduelle d'itérations précédentes de la section. Structurer les conditions d'écriture selon cette séquence déterministe préserve la fiabilité de la Table I/O, protège l'intégrité de l'index de la base de données et garantit que l'UBE peut être réexécuté sans générer d'erreurs SQL de clés en double.

Gestion de la sécurité des transactions et du contrôle d'engagement

Par défaut, la Table I/O classique dans les Event Rules s'exécute en mode auto-commitMode de validation automatique enregistrant immédiatement chaque modification en base de données., de façon totalement indépendante de la limite de transaction sous-jacente de la section UBE. Si vous émettez un Insert ou un Update dans une table d'audit personnalisée F554111A à l'intérieur de l'événement Do Section tout en générant des enregistrements de journal standard dans F0911, ces opérations s'exécutent sur des handles de connexion distincts. Un verrou mortel (deadlock) de base de données, une annulation de batch ou une erreur d'hôte d'exécution au 450e enregistrement déclenchera un rollbackOpération restaurant la base de données à son état antérieur à la transaction. du moteur sur la vue métier F0911 principale, mais votre table F554111A personnalisée conservera des enregistrements d'audit orphelins et corrompus pour les lignes 1 à 449.

Pour synchroniser ces opérations sans écrire de code C, activez la propriété Include in Transaction dans la boîte de dialogue des propriétés de la section UBE (UBE Section Properties). Ce paramètre force toutes les instructions native Table I/O d'Event Rules exécutées dans cette section à intégrer le périmètre de la transaction géré par le pilote principal de la vue métier. Lorsqu'une erreur de traitement ou une interruption au niveau de l'hôte déclenche un rollback du batch, le moteur JDB annule vos lignes d'audit personnalisées en même temps que les modifications de tables JDE standard, préservant ainsi une cohérence d'état absolue entre toutes les tables impliquées.

Le traitement déclaratif des transactions au niveau de la section échoue lorsque la table d'audit personnalisée réside dans une source de données (data source) de base de données séparée — comme une base de données d'analyse décisionnelle distincte ou un schéma de sécurité dédié défini dans l'Object Configuration ManagerComposant JDE associant les objets applicatifs à leurs bases de données cibles. (OCM). Le middleware JDB ne peut pas enrôler automatiquement des handles de bases de données multi-sources dans un périmètre de transaction unique au niveau de la section. Résoudre ce problème nécessite de contourner la Table I/O native d'ER et d'appeler des fonctions C (Business Functions) utilisant JDB_BeginTransaction, JDB_CommitUser et JDB_RollbackUser afin de coordonner explicitement les commits à travers des connexions de base de données séparées. Passer des handles de transaction explicites (HUSER et HREQUEST) garantit que même les écritures d'audit multi-sources de données subissent un rollback propre lors des échecs de traitements batch volumineux.

Gestion des interruptions de batch et limites de redémarrage idempotentes

Lorsqu'un traitement batch plante au milieu du traitement de 50 000 enregistrements, le nettoyage SQL manuel représente un risque opérationnel que la conception doit éliminer dès le départ. Vous devez gérer la resoumission directement dans les Event Rules en utilisant le modèle de redémarrage natif des UBE JDE de base tels que R09801. Concevez vos options de traitement (Processing Options) pour offrir aux opérateurs un mode de réexécution explicite — leur permettant de choisir entre retracer les enregistrements non validés, traiter uniquement les erreurs ou forcer une réécriture au niveau de l'exécution. Sans mode de traitement clair défini dans le modèle d'option de traitement, les opérateurs créeront inévitablement des doublons ou ignoreront des enregistrements en échec lors de la reprise.

L'idempotence nécessite une colonne d'état dédiée dans votre table d'audit F55, comme EDSP (Processed Code) ou un fanion EV01 mis à jour à 'P' lors d'un commit réussi. Dans l'événement Initialize Section, le code du pilote doit inspecter la table d'audit pour établir le niveau de référence supérieur (high-water mark) des enregistrements validés avant le démarrage de la boucle principale. Valider ce statut par rapport aux lignes de journal source dans F0911 ou F4711 garantit que la réexécution d'un UBE interrompu ignore les transactions déjà traitées sans lever de violations de clé primaire.

Purger les enregistrements partiels ou corrompus d'une exécution interrompue exige des contraintes strictes en Table I/O. N'émettez jamais une instruction Delete non restreinte sur la table F55. Limitez la portée de votre Delete en Table I/O en utilisant strictly une clé composite correspondant au numéro de job (SV JobNumber), à la date d'exécution (SV DateUpdated) et à l'ID utilisateur (SV UserId). Cela isole et supprime uniquement les enregistrements orphelins écrits lors de l'exécution échouée tout en conservant les données d'audit historiques totalement intactes.

Dans les environnements d'entreprise, la grande majorité des interruptions de batch découle de dépassements de délais réseau temporaires ou d'échecs d'allocation mémoire sur l'Enterprise ServerServeur central exécutant la logique applicative et les batchs dans JD Edwards.. Construire votre logique d'audit F55 autour de la détection du seuil de référence supérieur et d'opérations Table I/O ciblant spécifiquement le job garantit que la resoumission de l'UBE produit exactement le même état, qu'il faille une ou trois tentatives.

Implémentation dans les Event Rules : la Table IO sécurisée pas à pas

S'en remettre aux connexions réseau implicites du moteur JDE pour des écritures d'audit personnalisées constitue un risque latent en production. Dans l'événement Initialize Section, émettez une instruction Open Table I/O explicite assignant votre table d'audit personnalisée (par exemple F55411A) à un handle de table dédié (hUserTableHandle). Ouvrir le handle de façon explicite pendant l'initialisation de la section garantit que le surcoût de connexion à la base de données ne survient qu'une seule fois par exécution UBE, au lieu de s'ouvrir et de se fermer de manière implicite pour chaque ligne d'un traitement de 100 000 enregistrements.

À l'intérieur de l'événement Do Section, réinitialisez toutes les variables de rapport et valeurs de structure de données mappées à la table d'audit avant d'exécuter des opérations de lecture ou d'écriture. Ne pas réinitialiser les variables telles que RV szErrorMessage ou RV mnAuditAmount entraîne des fuites de tampon mémoire classiques, où la valeur du 499e enregistrement persiste silencieusement dans le 500e si ce dernier retourne un champ nul en base de données. Exécutez un Fetch Single Table I/O en utilisant votre handle de table ouvert, en lui passant les composants de clé primaire (tels que BC szOrderKey et BC idDocumentType).

Évaluez immédiatement la valeur système SV File_IO_Status après l'appel de lecture. Si SV File_IO_Status est égal à CO SUCCESS, orientez la logique vers un Update Table I/O mappé sur la clé primaire ; s'il renvoie CO ERROR (indiquant que l'enregistrement est absent), basculez directement vers un Insert Table I/O. Encadrez les deux branches d'un contrôle conditionnel sur SV File_IO_Status après l'opération d'écriture, en consignant tout fanion d'échec dans une variable de rapport pour la sortie de diagnostic, afin que l'exécution batch se termine avec une visibilité opérationnelle complète au lieu d'échouer silencieusement.

Enfin, passez à l'événement End Section pour exécuter un Close Table I/O explicite sur le handle hUserTableHandle. Laisser des handles de table non fermés contraint le moteur de l'Enterprise Server à maintenir des curseurs de base de données ouverts jusqu'à ce que le processus UBE se termine. Sur des traitements batch importants de 50 000 enregistrements répartis sur plusieurs sous-sections, des handles non fermés épuisent fréquemment les limites de curseurs de la base de données (comme Oracle ORA-01000Erreur de base de données Oracle indiquant un nombre excessif de curseurs ouverts. OPEN_CURSORS = 300), générant des erreurs ORA-01000 en cours d'exécution et interrompant le traitement.

Structurer vos Event Rules autour de handles de table explicites, de vérifications de clés défensives et de limites de transactions synchronisées garantit que vos traitements batch s'exécutent de façon fiable et se rétablissent proprement après des interruptions sans nécessiter d'intervention manuelle.