En plus de deux décennies d'audits de code JDE en entreprise, je vois encore régulièrement des développeurs concevoir des architectures batch fragiles en utilisant des tables de travail personnalisées (F55/F56) ou des surcharges d'options de traitement (Processing OptionsParamètres de configuration permettant de modifier le comportement d'un programme JDE sans altérer son code.) simplement pour transmettre un numéro de document, un type de lot ou un statut de traitement entre travaux batch. L'ajout d'une table de travail auxiliaire pour passer trois champs introduit des E/S base de données inutiles, des verrous de concurrence et des routines de nettoyage d'enregistrements orphelins pour une tâche que le runtimeEnvironnement d'exécution dans lequel s'exécutent les programmes informatiques. natif gère parfaitement de base.

Une structure de données (DSTR) Report InterconnectMécanisme natif de JD Edwards permettant de transmettre des paramètres entre rapports batch. bien conçue dans Report Design Aid (RDA)Outil de conception de JD Edwards utilisé pour créer et modifier des rapports batch. est le mécanisme standard et encapsulé permettant de transmettre des paramètres entre UBEUniversal Batch Engine, le moteur d'exécution des traitements par lots dans JD Edwards. parents et enfants. Lors de la configuration d'un Report Interconnect d'UBE JDE pour transmettre des valeurs entre rapports, la clé réside dans la maîtrise de la directionnalité des paramètres (IN, OUT, BOTH) et dans la gestion des compromis d'exécution entre modes synchrone et asynchrone. L'application de ces règles de conception au niveau de la structure de données élimine les dépendances d'état cachées et garantit que les traitements batch chaînés s'exécutent de manière prévisible en production.

Conception de la structure de données Report Interconnect

Un traitement batch cible doit considérer sa structure de données Report Interconnect comme un contrat d'APIInterface de programmation permettant à différents logiciels de communiquer entre eux. public et explicite. Ouvrir l'éditeur de structure de données Report Interconnect dans Report Design Aid (RDA) lient les éléments du Data DictionaryDictionnaire de données centralisé définissant le type et le format de chaque champ dans JDE. directement à l'en-tête du rapport sans ajouter de surcoût d'exécution au runtime. Cette structure définit précisément les paramètres entrants, les valeurs de retour sortantes ou l'état bidirectionnel que l'UBE enfant expose à tout objet parent appelant au sein de votre environnement.

Les indicateurs de direction — IN, OUT et BOTH — doivent être assignés de manière délibérée plutôt que d'accepter les valeurs par défaut de l'éditeur. Dans les routines C batch compilées que le runtime UBE exécute sur l'Enterprise ServerServeur principal qui exécute la logique métier et les traitements batch lourds dans JDE., des indicateurs de direction mal configurés créent des pièges de variables non initialisées ou des corruptions mémoire lorsque les pointeurs sont réassignés à la pile parent. Si un traitement batch enfant valide un numéro de lot sans le modifier, définir cet élément en paramètre IN garantit que le processus parent conserve une intégrité mémoire déterministe tout au long de l'exécution.

Liez des éléments concrets du Data Dictionary plutôt que des chaînes de caractères génériques telles qu'un EV01 de 100 caractères ou un TEXT200. Des éléments standards tels que MN22A (Math NumericType de données spécifique à JDE utilisé pour la gestion exacte des chiffres et décimales.) ou DOCO apportent un formatage natif de base de données, des règles d'édition et des métadonnées de décimales implicites dans la structure de données. Acheminer des montants en devise ou des unités de mesure via des mémoires tampons de caractères génériques supprime la gestion des décimales, introduisant des erreurs de troncature difficiles à tracer dans les rapports financiers ou de fabrication. Concevoir une structure de données Report Interconnect propre dès le premier jour évite les réadaptations ultérieures dans l'ensemble de votre architecture batch.

Modes d'exécution RI : Synchrone vs Asynchrone

Sélectionner l'option d'exécution synchrone — appelée « Wait for Completion » dans les Event RulesLangage de script événementiel utilisé pour programmer la logique métier dans JD Edwards. — force le thread du moteur UBE parent à interrompre son traitement à l'emplacement de l'appel. Le thread parent entre dans un état d'attente, scrutant le processus enfant jusqu'à ce qu'il atteigne sa phase finale de nettoyage et renvoie son code de statut de sortie. Ce comportement bloquant est obligatoire chaque fois que le parent attend des valeurs renvoyées par des paramètres OUT ou BOTH, comme un total de fret calculé ou un numéro de contrôle de lot mis à jour. Si l'enfant échoue, le parent reçoit ce statut directement, ce qui permet une gestion conditionnelle d'erreur immédiate sur la ligne de logique suivante.

Désactiver « Wait for Completion » fait passer l'exécution en mode asynchrone, ce qui amène JDE à appeler jdeLaunchUBEExFonction C interne de JDE permettant de démarrer l'exécution d'un traitement batch. pour lancer un traitement détaché dans la file d'attente batch désignée. L'UBE parent passe immédiatement à la ligne ER suivante sans attendre le démarrage du processus enfant. Par conséquent, tous les paramètres OUT ou BOTH de votre structure de données deviennent totalement inaccessibles ; le parent lit la valeur présente en mémoire avant même l'initialisation de l'enfant. Les développeurs qui tentent de renvoyer des totaux calculés à un UBE parent via un RI asynchrone observeront des allocations mémoire vides car le runtime ne mappe jamais les valeurs de retour entre des handles de travaux détachés.

Dans des configurations de files d'attente multithread exécutant 4 à 8 threads de traitement en parallèle, les lancements asynchrones introduisent des conditions de concurrence (race conditions)Bugs survenant lorsque le résultat dépend de l'ordre d'exécution imprévisible de plusieurs processus. silencieuses. Si un rapport parent lance un UBE enfant asynchrone pour traiter des enregistrements et interroge immédiatement la table F0911 pour obtenir ces mises à jour, le parent exécute sa requête SELECT avant que l'enfant n'ait terminé son JDB_CommitUserTransaction. Pour garantir l'intégrité des données sans coder en dur des boucles d'attente artificielles dans les ER, forcez l'exécution synchrone et activez « Include Transaction » chaque fois que les commits en base de données de l'enfant doivent être visibles par la logique ultérieure du parent.

Implémentation dans l'UBE parent : appeler le rapport enfant

Placer un appel Report Interconnect dans un événement indéterminé comme Initialize Section ou End Page break crée des bugs de séquencement intermittents qui font perdre un temps précieux dans le débogueur. Dans les UBE en production, invoquez la fonction système Report Interconnect exclusivement au sein de points d'exécution déterministes — typiquement Do Section lors du traitement ligne par ligne, ou After Section Print lors du déclenchement d'actions de synthèse agrégées. Cela garantit que votre traitement batch enfant ne s'exécute qu'après l'évaluation du formatage conditionnel et de la logique de suppression de section par le moteur de données.

Le mappage des paramètres dans l'interface d'appel ER exige une hygiène rigoureuse des variables. Mappez les valeurs directement à partir des colonnes de Business ViewVue logique combinant une ou plusieurs tables pour alimenter un rapport ou un écran JDE. (BC), de Report Variables (RV) ou de Processing Options (PO) dont la portée correspond aux limites de la section courante. Transmettre des variables globales au niveau du rapport non initialisées et dépendantes de l'exécution d'une section précédente injecte fréquemment des valeurs nulles ou des adresses mémoire obsolètes dans la structure du rapport enfant. Si une valeur provient d'un calcul, liez-la explicitement à une variable au niveau de la section dans le bloc d'événements qui précède immédiatement l'appel.

Coder en dur la chaîne de caractères de la version enfant cible directement dans l'assistant de fonction système crée des goulots d'étranglement de maintenance entre les environnements de non-production et de production. Transmettez l'identifiant de version de manière dynamique via une expression ER ou une option de traitement (Processing Option) dédiée, permettant ainsi aux équipes d'exploitation d'acheminer les charges de travail vers différentes files d'attente de sous-systèmes ou modèles de sélection de données sans extraction d'objets (check-out).

Enfin, traitez l'appel d'interconnexion comme un point d'interface sujet aux défaillances. Vérifiez toujours la valeur de retour d'exécution immédiatement après l'instruction de fonction système au lieu de supposer que l'UBE enfant s'est lancé correctement. Évaluer les variables d'état du système immédiatement après des appels synchrones fournit le point d'ancrage programmatique requis pour consigner un échec dans la sortie PDF, ignorer les lignes de transaction suivantes ou interrompre un pipeline batch multithread avant d'altérer les tables de staging.

Implémentation dans l'UBE enfant : consommer le RI dans les Event Rules

Les valeurs de la structure de données mappées depuis l'UBE parent sont instanciées dans la mémoire runtime avant le déclenchement de l'événement Initialize Report. Ce séquencement événementiel garantit que les options de traitement, les variables ER et les filtres de section du cycle de vie de l'enfant disposent d'une visibilité complète sur le tableau de paramètres. Le runtime liant ces valeurs immédiatement lors de la création du processus, la logique de consommation peut être proprement consolidée au début du flux d'exécution du rapport plutôt que dispersée dans divers événements.

Le schéma le plus fiable pour le filtrage dynamique repose sur l'appel de la fonction système Set User Selection dans l'événement Initialize Section de la section enfant. Transmettre un paramètre RI — tel que RI szDocumentPayItem ou RI mnAddressNumber — directement dans Set User Selection avec un opérateur EQUAL et une logique de jonction AND applique des clauses SQL WHEREInstruction SQL servant à filtrer les enregistrements extraits d'une base de données. appuyées par un index. L'exécution de cette logique dans Initialize Section garantit que le moteur de base de données compile le filtre avant d'ouvrir le curseur SQL principal, évitant ainsi le balayage complet de grandes tables non indexées comme F0911 ou F4211.

Une conception ER défensive nécessite d'évaluer si les variables RI entrantes contiennent des données valides avant de surcharger la logique de sélection. Si un utilisateur lance le rapport enfant de manière autonome via Batch Versions, des variables RI vides ou à zéro altéreront le filtrage attendu. Évaluer If RI szOrderType is NOT equal to <Blank> dans les Event Rules permet à l'objet enfant de basculer de manière conditionnelle sur les Processing Options standards, préservant ainsi sa capacité à être exécuté comme un rapport batch ponctuel (ad-hoc).

La capture de métriques à renvoyer au parent exige une discipline événementielle stricte lors de la fin du rapport. L'assignation de valeurs runtime aux champs RI sortants doit s'effectuer soit dans l'événement After Last Object Printed de la section principale, soit dans l'événement global End Report. Alimenter des variables RI sortantes à l'intérieur d'une boucle Do Section risque de renvoyer des agrégations incomplètes à l'UBE appelant lors du traitement de grands jeux de données répartis sur plusieurs sauts de page.

Anti-patterns d'architecture : tables de travail vs RI direct

Écrire des états d'exécution dans des tables de staging F55Tables sur mesure dans JDE servant de zone de stockage temporaire pour les données. personnalisées simplement pour transmettre des clés batch entre rapports est un schéma obsolète qui dégrade le débit des files d'attente batch. Chaque insertion, recherche et suppression sur une table de staging F55 engendre un surcoût d'E/S réseau et disque, multipliant la latence sur les exécutions batch à fort volume. Lorsque des UBE enfants s'arrêtent de manière anormale en raison d'exceptions mémoire ou de plantages de kernel, la logique de nettoyage obligatoire échoue, laissant des enregistrements orphelins qui polluent les exécutions ultérieures et déclenchent des erreurs de clé en double faux-positifs.

Les développeurs qui tentent d'éviter les E/S base de données en passant des pointeurs mémoire via des structures de BSFN cacheMémoire tampon temporaire gérée par des fonctions C (Business Functions) dans JDE. se heurtent à un autre obstacle opérationnel : les frontières de processus. Alors qu'un pointeur de cache C réside proprement en mémoire au sein d'un unique kernel CALLKS de l'Enterprise Server, les UBE enfants routés vers des files d'attente multithread démarrant fréquemment sous des processus RUNBATCH distincts, voire sur des serveurs batch physiques séparés. Le traitement enfant tente alors de déférencer une adresse mémoire qui n'existe pas dans son espace d'adressage local, entraînant des échecs d'exécution silencieux immédiats ou des plantages sévères du kernel (kernel crashes).

Le passage direct de valeurs via la structure de données de l'UBE contourne complètement les verrous du moteur de base de données et les frontières d'isolation de processus. Le processus parent empaquète le tampon de paramètres directement dans la pile d'appel d'exécution, transmettant les valeurs runtime dans la section d'initialisation de l'UBE enfant sans solliciter la base de données ou la mémoire partagée. Cela élimine la contention de verrouillage de table et les collisions de concurrence multithread sur les kernels Enterprise Server 64 bits, permettant aux files d'attente de traitement parallèle d'évoluer de manière fluide.

La refactorisation d'un pipeline legacy de distribution financière ou de stock, passant d'une architecture de table de travail F55 à des paramètres directs, réduit couramment le temps d'exécution global des traitements batch de 15 % à 40 %. Éliminer des milliers d'écritures intermédiaires en table par exécution batch libère les buffer poolsEspace de mémoire vive réservé par la base de données pour conserver les données en cache. de la base de données pour les utilisateurs interactifs tout en supprimant la charge de maintenance des scripts de purge.

Débogage et test des appels Report Interconnect

Exécuter pas à pas les appels Report Interconnect localement sur un Web Dev ClientEnvironnement de développement local permettant de tester et déboguer les applications JDE. offre une visibilité totale de part et d'autre de la frontière d'exécution. Lors d'une exécution synchrone dans le débogueur d'Event Rules, placer un point d'arrêt sur l'instruction d'interconnexion vous permet de passer directement (step into) dans l'événement Initialize Section du rapport enfant sans perdre le contexte de débogage. Si vous passez au-dessus (step over) au lieu d'entrer, le débogueur termine le thread en arrière-plan de manière silencieuse et s'arrête sur l'instruction parent suivante. Ce traçage local isole les erreurs de mappage de portée des variables en quelques minutes, vous évitant de déployer des packages d'objets non testés sur les serveurs d'entreprise.

Lors du diagnostic d'une corruption de paramètres sur un Enterprise Server, le fichier jdedebug.logFichier journal de débogage généré par JDE traçant chaque instruction exécutée. fournit le vidage (payload dump) définitif, traçant les adresses de décalage (offsets) des paramètres et les structures mémoire hexadécimales. Sous Tools Release 9.2.x en architecture 64 bits, portez une attention particulière au remplissage d'alignement (padding) des structures de données sur les kernels AIX et Linux. Placer un indicateur caractère de 1 octet directement devant un pointeur de 8 octets ou une structure mathématique sans alignement explicite crée des écarts de frontière, provoquant le décalage des valeurs de paramètres dans des offsets d'octets incorrects lorsqu'ils sont transmis à l'UBE enfant.

L'exécution asynchrone côté serveur présente un piège de débogage particulier : le statut du traitement parent dans la table F986110 passe à 'D' alors que le rapport enfant est toujours en file d'attente ou échoue silencieusement. Vous devez effectuer un examen croisé des fichiers UBE_*.log du parent et de l'enfant dans le répertoire d'impression (print queue) du serveur pour détecter les surcharges de file d'attente, les erreurs de conversion d'environnement ou la troncature de données. Standardiser sur les structures de données natives Report Interconnect apporte aux architectures batch EnterpriseOne une gestion déterministe des paramètres, une exécution prévisible des files d'attente multithread et une isolation mémoire propre sans le surcoût de tables de staging personnalisées.