Une grille EnterpriseOne standard traitant seulement 500 lignes peut exécuter silencieusement des milliers de lectures en base de données si vous placez des Table I/O non mis en cache ou des fonctions métier lourdes dans les événements Grid Record Is FetchedÉvénement JDE déclenché automatiquement pour chaque ligne de données chargée dans une grille. ou Write Grid Line-BeforeÉvénement déclenché juste avant l'affichage ou l'écriture d'une ligne dans la grille.. Ce modèle d'exécution synchrone crée un problème de performance JDE APPLApplication interactive JD Edwards permettant aux utilisateurs de consulter ou modifier des données. majeur avec des lectures répétées dans les boucles de grille, où le thread JVMProcessus de la machine virtuelle Java gérant l'exécution et la mémoire d'une session utilisateur. interactif se bloque en attendant des allers-retours séquentiels vers la base de données. Lorsqu'une seule action utilisateur prend plusieurs secondes au lieu d'une fraction de seconde, le coupable est presque toujours ce traitement synchrone répétitif, ligne par ligne.

Pour corriger cela, les développeurs doivent cesser de traiter la grille comme un curseur de base de données et commencer à utiliser efficacement les structures de mémoire. Avant de refactoriser, analysez la cardinalité de la table cible ; si vous interrogez de manière répétée des données de paramétrage statiques comme les conditions de paiement (F0014) ou les constantes de succursale (F41001), ces données ont leur place dans un cache JDE ou une Named Event RuleComposant de logique métier réutilisable créé avec l'outil de développement JD Edwards. (NER) résidente en mémoire. En déplaçant cette logique vers une Business FunctionBloc de code (en C ou NER) exécutant des opérations logiques spécifiques sur le serveur. (BSFN) en C utilisant l'API JDE CacheInterface de programmation permettant de stocker des données temporaires en mémoire pour un accès ultra-rapide., vous réduisez la charge de la base de données de manière significative, dépassant souvent 80 %, et restaurez des temps de réponse inférieurs à la seconde.

L'anatomie d'un goulot d'étranglement en boucle de grille

Dans les applications JDE personnalisées, les développeurs ont souvent le réflexe de placer un F4101 Fetch SingleOpération de base de données recherchant un enregistrement unique dans la table des articles. à l'intérieur de l'événement Grid Record is Fetched pour récupérer les descriptions d'articles ou les codes de catégorie à la volée. Ce choix introduit une pénalité de performance sévère car les événements Grid Record is Fetched et Write Grid Line-After s'exécutent séquentiellement pour chaque ligne chargée dans le contrôle de grille. Si un utilisateur interroge un formulaire de recherche et sélection qui extrait 200 enregistrements, le serveur HTML doit attendre que le serveur d'entreprise et la base de données terminent ces 200 allers-retours synchrones avant de rendre la page.

La dégradation des performances s'accentue de manière exponentielle lorsque plusieurs recherches de tables sont empilées dans ces événements de boucle. Une grille personnalisée typique affichant 200 enregistrements avec trois recherches de tables indépendantes dans la boucle — comme l'extraction de F4101, F4102 et F0006 — entraîne l'exécution séquentielle de 600 instructions SQL distinctes. Comme chaque instruction nécessite son propre aller-retour via le middlewareCouche logicielle assurant la communication et le transfert de données entre le serveur et la base de données., même une réponse de base de données à faible latence de 2 millisecondes par requête fait grimper le temps de chargement de la grille à plus d'une seconde de temps d'attente pur en base de données, hors surcharge réseau.

Sous le capot, le moteur d'exécution de l'ensemble d'outils JDE traite chaque instruction Event RulesScripting propriétaire de JD Edwards utilisé pour programmer la logique métier des applications. (ER) comme une instruction isolée. Contrairement aux frameworks d'application modernes qui utilisent l'Object-Relational MappingTechnique permettant de manipuler les données d'une base de données comme s'il s'agissait d'objets en programmation. (ORM) pour regrouper les requêtes, le moteur JDE ne peut pas optimiser ces instructions ER individuelles en une seule opération de base de données basée sur des ensembles. Cette limitation architecturale signifie que le placement de boucles Select et Fetch Next à l'intérieur des événements de grille force le système dans un modèle d'exécution ligne par ligne bavard qui contourne la capacité de la base de données à optimiser les plans d'exécution basés sur des ensembles.

