Lors de l'audit d'applications P55Préfixe utilisé dans JD Edwards pour désigner les applications et objets personnalisés développés spécifiquement pour une entreprise. personnalisées, je trouve régulièrement des formulaires Headerless DetailType de formulaire JD Edwards permettant de saisir ou modifier plusieurs lignes de données directement dans une grille sans en-tête complexe. avec des milliers de lignes d'Event Rules (ER)Langage de programmation propriétaire de JD Edwards utilisé pour ajouter de la logique métier aux applications et rapports. procédurales entassées directement dans le bouton OK. Cet anti-pattern architectural dégrade les performances d'exécution interactives sur le serveur HTML et transforme les mises à jour mineures de Tools ReleaseMise à jour technique du socle logiciel JD Edwards, incluant les outils de développement, de sécurité et d'infrastructure. en marathons de débogage de plusieurs semaines.

Pour maintenir la réactivité de vos applications interactives et garantir la sécurité des mises à jour, vous devez imposer une séparation stricte entre la validation des contrôles au niveau de l'interface utilisateur (UI) et la logique métier réutilisable. Cet exemple de JDE APPL event rules pour valider la saisie d'un formulaire avant l'enregistrement montre comment structurer la validation dans Form Design Aid (FDA)Outil de développement visuel utilisé pour créer et modifier les écrans interactifs dans JD Edwards. sans alourdir la couche de présentation. En déléguant les vérifications complexes de la base de données à des Named Event Rules (NER)Fonctions métier créées avec le langage Event Rules, mais compilées en langage C pour être réutilisables et performantes. ou à des Business Functions (BSFNs)Modules de code réutilisables, écrits en C ou en NER, qui exécutent des calculs ou des validations complexes. en C, vous empêchez les données erronées d'atteindre des tables comme F4101Table de base de données JD Edwards contenant les informations de base sur les articles (Item Master). ou F0911Table centrale de la comptabilité JD Edwards contenant le détail des écritures du Grand Livre. tout en préservant une empreinte ER propre et maintenable.

L'architecture de la validation de formulaire JDE

Placer la logique de validation dans le mauvais événement est le moyen le plus rapide de saturer la mémoire d'exécution interactive et de bloquer les sessions utilisateur. Dans JDE Form Design Aid, vous devez strictement séparer la validation de l'interface utilisateur de la validation des transactions de la base de données. La validation au niveau de l'UI gère les vérifications immédiates et légères, telles que l'identification des champs de saisie vides, la vérification du formatage des dates et le déplacement programmatique du focus entre les contrôles du formulaire. Ces opérations s'exécutent entièrement dans la couche de présentation et ne devraient jamais déclencher d'allers-retours avec la base de données.

Lorsque la validation nécessite de vérifier l'intégrité relationnelle ou de contrôler des règles métier par rapport à des tables comme F0101Table du répertoire d'adresses (Address Book) contenant les informations sur les entités comme les clients ou fournisseurs. Address Book ou F41021Table JD Edwards gérant la disponibilité des stocks par article, magasin et emplacement. Item Location, les règles architecturales changent complètement. Par exemple, valider la disponibilité des stocks dans la F41021 nécessite de calculer les quantités sur plusieurs compartiments comme la Quantity on Hand (PQOH) et la Quantity Hard Committed (QWOC) tout en évaluant les règles d'engagement. Tenter d'écrire ces vérifications relationnelles complexes directement dans les APPL event rules est un anti-pattern de conception. Cette validation de niveau métier appartient à une business function C dédiée s'exécutant sur le serveur d'entreprise.

