Lancer un débogueur C comme Microsoft Visual Studio pour parcourir une Named Event Rule (NER)Langage de programmation spécifique à JD Edwards permettant de créer de la logique métier sans écrire directement en C. est souvent inutile et chronophage. Pour la plupart des développeurs JD EdwardsSuite logicielle de gestion d'entreprise (ERP) développée par Oracle., une approche plus efficace du débogage JDE NER consiste à tracer les event rulesInstructions logiques déclenchées par des actions de l'utilisateur ou du système dans JDE. déclenchées directement depuis un appel d'application en utilisant les capacités de journalisation natives du moteur d'exécution. En analysant systématiquement la pile d'appels, les mappages de paramètres et les codes de retour dans le log de débogage local, vous pouvez rapidement isoler la cause racine des échecs transactionnels sans la lourdeur de la compilation des symboles de débogage ou de l'attachement de processus externes.

L'interface APPL-vers-NER : Cartographier la pile d'appels

Lorsqu'un utilisateur clique sur le bouton OK de l'application Sales Order Entry (P4210), le moteur d'exécution exécute une pile d'appels complexe, déclenchant souvent 30 à 60 appels imbriqués de Business Function (BSFN)Bloc de code réutilisable effectuant une tâche spécifique, comme un calcul ou une mise à jour de table. et de Named Event Rule (NER) au sein d'une seule limite de transaction. Si votre logique personnalisée échoue durant ce processus, trouver la cause racine nécessite de cartographier la séquence exacte de l'appel NER à l'intérieur des Event Rules (ER) de l'APPL. Les développeurs perdent souvent des heures à peigner les fichiers logs alors qu'ils devraient d'abord isoler l'événement spécifique — tel que Post Button Clicked ou OK Button Clicked — où la NER personnalisée est enregistrée.

Les applications interactives transmettent des valeurs aux NER en utilisant un modèle de Data Structure (DSTR)Définition des paramètres d'entrée et de sortie utilisés pour échanger des données entre programmes. spécifique, qui dans ce scénario est une structure personnalisée multi-paramètres (D554201A) appelée par la NER personnalisée N554201A. Un point d'échec courant est une discordance entre les types de données Form Control (FC)Éléments d'interface utilisateur, tels que des champs de saisie, sur un écran JDE. ou Grid Column (GC)Colonnes de données affichées dans un tableau au sein d'une application JDE. dans l'APPL et les éléments correspondants dans le modèle de la NER. Par exemple, mapper un Form Control de type chaîne de 40 caractères à un membre de Data Structure de 30 caractères (comme SZALPH) entraîne une troncature de mémoire silencieuse ou, pire, une violation d'initialisation de mémoire qui fait planter le call object kernelProcessus serveur chargé d'exécuter les fonctions métier et de gérer la logique applicative. sur le serveur d'entreprise.

Pour éviter ces erreurs d'alignement, vérifiez toujours le mappage des paramètres dans l'outil Event Rules Design (ERD)Outil de développement visuel utilisé pour créer la logique métier dans JD Edwards. avant de générer la NER personnalisée. Si vous modifiez une Data Structure pour ajouter un paramètre supplémentaire, JDE ne met pas à jour automatiquement les mappages existants dans l'APPL ; il les laisse non mappés ou mal alignés. Réaligner ces variables manuellement dans l'éditeur ER de l'APPL et effectuer une génération locale est le seul moyen de garantir que le moteur d'exécution pousse correctement les paramètres sur la pile d'exécution.

Configurer la trace d'exécution pour une capture de log propre

Une session client web locale standard s'exécutant sur un fat clientPoste de travail complet utilisé par les développeurs pour concevoir et compiler des objets JDE. peut facilement générer des dizaines de mégaoctets de données log par minute, ce qui rend la configuration précise du jde.iniFichier de configuration principal contenant les paramètres système et de débogage de JD Edwards. local critique avant de déclencher votre application cible. Si vous laissez les paramètres par défaut grands ouverts, le système inonde le log de bavardages du middlewareLogiciel servant de pont entre différentes applications, bases de données ou systèmes d'exploitation. en arrière-plan, enterrant l'exécution spécifique de la Named Event Rule que vous devez analyser. Pour isoler le chemin d'exécution, accédez à la section [DEBUG] de votre fichier jde.ini local.