Mesurer le timing et la surcharge de la base de données

Une seule extraction de base de données sur un réseau local prend généralement entre 2 et 5 millisecondes. Isolé, un développeur testant un seul enregistrement sur un client de développement local ne remarquera jamais ce délai. Cependant, lorsque cette extraction unique est intégrée dans un événement Grid Record Is Fetched ou Write Grid Line-Before et multipliée sur une boucle de grille de 500 lignes, le calcul change radicalement. Quelques millisecondes de latence par extraction, apparemment mineures, se transforment instantanément en plus d'une seconde de temps d'attente pur en base de données pour une seule action utilisateur, bloquant le thread interactif pendant que le serveur HTML attend le serveur d'entreprise.

Pour diagnostiquer ce goulot d'étranglement spécifique, vous devez contourner les journaux standard du kernel CallObjectProcessus serveur JD Edwards dédié à l'exécution des fonctions métier et de la logique complexe. et isoler le jdedebug.logFichier journal détaillé enregistrant toutes les opérations techniques et requêtes SQL d'une session. pour la session HTML spécifique. La recherche dans ce journal des instructions JDB_FetchKeyedFonction interne de JD Edwards utilisée pour rechercher un enregistrement spécifique dans la base de données. sous l'ID de thread de l'exécution de votre application révèle la répartition exacte du timing des instructions SELECT sous-jacentes. Vous observerez fréquemment la même instruction SQL s'exécuter des centaines de fois avec des paramètres de clause WHERE identiques — comme l'extraction de la même description de code de catégorie de la table F0005 User Defined CodesTables de codes personnalisables permettant de définir des listes de valeurs valides pour un champ. ou des détails de l'article maître de la F4101 pour chaque ligne de détail.

La comparaison des horodatages 'Time Start' et 'Time End' de ces appels JDB_FetchKeyed séquentiels expose le retard cumulatif de l'exécution synchrone des Event Rules. Étant donné qu'EnterpriseOne exécute les règles d'événement de grille de manière synchrone, le navigateur de l'utilisateur reste verrouillé dans un état de traitement jusqu'à ce que la dernière itération soit terminée. Si votre journal montre 500 itérations d'une extraction F4101 prenant quelques millisecondes chacune, l'écart de plusieurs secondes entre le premier 'Time Start' et le dernier 'Time End' représente un temps mort qu'aucun réglage de serveur Web ou allocation de mémoire JVM ne peut résoudre.

Identifier le candidat idéal pour le cache

Dans une APPL de distribution standard comme P4210 ou P4111, l'événement Grid Record Fetched déclenche souvent une recherche redondante dans la table F41001 (Inventory Constants) pour chaque ligne. Les tables statiques ou à évolution lente comme F0005 (UDC) ou F41001 sont des candidats de choix pour la mise en cache au niveau de l'application car leurs données restent constantes tout au long de la session de l'application. Interroger la base de données 500 fois pour la même constante de succursale pendant le chargement d'une grille est un gaspillage de ressources.

Si le même enregistrement est extrait plus de trois fois au cours d'une seule exécution de grille, il doit être marqué comme candidat au cache pour éviter les E/S redondantes. Par exemple, dans une grille de 200 lignes où 150 lignes appartiennent aux trois mêmes succursales, une extraction standard exécute 200 instructions SQL. En identifiant ces modèles de recherche répétitifs lors de la phase de conception, vous éliminez la surcharge des allers-retours répétés vers la base de données.

L'utilisation du JDE Cache permet aux développeurs de charger les données de référence une seule fois dans la mémoire de l'espace utilisateur lors de l'événement Post Dialog Is InitializedÉvénement déclenché immédiatement après le chargement complet d'un écran et de ses données.. Au lieu de solliciter la base de données à chaque ligne de la grille, une fonction métier C personnalisée peut pré-remplir une structure de mémoire avec les enregistrements F41001 nécessaires. La boucle de grille interroge ensuite cette structure de mémoire au lieu d'exécuter une instruction SQL SELECT.