L'intégration de requêtes de base de données lourdes ou d'instructions Table I/O directement dans les event rules interactives dégrade les performances du serveur d'applications Java, prolongeant les temps de réponse des écrans de quelques dizaines de millisecondes à plusieurs secondes. Cela crée également un cauchemar de maintenance car ces mêmes règles de validation doivent être dupliquées lorsque les données sont importées via EDIÉchange de données informatisé permettant le transfert automatique de documents commerciaux entre systèmes informatiques. ou un UBEUniversal Batch Engine, l'outil de JD Edwards pour exécuter des rapports et des traitements de données en arrière-plan. batch. L'acheminement de la validation métier vers une Business Function ou une Named Event Rule réutilisable garantit qu'un bloc de code unique et centralisé gère la logique, que la transaction provienne d'une saisie manuelle dans P4210 ou d'une charge utile RESTStyle d'architecture logicielle utilisé pour créer des services web légers et interopérables sur Internet. entrante via le serveur AISApplication Interface Services, un serveur permettant d'exposer la logique JD Edwards via des services web REST..

Configuration du Form Interconnect et des variables d'entrée

Les variables Form Interconnect (FI)Variables utilisées pour transférer des données entre deux formulaires JD Edwards lors d'un appel. définissent le contrat d'interface strict entre une application appelante — telle qu'une saisie de commande client personnalisée P554210 — et le formulaire de validation cible, W554210A. Lors du passage de valeurs telles que le numéro Sold To (AN8) ou le type de commande (DCTO), traiter ces paramètres comme un contrat immuable empêche la corruption des données à travers la hiérarchie des tables. Si l'application appelante transmet une valeur invalide ou vide, le formulaire cible doit gérer cette condition limite immédiatement avant d'exécuter toute logique métier.

Dans l'événement Dialog Is Initialized de W554210A, vous devez mapper ces variables FI entrantes directement sur leurs variables Form Control (FC)Éléments visuels d'un formulaire, tels que les champs de saisie, les cases à cocher ou les listes déroulantes. correspondantes. Une omission courante dans le développement personnalisé est de supposer que ces paramètres contiendront toujours des données valides. Si une variable FI nulle ou non mappée passe à travers ce chargement initial, elle déclenche une cascade d'erreurs d'exécution lorsque le formulaire tente de récupérer des enregistrements de la table Sales Order Header (F4201). Vous devriez implémenter une vérification de validation explicite dans cet événement : si la variable FI mnOrderNumber entrante est vide ou égale à zéro, levez une erreur à l'aide de la fonction système Set Action Code et terminez immédiatement l'exécution du formulaire.

Pour améliorer l'expérience utilisateur et vérifier que le bon contexte a été établi, utilisez la fonction système Set Form Title au cours de cette même phase d'initialisation. La concaténation des variables FI szOrderType et FI mnOrderNumber transmises dans une seule chaîne vous permet de mettre à jour dynamiquement l'en-tête du formulaire pour afficher quelque chose de précis, tel que "Valider la commande : SO 10245". Cette étape simple fournit une confirmation visuelle immédiate à l'utilisateur et aide les développeurs lors des sessions de débogage interactives dans le client HTML, réduisant le temps de dépannage lors des tests d'intégration de 10 % à 20 %.

L'événement OK Button Clicked : là où la validation commence

Dans l'ordre d'exécution standard du runtime JDE pour les applications interactives (APPL), l'événement 'OK - Button Clicked' représente la toute dernière ligne de défense avant que le moteur d'exécution ne valide les données dans la base de données. De nombreux développeurs croient à tort que la validation peut se produire en toute sécurité dans 'Post Button Clicked' ou lors de l'événement 'Add Record to DB - Before', mais à ce stade, le moteur assemble déjà les instructions SQL d'insertion ou de mise à jour. Si votre code n'intercepte pas la transaction pendant la phase 'Button Clicked', vous risquez de corrompre des tables comme F4101 ou F0911 avec des données incomplètes ou invalides.

Une fois l'exécution de l'événement 'OK - Button Clicked' terminée, le runtime standard passe automatiquement à 'Post Button Clicked' et exécute les mises à jour des tables sous-jacentes. Le moteur suppose un état de validation réussi à moins qu'une erreur critique ne soit enregistrée. J'ai vu des applications personnalisées où les développeurs s'appuyaient uniquement sur la fonction système Set Action Code pour manipuler le flux de transaction, s'attendant à ce qu'elle bloque l'enregistrement. Ce n'est pas le cas ; le moteur d'exécution ignore les surcharges de code d'action si l'indicateur d'erreur interne reste vierge, ce qui conduit à des enregistrements fantômes qui contournent les règles métier.

