Dans une personnalisation standard de commande client P4210Application standard de saisie des commandes clients dans JD Edwards. comportant des dizaines de lignes de grille, une boucle naïve « Get Max Grid Rows » lors de la validation peut facilement ajouter près d'une seconde de latence à l'interface utilisateur par transaction. Les développeurs supposent souvent que le runtime EnterpriseOneLa suite logicielle ERP complète développée par Oracle. optimise ces boucles en arrière-plan, mais il évalue en réalité chaque cellule de manière séquentielle, ce qui dégrade les performances interactives sur les serveurs HTML. Cet exemple de développement APPLTerme technique désignant une application interactive au sein de JD Edwards. JD Edwards sur la validation des lignes de grille montre comment cibler uniquement les lignes modifiées, réduisant ainsi la charge de validation de plus de 80 %.

En utilisant des Grid Event Rules (GER)Logique de programmation déclenchée par des actions spécifiques dans une grille de données. spécifiques comme Row is Exit and Changed - Asynch ou en suivant l'état des modifications avec des colonnes de grille masquées, vous pouvez ignorer entièrement les enregistrements non modifiés. Si vos utilisateurs traitent des commandes de plus de cent lignes, ce passage d'un balayage aveugle à une validation ciblée évite les blocages au niveau du navigateur qui déclenchent des délais d'attente inutiles du client Web. Voici comment implémenter ce modèle proprement dans Form Design Aid (FDA)Outil de développement utilisé pour créer et modifier les interfaces utilisateur dans JD Edwards. sans alourdir vos règles d'événements.

Le coût des boucles aveugles dans la validation de grille

Observez un utilisateur tentant de mettre à jour une seule ligne dans une grille de saisie de commandes clients personnalisée de plusieurs centaines de lignes : vous verrez souvent l'écran se figer pendant plusieurs secondes. Cette latence est presque toujours causée par un développeur écrivant une boucle Get Max Grid Rows à l'intérieur d'un événement de validation de ligne. Au lieu d'isoler la seule ligne modifiée, les règles d'événements parcourent chaque ligne du tampon de la grille de haut en bas. Ce modèle transforme une simple mise à jour de l'interface en un goulot d'étranglement massif des performances.

Cet anti-pattern se produit parce que les développeurs traitent souvent le composant de grille actif comme une table de base de données plate plutôt que comme un tampon d'exécution en mémoire. Lorsqu'un utilisateur modifie une cellule sur une ligne vers la fin de la grille, une boucle aveugle force le serveur HTML à effectuer des centaines de recherches en mémoire interne juste pour valider ce changement unique. Si l'utilisateur modifie plusieurs lignes séquentiellement, le système exécute des milliers d'itérations. Cette complexité algorithmique O(N²)Mesure indiquant que le temps d'exécution augmente de façon exponentielle avec le nombre de lignes. paralyse la couche de présentation, transformant ce qui devrait être une réponse d'écran inférieure à la seconde en une attente frustrante.

Les dommages s'étendent bien au-delà de la vitesse de rendu du client Web. Si ces centaines de lignes itérées déclenchent des recherches redondantes dans la base de données via F4101Table de base de données contenant les informations de base sur les articles (Item Master). ou exécutent des fonctions métier comme VerifyAndInheritGLClass (B4000350) pour des lignes inchangées, le serveur d'entreprise en souffre immédiatement. Ce traitement inutile sature rapidement les call object kernels (COKs)Processus serveur responsables de l'exécution de la logique métier (Business Functions). de votre serveur d'entreprise. Sous une lourde charge d'utilisateurs simultanés, quelques-unes de ces boucles non optimisées peuvent facilement saturer les ressources IPCMécanismes permettant à différents processus du serveur de communiquer entre eux. du système et faire grimper l'utilisation du processeur à sa capacité maximale.