Le stockage de paires clé-valeur en mémoire réduit le temps de récupération suivant de millisecondes en microsecondes. Une lecture physique de base de données sur un réseau prend généralement de 2 à 10 millisecondes selon la latence du réseau et l'indexation de la base de données. La récupération de cette même paire clé-valeur à partir de la mémoire locale prend moins de 10 microsecondes, ce qui entraîne une réduction quasi totale du temps de récupération pour ce point de données spécifique.

Refactorisation vers NER pour une logique basée sur des ensembles

Placer cinq instructions Fetch Single consécutives dans l'événement Grid Record Is Fetched d'une application transactionnelle lourde comme P4210 ou P4312 est un anti-pattern architectural. Chaque Table I/O au niveau FDAOutil de conception graphique utilisé pour créer et modifier les écrans des applications JD Edwards. force le serveur HTML à se coordonner avec le serveur Enterprise, générant une surcharge massive de la pile d'appels pour chaque ligne de la grille. Le déplacement de ces Table I/O répétitifs dans une Named Event Rule (NER) consolide immédiatement ces opérations de base de données fragmentées en un seul composant C compilé.

Ce changement vous permet de regrouper les étapes de validation liées — telles que la vérification des enregistrements d'articles par succursale F4102, les instructions de facturation client F03012 et les codes de catégorie F4101 — dans un bloc d'exécution unifié. Étant donné que la NER s'exécute directement sur le serveur Enterprise, la logique métier s'exécute beaucoup plus près du moteur de base de données. Au lieu de cinq allers-retours distincts depuis la couche de présentation, le système traite la logique de validation localement sur le niveau application, réduisant les temps d'exécution de plus de 100 millisecondes par ligne de grille à quelques millisecondes seulement.

Pour implémenter cela, définissez une structure de données propre qui accepte les champs clés de la ligne de grille — tels que MCU, ITM et AN8 — et renvoie les cinq attributs requis, tels que le type de ligne, les conditions de paiement et le coût de l'inventaire, en un seul appel. Cette liste de paramètres structurés élimine le besoin de lectures de base de données séquentielles et indépendantes dans le FDA.

En regroupant ces récupérations, vous minimisez le bavardage réseau entre le serveur HTML, le serveur Enterprise et le serveur de base de données, transformant un goulot d'étranglement ligne par ligne en une opération efficace basée sur des ensembles. Pour une grille chargeant 100 lignes, cette optimisation réduit les appels réseau individuels de 500 à seulement 100. Cela détermine directement si l'application reste réactive sous des volumes de production.

Implémentation de l'API JDE Cache dans les Business Functions C

Lorsqu'une grille contient 500 lignes ou plus, l'exécution d'extractions de base de données via Table I/O dans l'événement Grid Record Is Fetched est très susceptible d'augmenter l'utilisation du CPU du kernel callObject. Pour une performance maximale, les Business Functions (BSFN) basées sur le langage C utilisant les API jdeCache offrent la récupération de données à la latence la plus faible car elles éliminent la couche de traduction du middleware. Opérant directement dans l'espace mémoire du kernel callObject, ces API contournent entièrement le pilote de base de données une fois le chargement initial terminé.

Les API jdeCacheInitFonction de programmation utilisée pour initialiser un nouvel espace de stockage en mémoire vive., jdeCacheAdd et jdeCacheFetch permettent aux développeurs de gérer des tables de données structurées en mémoire directement dans le kernel callObject. Pendant l'événement Dialog Is Initialized ou Post Dialog Is Initialized de l'APPL, une BSFN en C peut exécuter un seul SELECT SQL optimisé pour charger l'ensemble du sous-ensemble d'enregistrements de référence requis — comme 1 000 enregistrements de constantes de succursale — dans une instance de cache personnalisée. Cette opération de base de données en un seul voyage remplace des centaines d'instructions SELECT individuelles qui s'exécuteraient autrement pendant le chargement de la grille.