Pour interrompre de manière fiable le cycle de validation (commitAction finale consistant à enregistrer de manière permanente les modifications de données dans la base de données.), vous devez émettre une fonction système 'Set Control Error' contre un contrôle de formulaire spécifique. Lorsque le moteur d'exécution rencontre une erreur au niveau du contrôle pendant 'OK - Button Clicked', il arrête immédiatement l'ordre d'exécution, abandonne la validation en base de données et met en évidence le champ invalide en rouge sur l'écran de l'utilisateur. Par exemple, si vous validez un champ branch/plant par rapport à la F0006 et qu'il s'avère invalide, l'appel à 'Set Control Error(FC BranchPlant, "123A")' arrête instantanément la transaction. Ce comportement natif garantit qu'aucune opération d'E/S en base de données ne se produit tant que l'utilisateur n'a pas corrigé la saisie, préservant l'intégrité référentielle sans nécessiter de logique de rollbackOpération consistant à annuler une transaction en cours et à restaurer les données dans leur état initial. personnalisée complexe.

Écrire les Event Rules : exemple de code étape par étape

Dans la grande majorité des applications interactives personnalisées que j'audite, les développeurs oublient d'effacer les états d'erreur précédents au tout début de l'événement de validation. Si vous n'appelez pas explicitement la fonction système Clear Control Error pour vos contrôles de formulaire avant d'exécuter vos vérifications de validation, le moteur d'exécution conserve les blocages d'interface obsolètes de l'exécution précédente. Cela se traduit par des utilisateurs qui corrigent un champ, cliquent sur OK, et voient le formulaire rester verrouillé avec une erreur fantôme. Un bloc de validation propre doit toujours commencer par purger la pile d'erreurs pour chaque contrôle évalué, tel que FC Short Item No et FC Branch/Plant.

Une fois le terrain dégagé, les event rules doivent évaluer les règles conditionnelles de manière séquentielle pour vérifier la logique métier. Par exemple, si vous validez un formulaire de transfert de stock personnalisé, vous vérifiez d'abord que l'article existe dans l'Item Master (F4101) à l'aide d'un fetch standard, puis vous vérifiez si le branch/plant est valide dans le Business Unit Master (F0006). Cette approche séquentielle vous permet de comparer les contrôles de formulaire directement par rapport aux variables locales alimentées par ces recherches en base de données, garantissant que vous n'exécutez pas de requêtes lourdes si les validations de base au niveau du champ ont déjà échoué.

Lorsqu'une règle de validation échoue, vous devez déclencher immédiatement la fonction système Set Control Error, en la mappant à un code d'erreur valide du Data DictionaryRéférentiel centralisé qui définit les propriétés, les libellés et les règles de validation de tous les champs du système.. Par exemple, si la recherche du numéro d'article court échoue, appelez Set Control Error(FC Short Item No, '0002') pour mettre en évidence le champ spécifique en rouge et afficher le message "Record Invalid" à l'utilisateur. Immédiatement après cet appel, vous devez exécuter la fonction système Stop Processing. Cela empêche l'exécution des lignes de validation suivantes et des insertions en base de données, économisant des cycles CPU sur le serveur d'entreprise et empêchant le moteur d'exécution d'évaluer la logique en aval sur une transaction déjà compromise.

Déléguer la validation complexe à une logique NER ou BSFN réutilisable

L'intégration de jointures multi-tables sur des tables comme F0101 et F0006 directement à l'intérieur de l'événement OK Button Clicked d'une APPL est un anti-pattern courant qui alourdit le runtime interactif. Au lieu de cela, encapsulez cette logique complexe — y compris les vérifications de sécurité des business units — à l'intérieur d'une Named Event Rule dédiée comme N5542010 (ValidateOrderHeader). Cela déplace la charge de traitement hors de la couche de présentation et isole les opérations de base de données là où elles doivent être.