Dans cette section [DEBUG], définir Output=FILE et DebugLevel=EXT est l'exigence de base pour capturer les points d'entrée et de sortie granulaires du moteur NER. La valeur EXT garantit que le runtime JDE enregistre les paramètres exacts passés dans la structure de données de la business function, ainsi que les valeurs retournées lors de l'exécution. Sans ce niveau de détail, vous voyez seulement que la fonction a été appelée, mais vous manquez les changements d'état critiques des variables.

Pour garder le log lisible, vous devez explicitement désactiver les composants de trace inutiles qui polluent la sortie. Désactivez la trace SQLLangage standard utilisé pour interagir avec les bases de données relationnelles. en réglant LogSQL=0 dans la section [DB SYSTEM SETTINGS], et assurez-vous que la trace du security kernel est désactivée. L'élimination de ces détails de lecture de base de données réduit le volume du log d'environ deux tiers, gardant votre attention entièrement sur le flux d'exécution des Event Rules et la pile d'appels.

Une approche fiable consiste à utiliser l'utilitaire JDE AppControl ou à basculer manuellement l'état actif du log de débogage juste avant de cliquer sur le bouton spécifique ou la sortie qui déclenche l'événement de l'application. Le débogage actif ne devrait s'exécuter que pendant les 3 à 5 secondes nécessaires à l'exécution de la logique métier cible. Basculer l'état dynamique du log via l'APIInterface permettant à différents logiciels de communiquer entre eux en utilisant des règles définies. runtime ou un utilitaire local permet de maintenir votre fichier de trace sous les 5 à 10 mégaoctets, vous permettant de l'ouvrir instantanément dans n'importe quel éditeur de texte sans faire planter l'application.

Isoler l'entrée et la sortie de la NER dans jdedebug.log

Isoler une Named Event Rule personnalisée dans un fichier log volumineux, dépassant souvent plusieurs centaines de mégaoctets, nécessite un filtrage immédiat et chirurgical. Si vous recherchez la chaîne Entering JDE_NER: N554201A, vous identifierez la milliseconde exacte où le runtime passe l'exécution de l'application interactive à votre logique personnalisée de traitement des ventes. Ce point d'entrée est accompagné d'un identifiant spécifique, tel que le thread IDIdentifiant unique attribué à un processus spécifique en cours d'exécution dans le système. 4512, qui sert d'ancrage. Vous devez isoler ce thread spécifique immédiatement ; sinon, les logs entrelacés des business functions asynchrones, des UBEsMoteur de traitement par lots de JD Edwards utilisé pour générer des rapports et des traitements massifs. en arrière-plan ou des sous-programmes système s'exécutant sur des threads parallèles corrompront votre analyse du chemin d'exécution.

Une fois le thread 4512 isolé, le runtime JDE expose la profondeur de la pile d'appels à l'aide d'indicateurs de niveau imbriqués comme --> pour l'entrée et <-- pour la sortie. Chaque niveau imbriqué représente une étape plus profonde dans la hiérarchie d'exécution, par exemple lorsque N554201A appelle des business functions standard de vente comme B4200310. Compter ces indicateurs fléchés vous permet de cartographier la relation parent-enfant exacte des business functions sans deviner. Lorsque vous trouvez le marqueur Exiting JDE_NER: N554201A correspondant sur ce même thread, vous avez réussi à délimiter la fenêtre d'exécution pour cet appel spécifique.