Pour éviter cela, les développeurs doivent passer des boucles de grille passives à l'isolement des lignes piloté par les événements. Au cours de mes deux décennies de dépannage d'applications interactives personnalisées, j'ai constaté que le simple fait de refactoriser ces boucles aveugles pour cibler les valeurs GC (Grid Column) de la ligne actuellement active réduit le chemin d'exécution de la logique de validation de plus de 95 %.

Utilisation des Grid Event Rules pour la détection des lignes modifiées

Placer une validation multi-champs à l'intérieur de l'événement « Col Exited & Changed » est un défaut de conception courant qui dégrade les performances interactives de l'APPL. Si une ligne de grille possède plusieurs colonnes modifiables et qu'un utilisateur passe de l'une à l'autre avec la touche tabulation, une validation dépendante de plusieurs champs se déclenche de manière répétée et prématurée. L'événement Row Exit & Out constitue le point d'ancrage optimal pour la validation au niveau de la ligne, car le moteur d'exécution FDA le déclenche exactement une fois lorsque l'utilisateur quitte une ligne modifiée, ou « dirty ». Cela réduit les cycles d'exécution BSFNBusiness Function : un programme réutilisable contenant de la logique métier complexe. inutiles de plus de moitié par rapport aux événements au niveau de la colonne lors d'une saisie rapide de données.

Les développeurs confondent fréquemment les valeurs GB (Grid Buffer) avec les données d'exécution actives lors des routines de validation. Dans le contexte Row Exit & Out, les valeurs GB représentent l'état de l'enregistrement avant la modification actuelle ou sont principalement utilisées lors des opérations de copier-coller dans la grille. Pour évaluer l'état d'exécution précis saisi par l'utilisateur, vous devez mapper les paramètres de votre BSFN de validation directement aux variables GC (Grid Column). Cela empêche les anciennes valeurs de la base de données ou les structures de tampon incomplètes de corrompre votre logique de validation, en particulier dans des applications complexes comme Sales Order Entry (P4210) ou Voucher Entry (P0411).

Pour isoler l'exécution à l'enregistrement actif, référencez la variable système 'SV Line-Number' au lieu d'exécuter une boucle manuelle Get Max Grid Rows. L'utilisation de 'SV Line-Number' permet au moteur d'exécution de cibler l'index exact de la ligne en cours de validation, exécutant la validation ligne par ligne. Je recommande d'écrire une vérification conditionnelle rapide à l'aide de cette variable système pour vérifier que l'index de la ligne est supérieur à zéro avant d'appeler des BSFN de validation personnalisés. Ce simple contrôle élimine le risque d'exécuter une logique de validation sur des en-têtes de grille vides ou des lignes fantômes, économisant ainsi de précieuses millisecondes par transaction.

Implémentation étape par étape de la validation des lignes de grille

Le déclenchement de la logique de validation sur le mauvais événement de grille est l'un des principaux facteurs de dégradation des performances dans les applications interactives complexes comme P4210 ou P4312. Les développeurs insèrent fréquemment des routines de validation dans « Col Exited and Changed », provoquant des récupérations de base de données redondantes chaque fois qu'un utilisateur parcourt une ligne. Limitez cette exécution aux événements Row Exit & Out ou Row Is Validated. Pour rendre cela infaillible, définissez une colonne de grille masquée (généralement un champ de caractère comme EV01) pour servir d'indicateur de modification (dirty flag). Définissez cet indicateur sur '1' uniquement lorsqu'une cellule change réellement, permettant à l'événement de validation de ligne de contourner le traitement en base de données si la ligne n'a pas été touchée.

Lorsque la validation échoue, l'affichage d'une erreur générique au niveau du formulaire via Set Action Code Error frustre les utilisateurs car elle ne fournit aucun contexte visuel sur une grille contenant des dizaines de lignes. Utilisez la fonction système Set Grid Cell Error pour cibler précisément la colonne et l'index de ligne causant l'échec. Si un champ de quantité échoue à un contrôle de stock de sécurité par rapport à la table F41021Table de base de données gérant la disponibilité des stocks par emplacement., mappez l'erreur directement à la colonne GC Quantity. Cela met en évidence la cellule incriminée en rouge, permettant à l'utilisateur de se concentrer sur le point exact de l'échec.