Vos APPL event rules doivent agir comme un simple agent de circulation, transmettant les valeurs de Form Control pertinentes — telles que MCU, AN8 et DCTO — directement dans la structure de données N5542010. Une fois que la business function s'exécute, l'APPL n'a plus qu'à évaluer un seul indicateur d'erreur renvoyé, tel que cErrorFlag (EV01), et déclencher conditionnellement Set Action Code(HC_FRM_ERR) ou affecter des erreurs à des contrôles spécifiques à l'aide de Set Control Error. Cette délégation maintient le code de l'application interactive sous la barre des cent lignes d'ER lisibles, faisant des futures adaptations lors d'une mise à jour vers Tools Release 9.2.8 une question de minutes plutôt qu'un exercice de débogage de plusieurs jours.

Le découplage de votre logique de validation de l'interface utilisateur du formulaire prépare votre architecture pour les points de contact d'intégration modernes. En exposant N5542010 en tant qu'appel REST AIS ou en l'appelant directement depuis une Orchestration EnterpriseOne, vous garantissez que les commandes e-commerce tierces ou les fichiers plats EDI entrants traités via l'UBE R47011 subissent exactement les mêmes règles de validation que les saisies manuelles dans P42101. Si vos règles de vérification de crédit ou d'autorisation de branch/plant changent demain, vous modifiez le code dans un seul objet, N5542010, plutôt que de traquer la logique de validation dans quatre applications et rapports personnalisés différents. Cette architecture réduit les cycles de tests de régression de 30 % à 50 % lors des mises à jour en livraison continue.

Tester et déboguer le flux de validation

Pour confirmer que votre logique de validation tient la route, évitez la tentation de vous fier uniquement aux fenêtres contextuelles d'erreur du runtime. Lancez le débogueur interactif JDE (ActiveEra) et définissez un point d'arrêt directement sur la première ligne de l'événement 'OK - Button Clicked'. Au fur et à mesure que vous parcourez les Event Rules, inspectez la variable système SV CO_ErrorStatus aux côtés de vos variables Form pour vérifier que l'indicateur d'erreur est défini sur CO_ERROR à la milliseconde où une condition invalide est rencontrée. Cette étape manuelle empêche l'erreur courante de laisser l'exécution se poursuivre jusqu'aux mises à jour des tables alors qu'un échec de validation aurait dû arrêter le moteur.

Une fois l'exécution visuelle vérifiée, validez la couche de base de données en analysant le fichier jdedebug.log. Dans un environnement 9.2 standard avec le traitement des transactions activé, un échec de validation à l'intérieur d'une business function doit déclencher un rollbackOpération consistant à annuler une transaction en cours et à restaurer les données dans leur état initial. explicite. Inspectez le journal pour l'instruction ROLLBACK et confirmez qu'aucune commande SQL INSERT ou UPDATE n'a été exécutée contre les tables cibles comme F4211 ou F0911 après que l'erreur de validation a été définie. Si vous repérez un INSERT orphelin suivi d'un échec de commit, vos limites de transaction sont mal configurées, ce qui risque de corrompre la base de données.

Finalisez vos tests en soumettant le formulaire à des conditions limites extrêmes. Exécutez des cas de test avec des entrées nulles dans les champs obligatoires, des clés étrangères invalides qui échouent à la validation F0101, et un chemin d'enregistrement propre et réussi. Pour chacun de ces 3 scénarios, vérifiez que le moteur d'exécution efface proprement la file d'attente des erreurs lors de la prochaine action sur un contrôle, empêchant les erreurs "collantes". Si une business function comme ValidateF0101AddressBook renvoie un avertissement au lieu d'une erreur critique, assurez-vous que vos Event Rules interceptent explicitement cela pour empêcher la validation de données partielles.

Si vous allez au-delà de la simple validation de formulaire vers une logique plus complexe dans P4210 ou P4310, consultez nos autres articles techniques sur la gestion des erreurs BSFN et les configurations d'erreurs définies par l'utilisateur pour garantir que vos applications d'entreprise restent performantes et sûres pour les mises à jour.