Comparer les différences d'horodatage entre ces marqueurs d'entrée et de sortie est le moyen le plus rapide de diagnostiquer une dégradation des performances. Une seule exécution de N554201A devrait se traiter en moins de 50 à 100 millisecondes, mais si le delta entre les marqueurs d'entrée et de sortie s'étire sur plusieurs secondes, vous faites face à un goulot d'étranglement critique. Ce retard pointe généralement vers des lectures personnalisées non indexées à l'intérieur d'une boucle Select/Fetch Next ou des opérations d'E/S de table répétitives et redondantes à l'intérieur des event rules. En calculant ces deltas sur plusieurs itérations dans le log, vous pouvez prouver si un problème de performance est systémique ou lié à une charge de données spécifique.

Inspection des mappages de paramètres et des structures de données

L'état exact de votre structure de données au moment de l'exécution est mis à nu dans le jdedebug.log immédiatement après la ligne Entering JDE_NER. Le moteur affiche chaque membre de la structure de données cible, vous montrant exactement ce que l'APPL appelante a poussé sur la pile. Si vous dépannez un calcul qui échoue uniquement lorsqu'il est exécuté depuis un power form spécifique, cet affichage est l'endroit où vous isolez l'écart entre les entrées attendues et réelles.

Un coupable fréquent dans ces affichages est un paramètre MATH_NUMERICType de données interne à JDE utilisé pour stocker et manipuler des nombres avec précision. qui arrive sous forme de chaîne vide non initialisée plutôt que d'un zéro propre. Dans les business functions en C et les NER, un vide dans une structure mathématique ne devient pas par défaut un zéro ; au lieu de cela, il contourne la logique d'initialisation, provoquant l'échec silencieux des opérations mathématiques en aval ou déclenchant des violations de mémoire. Lorsque vous inspectez le log, recherchez une ligne comme IN [1] <Math Numeric> : [] qui confirme que l'application appelante n'a pas réussi à initialiser la variable avant de la passer à la structure de données.

Les paramètres de type caractère comme les drapeaux EV01Élément du dictionnaire de données JDE représentant généralement un indicateur de type Oui/Non (Y/N). nécessitent la même vigilance. Une APPL pourrait passer un 'y' minuscule au lieu d'un 'Y' majuscule, ou un champ de caractère pourrait contenir un espace de fin qui échappe aux règles de validation de base. Le log de trace expose ces valeurs littérales entre crochets, ce qui permet de repérer facilement si une instruction conditionnelle à l'intérieur de la NER échoue simplement parce qu'elle a évalué 'y' == 'Y' comme faux.

Avant de faire défiler le bloc d'appel, remontez jusqu'à la ligne Exiting JDE_NER correspondante pour vérifier les paramètres de sortie. Si la logique interne s'est exécutée avec succès, le log doit montrer les paramètres de sortie remplis avec leurs nouvelles valeurs immédiatement avant ce marqueur de sortie. Si les sorties restent vides ou inchangées malgré l'absence d'erreurs de base de données dans les logs, votre problème réside dans le routage conditionnel des event rules internes de la NER, et non dans la couche de base de données.

Suivi des codes de retour et propagation de la pile d'erreurs

Une NER communique son statut d'exécution à l'APPL appelante via un protocole de valeur de retour strict : ER_SUCCESSCode de retour indiquant que l'exécution d'une fonction ou d'une règle s'est terminée sans erreur. (0) indique une exécution propre, tandis que ER_ERRORCode de retour signalant qu'une erreur critique est survenue lors de l'exécution de la logique. (2) signale un échec critique. Lorsqu'une validation échoue à l'intérieur de la NER, le moteur n'arrête pas automatiquement les event rules de l'application appelante à moins que ce code de retour ne soit explicitement évalué par l'appelant. Dans le jdedebug.log, vous verrez cela se manifester immédiatement après la ligne Return value is du bloc d'exécution BSFN, où un 2 indique que le formulaire appelant doit interrompre sa séquence de validation (commit).

