La plupart des ralentissements de performance dans les applications interactives personnalisées (APPLApplications interactives au sein de l'environnement JD Edwards.) ne proviennent pas de la latence de la base de données, mais de Event Rules (ER)Langage de programmation propriétaire utilisé pour définir la logique métier dans JD Edwards. mal synchronisées qui récupèrent des données lors de l'initialisation du formulaire. Lorsque les développeurs doivent extraire des données standard de l'Address Book en parallèle de configurations personnalisées, ils déclenchent souvent des allers-retours redondants avec la base de données qui peuvent plus que doubler ou tripler les temps de chargement des écrans. L'implémentation d'un exemple propre de JDE APPL pour les valeurs par défaut de la F0101 et des tables personnalisées nécessite une adhésion stricte au flux d'événements de Form Design Aid (FDA)Outil de développement JD Edwards utilisé pour créer et modifier les interfaces des applications. pour éviter la double extraction.

Au lieu d'empiler plusieurs lectures de tables F0101 et F550101 dans l'événement Post Dialog is Initialized où elles bloquent le rendu de l'interface utilisateur, les développeurs seniors doivent diviser l'initialisation. En isolant la validation de la clé primaire sur Control Exited and Changed Inline et en utilisant des lectures indexées directes et légères pour la table personnalisée, vous pouvez maintenir la surcharge d'exécution sous les 100 millisecondes par lancement de formulaire. Cette approche garantit que le runtime interactif reste très réactif, même sur des connexions WANRéseau étendu reliant des sites distants, souvent sujet à une latence plus élevée. à haute latence.

L'architecture d'une gestion propre des valeurs par défaut dans les JDE APPL

Observez n'importe quel développeur junior construire une application interactive dans Form Design Aid (FDA) et vous trouverez probablement l'événement Dialog Is Initialized étouffé par une douzaine de lectures de tables séquentielles. Cette approche par force brute introduit une latence de 200 à 500 millisecondes avant même que le formulaire ne s'affiche sur le client HTML de l'utilisateur. Lorsqu'elle est étendue à des centaines d'utilisateurs simultanés dans un centre de distribution à gros volume, cette surcharge inutile dégrade les performances JVMMachine virtuelle Java qui exécute les composants du serveur web JD Edwards. sur vos serveurs WebLogicServeur d'applications d'Oracle utilisé pour héberger l'interface utilisateur de JD Edwards. et crée une expérience utilisateur lente.

Une architecture de valeurs par défaut propre sépare la récupération standard de l'Address Book (F0101) des affectations personnalisées de business unit ou de codes de catégorie. Au lieu de coder en dur une logique de branchement conditionnel directement dans vos Event Rules, vous devriez découpler ces recherches en interrogeant une table de correspondance personnalisée dédiée comme la F550101. Cette table agit comme un registre centralisé pour les surcharges spécifiques à l'utilisateur ou à l'agence, garantissant que les futurs changements de schéma ou les mises à niveau de Tools Release ne brisent pas la logique de votre application principale. Par exemple, le routage de la branch/plant par défaut d'une transaction basé sur l'ID du terminal de l'utilisateur devrait être une simple lecture d'une seule ligne dans la F550101, et non une instruction IF imbriquée complexe dans l'ER.

Vous pouvez obtenir un gain de performance immédiat en laissant le moteur d'exécution JDE résoudre d'abord les valeurs par défaut standard du Data Dictionary (DD)Référentiel central définissant les caractéristiques et les règles de validation des champs de données., avant de déclencher toute extraction ER personnalisée. S'appuyer correctement sur les valeurs par défaut du DD pour des champs de base comme le search type (ATY) ou le tax explanation code (EXR1) élimine les allers-retours redondants, réduisant les E/S de base de données d'un tiers à la moitié sur les formulaires de saisie à haut volume. Ce n'est qu'après que le moteur d'exécution a terminé son initialisation native que votre ER personnalisée doit intervenir pour interroger la F0101 et la F550101 pour les surcharges métier spécialisées.

Configuration du schéma de base de données pour la F0101 et la table personnalisée F550101

S'appuyer uniquement sur la table standard Address Book Master (F0101) pour les valeurs par défaut de l'application limite votre flexibilité lorsque les utilisateurs exigent des comportements distincts basés sur leurs rôles opérationnels. Bien que la F0101 héberge des champs maîtres critiques comme le Search Type (AT1) et la Business Unit (MCU), ces champs représentent des attributs d'entité statiques plutôt que des valeurs par défaut spécifiques à l'utilisateur ou au contexte. Dans un flux standard de distribution ou de fabrication, la récupération du MCU directement depuis la F0101 fonctionne pour un routage de base, mais elle échoue lorsque différents départements traitant le même enregistrement d'Address Book nécessitent des centres de coûts par défaut différents.

Pour contourner cette limitation, nous déployons une table de correspondance personnalisée, F550101, qui agit comme une matrice de surcharge. Cette table associe des Search Types (AT1) spécifiques à des valeurs par défaut ciblées, incluant un Cost Center (MCU) par défaut et des Category Codes (GPH1) personnalisés. En découplant ces valeurs par défaut de l'enregistrement de l'entité principale, vous évitez de devoir modifier constamment les données de base standard lorsque les règles métier changent.

La structuration de la table personnalisée avec une clé primaire compositeClé de base de données composée de plusieurs colonnes pour identifier de manière unique un enregistrement. contenant l'User ID (USER) et le Search Type (AT1) permet une logique de valeurs par défaut granulaire basée sur les rôles. Par exemple, lorsqu'un représentant du service client interroge un enregistrement d'Address Book avec un AT1 de "C", l'application récupère un centre de coûts par défaut spécifique, tandis qu'un utilisateur des achats interrogeant le même enregistrement pourrait extraire une unité commerciale d'inventaire par défaut différente. Cette structure permet aux Event Rules de l'application d'effectuer une lecture directe à deux clés sans exécuter de logique conditionnelle imbriquée.

L'indexation de la base de données pour cette table doit être précise pour éviter la dégradation des performances lors des lancements d'applications à forte concurrence. La création d'un index primaire unique défini exactement sur USER et AT1 garantit que le moteur de base de données effectue des balayages d'index efficaces pendant la phase d'initialisation de l'application. Cette conception élimine la surcharge des balayages complets de table ou des recherches de lignes inutiles, maintenant les temps de réponse de la base de données sous les 10 millisecondes, même lorsque des centaines de sessions simultanées interrogent la matrice de valeurs par défaut.

Maîtriser le timing des événements : Dialog Is Initialized vs Post Dialog

Placer les lectures de base de données et les affectations d'interface utilisateur dans l'événement Dialog Is Initialized est une erreur classique qui se glisse encore dans les formulaires personnalisés Find/Browse et Headerless Detail. Dans le flux d'exécution du moteur runtime FDA, Dialog Is Initialized se déclenche avant que les contrôles du formulaire ne soient complètement instanciés et mappés à leurs structures de données sous-jacentes. Si vous tentez d'affecter une valeur récupérée de la F0101 ou de votre table personnalisée F550101 à un contrôle de formulaire ici, le moteur runtime rejettera fréquemment l'affectation, laissant vos champs à l'écran vides malgré le retour d'un statut CO ER_SUCCESS par la fonction métier.

Déplacer cette logique vers l'événement Post Dialog Is Initialized garantit que tous les contrôles de formulaire, champs de filtre et colonnes de grille sont complètement alloués en mémoire et prêts à accepter des entrées. Cet événement s'exécute immédiatement après l'initialisation du dialogue mais avant que l'utilisateur ne prenne le contrôle de l'application ou que l'action de recherche initiale ne se produise. Il représente le point d'ancrage le plus sûr et le plus stable pour peupler les valeurs de filtre par défaut, comme la récupération de la branch/plant par défaut d'un utilisateur ou l'extraction des détails principaux de l'Address Book depuis la F0101 pour pré-remplir les critères de recherche.

Les développeurs brouillent souvent cette séparation propre en codant en double la même lecture F0101 dans les événements de démarrage du dialogue et dans l'événement Control Exited and Changed Inline du contrôle Address Number (AN8)Numéro unique identifiant une entité (client, fournisseur, employé) dans JD Edwards.. Cela déclenche un scénario de double extraction coûteux, où le serveur HTML interroge la base de données lors du chargement initial du formulaire et réexécute immédiatement la même instruction SQLLangage standard utilisé pour communiquer avec et manipuler les bases de données relationnelles. lorsque le contrôle est validé. Réservez l'événement Control Exited and Changed Inline strictement pour la ré-affectation dynamique des valeurs par défaut lorsqu'un utilisateur modifie manuellement ou saisit une nouvelle valeur AN8, en gardant votre logique de démarrage isolée et efficace.

Code ER étape par étape pour la lecture de la F0101 et F550101

Dans la grande majorité des JDE APPL personnalisées que j'audite, les développeurs font l'erreur de croire que les contrôles de formulaire se peuplent séquentiellement sans validation explicite. Pour éviter la corruption des données, les Event Rules doivent d'abord exécuter un Table I/OOpérations d'entrée/sortie permettant de lire ou d'écrire directement dans les tables de la base de données. Fetch Single contre la F0101 en utilisant l'Address Number du formulaire (FC AN8) comme clé. Cette lecture doit récupérer le Search Type (AT1) et l'Alpha Name (ALPH) dans des variables locales. Stockez-les dans evt_szSearchType_AT1 et evt_szAlphaName_ALPH pour maintenir un contrôle strict sur le flux d'exécution.

Ensuite, interrogez la table personnalisée F550101 en utilisant une clé composite composée de l'AT1 récupéré et de la variable système SL UserID. Cela isole les surcharges spécifiques à l'utilisateur et au département, par exemple lorsqu'un planificateur de l'entrepôt 10 a besoin de valeurs par défaut différentes de celles d'un commis de l'entrepôt 20. Ce Fetch Single cible la Business Unit (MCU) personnalisée mappée à cette combinaison utilisateur-rôle spécifique dans votre table personnalisée.

Le point de pivot critique réside dans l'évaluation de la variable système SV File_Status immédiatement après la lecture de la F550101. Si SV File_Status est égal à CO ER_SUCCESS, affectez les valeurs de la F550101 à vos contrôles de formulaire. Si le système renvoie CO ER_RECORD_NOT_FOUND, votre ER doit se rabattre sur un second Fetch Single contre la F0101 standard pour récupérer le MCU standard, et enfin sur les valeurs par défaut du Data Dictionary si cela échoue également.

Négliger cette vérification immédiate est la raison pour laquelle des enregistrements fantômes finissent dans les tables de transaction. Sans cela, le moteur JDE conserve les valeurs des registres de la lecture réussie précédente, ce qui amène un utilisateur à écrire accidentellement des données de l'entrepôt 10 sur un enregistrement de l'entrepôt 20. Cette vérification à trois niveaux ajoute moins de 5 millisecondes au temps de chargement du formulaire mais élimine le risque de ces erreurs de contamination croisée.

Gestion de la ré-affectation dynamique lors de la validation du contrôle

Le déclenchement dynamique de la logique de valeurs par défaut lorsqu'un utilisateur modifie manuellement l'Address Number (FC AddressNumber) nécessite un contrôle absolu sur l'exécution des événements. Si vous dupliquez vos lectures de base de données F0101 et F550101 à la fois dans l'événement Post Dialog Is Initialized et dans l'événement Control Exited and Changed Inline du contrôle AN8, vous doublez instantanément votre empreinte de maintenance future. La bonne approche consiste à encapsuler tout ce bloc de valeurs par défaut dans une seule ER interne Subroutine: SetControlDefaults, que vous appelez ensuite depuis les deux points d'exécution.

L'exécution de lectures de base de données à chaque sortie de curseur peut dégrader les performances interactives, en particulier sur des connexions WAN à haute latence où une seule lecture F0101 ajoute une surcharge notable. Pour éviter les traitements redondants et les boucles infinies potentielles lors du paramétrage des contrôles dépendants, vous devez comparer l'AN8 nouvellement saisi avec la valeur précédente. Initialisez une variable d'événement cachée, evt_szPreviousAN8, lors de l'initialisation du dialogue, et enveloppez l'appel de la sous-routine dans une instruction ER If qui ne s'exécute que si l'entrée actuelle n'est pas égale à evt_szPreviousAN8.

Une fois la vérification de validation passée, appelez la sous-routine pour récupérer et peupler les contrôles cibles, puis mappez immédiatement le FC AddressNumber actuel à evt_szPreviousAN8 pour verrouiller le nouvel état. Ce modèle de conception garantit que l'application reste très réactive, en exécutant les instructions SQL SELECT contre la F0101 et la F550101 exactement une fois par changement de valeur réel. Dans une application de saisie de commandes typique traitant des milliers de transactions par jour, ce simple modèle de vérification d'état élimine des milliers de requêtes de base de données inutiles par session utilisateur.

Impact sur la performance et débogage de la logique de valeurs par défaut ER

Chaque lecture de base de données exécutée pendant l'initialisation d'un formulaire interactif ajoute une latence d'aller-retour entre le serveur HTML et le moteur de base de données. Dans les environnements à forte concurrence avec des centaines d'utilisateurs actifs, les lectures séquentielles de la F0101 et de la F550101 s'accumulent pour créer un décalage à l'écran. Combiner ces tables dans une seule vue de jointureObjet de base de données combinant les colonnes de plusieurs tables en une seule vue logique. personnalisée, telle que V550101A, élimine un aller-retour vers la base de données, économisant des millisecondes précieuses sur chaque transaction.

Pour vérifier l'efficacité de cette logique de valeurs par défaut, analysez le fichier JDEDEBUG.log ou le jdedebug.log local généré lors d'une exécution sur client web local. L'inspection de cette trace vous permet d'isoler les instructions SQL précises générées lors de l'événement Post Dialog Is Initialized. Vous devez confirmer que le runtime n'exécute pas d'instructions select redondantes ou de balayages de table complets en raison d'Event Rules (ER) mal construites.

Recherchez directement dans le fichier journal l'instruction SELECT ... FROM PRODDTA.F550101 pour vérifier que l'optimiseur de base de données utilise correctement l'index composite. Si vous voyez un balayage de table (table scan)Opération où la base de données lit chaque ligne d'une table, souvent signe d'un index manquant. là où un index composite personnalisé était prévu, votre plan d'exécution SQL est compromis. Cette analyse de trace prévient la dégradation des performances avant que l'APPL personnalisée ne soit promue dans l'environnement de production (PD920).

Les développeurs perdent fréquemment des heures à chercher pourquoi leur logique de valeurs par défaut ER ne parvient pas à peupler un contrôle de formulaire, pour finalement trouver le coupable dans les propriétés du contrôle. Assurez-vous que la propriété 'Suppress Default Update' n'est pas cochée dans les propriétés Form Design Aid (FDA) pour les contrôles cibles. Lorsque cette propriété est active, le runtime bloque les surcharges ER manuelles pendant la phase d'initialisation, rendant votre logique d'extraction personnalisée inutile.

L'implémentation de ce modèle de valeurs par défaut dans votre code APPL réduit les dizaines de lignes d'ER répétitives que l'on trouve souvent dans les anciennes applications 9.1. Si vous affinez vos applications personnalisées, l'isolation de vos lectures de base de données dans les fenêtres d'événements appropriées est le chemin le plus direct pour maintenir un environnement EnterpriseOneLe nom de la suite logicielle ERP moderne de JD Edwards. hautement réactif.