L'oubli de supprimer ces erreurs est une erreur courante qui entraîne des blocages persistants de la grille, forçant les utilisateurs à annuler entièrement la transaction. Chaque branche de validation doit avoir un mécanisme de suppression correspondant. Exécutez la fonction système Clear Grid Cell Error sur la colonne cible immédiatement avant de réévaluer la logique de validation. Si la valeur corrigée passe maintenant le contrôle de la base de données, l'état d'erreur rouge est effacé, l'indicateur de modification est remis à '0' et le moteur d'exécution permet à la transaction d'être validée en toute sécurité.

Exemple de code : Validation efficace des lignes modifiées

Écrire des Event Rules qui se déclenchent sur chaque ligne de grille, que les données aient changé ou non, est un tueur de performance classique dans les applications à gros volume comme P4210 ou P4312. Pour isoler la ligne active sans boucle complète, nous plaçons notre logique de validation dans l'événement Row Exit & Changed - Asynchronous. En utilisant la comparaison GC (Grid Column) et SV (System Variable), nous garantissons que l'exécution ne se produit que lorsque l'utilisateur modifie la quantité de la transaction. Cet événement s'exécute naturellement dans le contexte de la ligne active, ce qui signifie que nous contournons complètement la surcharge d'une structure de boucle Get Max Grid Rows et Get Grid Row.

Le cœur de cette optimisation est l'exécution conditionnelle de la fonction métier F41021 Inventory Availability. Nous comparons la valeur actuelle de la grille de GC QuantityOrdered (UORG) à son état d'origine. Si elles sont identiques, les règles d'événements s'arrêtent immédiatement. Si elles diffèrent, le runtime appelle la BSFN d'inventaire pour valider la quantité demandée par rapport à la table F41021, évitant ainsi des E/S de base de données et des recherches de cache inutiles pour la grande majorité des lignes que l'utilisateur n'a pas touchées.

La logique ER mappe dynamiquement l'index de la ligne actuelle à l'aide de fonctions système pour définir les erreurs directement sur la cellule concernée :

// Event: Row Exit & Changed - Asynchronous
If GC QuantityOrdered (UORG) is not equal to SV Selected_Grid_Row_Number
   // Call F41021 Inventory Availability BSFN
   F41021 Inventory Availability (B4101370)
      GC QuantityOrdered -> mnQtyRequested
      GC ItemNumber -> szItemNumber
      GC BranchPlant -> szBranchPlant
      VA evt_cErrorCode <- cErrorCode
   If VA evt_cErrorCode is equal to "1"
      Set Grid Cell Error(FC Grid, <Current Row>, GC QuantityOrdered, "0037")
   End If
End If

L'utilisation du paramètre <Current Row> dans la fonction système Set Grid Cell Error garantit que l'indicateur d'erreur met en évidence la cellule exacte sur la ligne active sans nécessiter de pointeur manuel ou de boucle d'index, maintenant le temps de réponse interactif sous les 100 millisecondes.

Gestion des erreurs de validation sans blocage de la grille

Un mode de défaillance courant dans les personnalisations P4210 ou P4312 est le redoutable blocage de la grille, où un utilisateur est piégé dans une boucle infinie de messages de validation. Comprendre la Hiérarchie des erreurs au niveau formulaire vs niveau grille est ici crucial. Lorsque vous déclenchez une erreur au niveau de la grille à l'aide de la fonction système Set Grid Cell Error, EnterpriseOne interrompt en toute sécurité le processus de validation de la transaction au niveau de la base de données sans geler la session HTML interactive. Cela permet au moteur d'exécution de bloquer le bouton OK après les événements de clic tout en maintenant le contrôle de la grille actif pour les corrections de l'utilisateur.