Une fois le cache rempli, les itérations suivantes de la boucle de grille interrogent le cache mémoire à l'aide de jdeCacheFetchPosition, contournant complètement le pilote de base de données et la pile réseau. Cette exécution d'API au sein d'une BSFN C cible le compartiment de cache spécifique à l'aide d'une structure d'index prédéfinie, récupérant la ligne requise en un temps inférieur à la milliseconde. Dans une APPL à haut volume avec une grille de 500 lignes, le remplacement des recherches SQL individuelles par jdeCacheFetchPosition fait généralement chuter le temps total d'exécution des règles d'événement de plusieurs secondes à une fraction de seconde. Les développeurs doivent coupler cela avec un appel final à jdeCacheTerminate dans l'événement End Form/Close pour éviter les fuites de mémoire dans le kernel callObject.

Form Extensions et Orchestrations comme alternatives

Le remplacement des Event Rules héritées par des Form ExtensionsOutil permettant d'ajouter des champs ou de la logique aux écrans sans modifier le code source. dans la Tools Release 9.2.x fournit une méthode sans code pour mapper des champs sans toucher à l'APPL. Dans les personnalisations P4210 ou P4310, les développeurs écrivaient historiquement des ER sur "Grid Record Is Fetched" pour extraire des données de F0101 ou F4101. Les Form Extensions contournent cela en mappant directement les colonnes, réduisant les coûts de mise à niveau d'une part significative, souvent jusqu'à la moitié, pour une simple récupération de données.

Lorsque des jointures multi-tables sont requises, la Tools Release 9.2.7 utilise l'OrchestratorPuissant outil d'automatisation permettant d'intégrer JDE avec des systèmes tiers via des services REST. pour exécuter des opérations de regroupement au niveau de la base de données. Au lieu d'exécuter 500 instructions SELECT individuelles pour calculer le solde ouvert d'un client, un seul appel REST renvoie la somme pré-agrégée. Cela déplace la charge de calcul vers le moteur de base de données, où les index optimisent la récupération en millisecondes.

Un échec architectural critique se produit lorsque les développeurs appellent ces Orchestrations à l'intérieur d'un événement de boucle de grille, tel que "Row Is Exited/Changed Inline" ou "Write Grid Line-Before". Chaque invocation individuelle d'Orchestration déclenche une requête HTTP POST sortante du serveur AISServeur d'interface qui traduit les requêtes web en commandes compréhensibles par JD Edwards., introduisant 15 à 50 millisecondes de latence réseau par ligne. Dans une grille affichant 200 lignes, cet anti-pattern ajoute plusieurs secondes de surcharge réseau pure, rendant l'application inutilisable et performant bien moins que les lectures de base de données ER standard.

Pour éliminer cette latence, invoquez l'Orchestration une seule fois pendant l'événement "Post Dialog Initialized" pour extraire l'ensemble de données agrégées dans une structure de mémoire temporaire avant le chargement de la grille. Utilisez une recherche rapide par pointeur pour remplir les lignes de la grille, en évitant les sauts réseau sortants pendant la phase de rendu. Restreindre l'exécution de l'Orchestrator à ces tâches d'initialisation pré-grille à appel unique garantit des temps de réponse d'écran inférieurs à la seconde tout en maintenant une APPL propre et facile à mettre à jour.

Réduire la latence de sortie de ligne de plusieurs secondes à une fraction de seconde nécessite souvent d'aller au-delà des Event Rules standard pour passer à la mise en cache en C pour les tables à haut volume comme F4211 ou F0911. Pour les développeurs gérant des environnements 9.2.x.x, le remplacement des extractions de grille répétitives par des tableaux résidents en mémoire est le moyen le plus efficace de stabiliser les performances des APPL sous de lourdes charges concurrentes. Pour voir ces modèles appliqués à grande échelle — y compris les structures de cache BSFN spécifiques et les optimisations de demande de données Orchestrator — examinez notre portefeuille de projets techniques ou parcourez les analyses approfondies associées sur la gestion de la mémoire JDE et l'optimisation des performances AIS.