À l'intérieur du code C généré de la NER, les Event Rules natives comme "Set Action Error" se mappent directement aux API de la pile d'erreurs du moteur JDE. Lors du traçage d'un échec de validation, recherchez dans le log la ligne de suivi COB0000012 ou l'appel API jdeErrorSet, qui enregistre l'élément spécifique du Data DictionaryRéférentiel central définissant les caractéristiques de tous les champs de données utilisés dans JD Edwards. — tel que 0002 pour "Record Invalid" — directement dans la mémoire du thread. La ligne de log affichera explicitement l'élément DD cible et la table ou l'alias associé, confirmant que la business function a réussi à enregistrer l'erreur avant même que le contrôle ne revienne au runtime interactif.

Un piège courant survient lorsque l'APPL appelante supprime ou ne parvient pas à évaluer ce code de retour, entraînant un échec silencieux où l'écran se fige sans afficher le texte d'erreur rouge standard. Ce décalage se produit parce que la pile d'erreurs contient l'élément DD 0002 enregistré, mais le flux de contrôle du formulaire contourne la logique d'affichage de l'erreur en raison d'une variable de retour non mappée dans les Event Rules de l'APPL. Pour résoudre cela, vérifiez que les event rules appelantes contrôlent le pointeur de retour de la BSFN et déclenchent explicitement un Set Action Error au niveau du contrôle si la NER retourne 2.

Recompiler et déployer la NER corrigée via OWM

Lorsque vous trouvez le bug d'alignement dans votre NER personnalisée de Sales Order Entry, disons N554201A, vous ne pouvez pas simplement enregistrer et quitter le designer d'Event Rules. Les développeurs JDE oublient souvent que l'enregistrement des ER ne met à jour que les spécifications ; vous devez explicitement déclencher le processus de génération dans l'Object Management Workbench (OWM)Interface centrale de JD Edwards pour gérer le cycle de vie des objets de développement. pour traduire ces règles visuelles en fichiers sources réels n554201a.c et n554201a.h. Si vous sautez cette étape de génération, le compilateur construira l'ancien code C, ignorant complètement vos modifications visuelles des ER.

Après la génération, exécutez une compilation locale de la business function dans OWM pour compiler le nouveau code C dans le répertoire runtime de votre environnement de développement local, ce qui est critique si vous utilisez une Tools ReleaseVersion de la couche technologique sous-jacente qui supporte les applications JD Edwards. 64 bits comme 9.2.6. Pour tester ce changement localement sur votre client de développement, vous devez contourner le mécanisme de mise en cache des spécifications locales. Supprimez le fichier local spec.db situé dans votre répertoire local de path codeRépertoire contenant un ensemble spécifique de spécifications et d'objets pour un environnement donné. (généralement sous E920\DV920\spec\) et redémarrez votre client Web Dev local pour forcer EnterpriseOne à sérialiser les spécifications newly compilées.

Une fois la validation locale réussie, promouvez N554201A via OWM vers le statut de votre projet de test, généralement le statut 26 pour la QA. Vous devez exécuter une construction de package de mise à jour sélective pour votre path code cible, tel que PY920, et le déployer à la fois sur les instances Enterprise Server et HTML Server. Sauter cette étape de déploiement est la cause la plus fréquente du syndrome "ça marche sur ma machine", où le serveur d'entreprise continue d'exécuter la DLLFichier contenant du code et des données pouvant être utilisés par plusieurs programmes simultanément. ou la bibliothèque partagée obsolète mise en cache, entraînant des échecs d'exécution immédiats.

Maîtriser la pile d'appels et interpréter la sortie de jdedebug.log est essentiel lors du dépannage d'une logique NER complexe dans les Tools ReleaseVersion de la couche technologique sous-jacente qui supporte les applications JD Edwards. 9.2.8 et au-delà. En isolant systématiquement les thread IDs, en vérifiant les mappages de paramètres et en surveillant la pile d'erreurs, les développeurs peuvent résoudre les goulots d'étranglement d'intégration et garantir l'intégrité des transactions dans toute l'entreprise.