Si vos Event Rules ne parviennent pas à effacer ces erreurs par programmation lorsque l'utilisateur corrige les données, le runtime FDA s'y perd. Dans une grille typique de plusieurs dizaines de lignes, une erreur non effacée sur une ligne précédente déclenchera de manière répétée la validation lors des évaluations de lignes suivantes, forçant l'utilisateur à fermer la session du navigateur. Pour éviter cela, vos Event Rules doivent explicitement appeler Clear Grid Cell Error, mappé précisément à la colonne cible et à la variable spécifique SV Grid_Row_Number.

Vous devez également faire la distinction entre les erreurs bloquantes (hard errors) qui empêchent l'écriture en base de données et les avertissements (soft warnings) qui signalent simplement une anomalie. Set Grid Cell Error est par défaut une erreur bloquante (type 1). Pour les avertissements (type 2), utilisez la fonction système Set Grid Cell Warning, qui alerte visuellement l'utilisateur avec un surlignage jaune mais lui permet d'ignorer l'avertissement lors d'un second clic sur le bouton OK. L'implémentation de cette distinction réduit les tickets de support de 10 % à 15 % sur les écrans de saisie de données à haut volume.

Analyse comparative des performances : Balayages aveugles vs Contrôles ciblés

La surveillance de l'utilisation du processeur par les call object kernels pendant les heures de pointe de saisie des commandes révèle le coût architectural immédiat d'une validation inefficace. Lorsque les développeurs écrivent des boucles aveugles qui parcourent chaque ligne de la grille lors d'un clic standard sur le bouton OK, ils inondent le serveur d'entreprise de requêtes de base de données redondantes. Le passage à une validation de ligne ciblée — n'exécutant la logique que sur les lignes où la valeur de la colonne de grille a réellement changé — réduit les allers-retours vers la base de données de plus de 80 %. Cela stabilise directement le serveur HTML EnterpriseOne pendant les périodes de forte simultanéité.

Dans les écrans transactionnels à haut volume comme la saisie F4211 ou F4311, les grilles s'étendent fréquemment sur des dizaines de lignes. Le contournement des appels de validation BSFN inutiles pour les lignes non modifiées empêche la JVMMachine Virtuelle Java, l'environnement qui exécute les applications web de JD Edwards. de vos instances WebSphereServeur d'applications d'IBM utilisé pour héberger l'interface web de JD Edwards. ou WebLogic de gonfler. Chaque appel redondant sérialise les structures de données sur le réseau, consommant de la mémoire tas (heap memory)Zone de mémoire utilisée par la JVM pour stocker les objets et les données de session. qui devrait être réservée aux sessions utilisateur actives.

Pour éviter ces accès inutiles à la base de données, les développeurs doivent mettre en cache les résultats de validation dans une structure de cache JDE temporaire ou utiliser les indicateurs d'état internes de la grille. L'utilisation des fonctions système permet au runtime de localiser les lignes modifiées sans parcourir l'ensemble du jeu de données de la grille. Cela garantit que même si un utilisateur clique plusieurs fois sur OK, l'application évite de réinterroger les tables maîtresses comme la F4101 ou la F03012.

Nos tests en laboratoire montrent la réalité frappante de cette optimisation. Une grille large standard prend moins de 100 millisecondes à valider lorsqu'elle utilise des contrôles ciblés. En revanche, l'exécution d'une boucle aveugle qui applique la logique de validation sur chaque ligne — quel que soit son état de modification — prolonge le temps de validation à plusieurs secondes. Pour un opérateur saisissant des centaines de commandes par jour, ce délai de plusieurs secondes fait toute la différence entre un système fluide et un système poussif.

L'optimisation de la logique de validation des lignes de grille est une condition préalable au maintien de temps de réponse inférieurs à la seconde dans les APPL à haut volume, en particulier lors de l'utilisation de BSFN complexes basées sur le cache. En passant de boucles aveugles à une validation ciblée et pilotée par les événements, les équipes informatiques peuvent protéger les ressources du serveur et offrir une expérience utilisateur fluide.

Si vous cherchez à optimiser vos environnements JD Edwards et à éliminer les goulots d'étranglement de performance, contactez notre équipe de conseil pour une revue complète de votre code et de votre architecture.