Modifier l'index d'une BSVWBusiness View : un objet JD Edwards qui joint une ou plusieurs tables et expose aux applications et aux rapports un ensemble fixe de colonnes ainsi qu'un index choisi. ressemble à une opération de cinq minutes dans BVDABusiness View Design Aid : l'outil JD Edwards utilisé pour définir quelles colonnes de table et quelle clé la Business View expose aux applications., et c'est précisément pour cette raison que cela casse plus de rapports que n'importe quelle autre modification isolée dans JD Edwards EnterpriseOne. Une BSVW peut être lue par des dizaines d'UBE, d'APPL et de form interconnects ; basculer sa clé de l'index 2 à l'index 4 dans OMWObject Management Workbench : la console JD Edwards qui contrôle le check-out, le check-in, le suivi des projets et la promotion des objets entre path codes. modifie l'ordre des lignes vu par chaque consumer et, si ne serait-ce qu'un seul dépendait du tri précédent, vous venez d'introduire un défaut de données silencieux en production.

Voici la procédure que j'utilise pour une modification d'index BSVW JD Edwards avec OMW et BVDA — la séquence exacte, la vérification des dépendances que j'exécute avant de toucher l'objet, et le chemin de rebuild qui maintient la modification propre à travers DVEnvironnement de développement dans JD Edwards : le path code où les développeurs font le check-out, modifient, compilent et testent unitairement les objets avant promotion., PYEnvironnement Prototype dans JD Edwards : le path code utilisé pour les tests d'intégration et l'acceptation utilisateur avant que les objets ne soient promus en production. et PDPath code de production dans JD Edwards EnterpriseOne. L'environnement live où les utilisateurs métier saisissent leurs transactions ; les modifications y sont déployées via promotion OMW depuis PY..

Pourquoi une modification d'index BSVW n'est jamais seulement une modification BSVW

Une BSVW ne stocke pas de données. C'est une définition SQLStructured Query Language : le langage standard utilisé pour interroger et manipuler des bases de données relationnelles. JDE génère du SQL derrière chaque BSVW, fetch et UBE. enregistrée au-dessus d'une ou plusieurs tables sous-jacentes, avec un index choisi qui détermine deux choses : la forme de la clause WHERE et l'ORDER BY par défaut. Quand vous changez l'index, par exemple de la clé basée sur la date à la clé basée sur le numéro de document, les clauses WHERE générées par le runtime changent de forme, et l'ordre dans lequel les lignes reviennent change avec elles. Tout consumer qui parcourait les résultats en supposant un tri par date les parcourt maintenant en ordre de numéro de document, et les agrégations, ruptures et logiques de type "first record wins" basculent sans avertissement.

Le deuxième problème est le nombre de consumers. Une seule BSVW utilisée dans un environnement opérationnel typique peut alimenter 10–30 UBE et 5–15 application forms. Le travail de 30 secondes consistant à changer la clé dans BVDA devient un travail de 3–4 heures pour trouver chaque consumer, l'ouvrir et confirmer qu'aucun ne dépend du tri précédent. Sauter cette étape transforme une optimisation d'index propre en incident de production deux semaines plus tard, lorsque les rapports d'agrégation de fin de mois commencent à placer des lignes dans le mauvais groupe.

Le troisième problème est que l'index doit réellement exister sur la table sous-jacente. La boîte de dialogue "Select Key" de BVDA liste chaque index défini sur la table primaire au niveau data dictionaryJD Edwards Data Dictionary : le référentiel central des définitions de data items (tables Fxxxx, champs de travail GTxxxx) qui gouverne la validation, l'affichage et les métadonnées des colonnes.. Si vous avez besoin d'une clé qui n'existe pas encore, vous ne faites pas une modification BSVW — vous faites une modification de table, qui est d'un ordre de grandeur plus invasive et nécessite l'implication de l'équipe CNCConfigurable Network Computing : la discipline d'administration JD Edwards qui possède les environnements, path codes, server packages et déploiements de base de données..

La vérification des dépendances que j'exécute avant de toucher l'objet

Avant tout check-out, exécutez la recherche de cross-reference dans P980011Application Cross Application Reference Repository dans JD Edwards : permet de lister chaque objet (UBE, APPL, NER, BSFN) qui référence une BSVW, une BSFN ou une table donnée. sur le nom de la BSVW. La sortie est la liste complète des UBE, APPL et NER qui la référencent. Pour chaque consumer, deux questions : itère-t-il le result set, et possède-t-il une logique qui dépend de l'ordre ? Si la réponse est oui aux deux, ce consumer doit figurer dans la liste de régression avant l'approbation de la modification.

Un raccourci utile : lisez directement les tables F9860 (Object Librarian Master) et F980011 (XREF) avec un client SQL. Une requête simple — SELECT FOOBNM, FOMODNAME FROM F980011 WHERE FOPONM = 'V55XXXXA' — vous donne la même réponse en une seconde au lieu de parcourir les résultats de recherche OMW. L'index XREF doit être reconstruit périodiquement dans JDE ; si votre dernier rebuild remonte à plusieurs mois, la liste est obsolète et vous manquerez des consumers ajoutés récemment. Exécutez d'abord le refresh XREF.

Pour chaque consumer qui dépend de l'ordre, capturez un snapshot "before". Exécutez l'UBE en DV sur un dataset figé, puis enregistrez la sortie. Le même dataset et le même UBE seront exécutés de nouveau après la modification ; le diff entre les deux sorties est votre critère d'acceptation. Sauter ce snapshot est la façon dont les équipes finissent par discuter avec les utilisateurs pour savoir si le rapport "a l'air différent" — il n'y a aucune mesure, seulement des opinions.

La séquence OMW et BVDA, étape par étape

La mécanique réelle compte huit étapes, toutes en DV, toutes via OMW :

1. Ouvrez OMW (P98220W) et localisez la BSVW par son nom (par ex. V55XXXXA).
2. Ajoutez l'objet à un projet OMW actif. Si vous n'êtes pas propriétaire d'un projet, créez-en un ; ne faites pas le check-out de l'objet dans le projet de quelqu'un d'autre.
3. Faites le check-out de la BSVW. OMW vous avertira si elle est déjà en check-out par un autre développeur — ne cassez jamais ce verrou sans confirmer avec lui.
4. Ouvrez-la dans Business View Design Aid (BVDA).
5. Depuis le menu : View → Select Table Columns. Confirmez que la table primaire et la liste des colonnes sont exactement celles que vous attendez. Ne modifiez pas la sélection des colonnes dans le même checkout qu'une modification d'index — gardez les modifications atomiques.
6. View → Select Key. La boîte de dialogue liste chaque index défini sur la table primaire. Sélectionnez le nouveau key item. Notez le numéro de clé que vous quittez et celui vers lequel vous basculez ; vous aurez besoin des deux pour le change log OMW.
7. Enregistrez et faites le build de la BSVW. Un build BSVW est rapide (quelques secondes), mais il doit réussir localement avant que vous puissiez faire le check-in.
8. Faites le check-in. Dans le commentaire OMW, documentez l'ancienne clé, la nouvelle clé et le nombre de consumers issu de la recherche XREF. C'est la piste d'audit qui vous sauve quand quelqu'un demande six mois plus tard pourquoi l'ordre de tri a changé.

Si le build échoue, la cause est presque toujours que la liste des colonnes référence encore une colonne qui n'existe pas dans la table de la nouvelle clé — typique lorsque la table primaire a été modifiée lors d'un check-out précédent et n'a pas été commitée proprement. La correction consiste à revenir en arrière, pas à forcer.

Quand l'index dont vous avez besoin n'existe pas encore

Si "Select Key" n'affiche pas l'index dont vous avez besoin, vous avez deux options, et elles ont des blast radii très différents. Option un : choisir l'index existant le plus proche et accepter le compromis. Option deux : créer un nouvel index sur la table elle-même. La deuxième option implique une modification de table, et une modification de table JDE est fondamentalement différente d'une modification BSVW.

Une modification de table touche TDATable Design Aid : l'outil JD Edwards utilisé pour définir les colonnes de table, les index, les clés primaires, et pour générer le DDL qui crée ou modifie la table physique de base de données. (Table Design Aid), génère un nouveau DDL et exige que la base de données soit physiquement reconstruite ou altérée dans chaque environnement. Le nouvel index doit exister en DV, PY et PD avant que toute BSVW ou tout UBE qui pointe vers lui fonctionne. Le déploiement appartient au CNC, pas au développeur qui a besoin de l'index. Prévoyez un cycle de génération et de déploiement de server package généralement de 1 à 3 jours, selon le calendrier de release de l'environnement.

L'autre risque est qu'ajouter un index à une table JDE standard (par ex. F4211, F0911, F4101) soit quelque chose dont le support Oracle discutera avec vous si un futur ESU touche la même table. Vous ne modifiez pas les colonnes de schéma — vous ajoutez un index — mais l'impact sur le débit d'insert/update d'une table à fort volume est réel et mesurable. Ajouter un index à F4211 dans une entreprise de distribution qui traite 100 000 lignes de commandes clients par jour est une conversation CNC, pas une décision réservée au développeur.

Si vous suivez cette voie : faites le check-out de la table dans OMW, ouvrez TDA, ajoutez l'index avec les colonnes dans l'ordre exact requis par la forme de clause WHERE souhaitée, enregistrez et faites le build, puis promouvez via les path codes standard. Ce n'est qu'ensuite que la BSVW peut être modifiée pour l'utiliser. Deux projets OMW séparés, deux check-ins séparés, deux fenêtres de déploiement séparées.

Construire et déployer la modification à travers DV, PY, PD

Une fois la BSVW check-in en DV, la modification n'est visible par personne sauf par un développeur qui teste en DV. Pour qu'elle atteigne les utilisateurs finaux, le projet OMW doit être promu : DV → PY → PD. Chaque promotion nécessite un build de server package piloté par CNC pour le path code cible. Une BSVW seule ne nécessite pas de full package build si vous utilisez specs over JavaSOJ (Specs Over Java) : le mode de déploiement JDE où les spécifications des objets sont servies depuis le deployment server au lieu d'être intégrées dans un full client package, supprimant la nécessité d'un full package build à chaque modification. (SOJ) — c'est l'un des principaux avantages de SOJ, et c'est le défaut sur toute Tools Release moderne.

Dans les environnements activés SOJ, la spec BSVW est récupérée depuis le store central des specs dès que la promotion OMW arrive. La modification est live immédiatement pour le path code cible. Sur un déploiement non-SOJ (rare sur les Tools Releases actuelles mais encore présent sur certains sites), un full client package build et deployment est nécessaire avant que la modification soit visible — une fenêtre de build de 30 à 60 minutes selon la taille de l'environnement.

Le test de régression se fait en PY, pas en DV. PY a des volumes de données proches de la production et les UBE consumers réels planifiés comme les utilisateurs les exécutent. Exécutez chaque consumer de la liste de régression sur le snapshot figé pris avant la modification. Comparez ligne par ligne. Ce n'est qu'après que chaque consumer correspond aux attentes que la modification reçoit le feu vert pour PD.

En PD, la fenêtre de déploiement est celle que prévoit votre politique de change management. La modification BSVW elle-même prend quelques secondes à atterrir. Le risque n'est pas le déploiement — c'est le premier UBE exécuté après le déploiement qui affiche un résultat que personne n'attendait. Préparez le projet OMW de rollback : un second projet qui contient la spec BSVW précédente, check-in mais pas encore promue, afin qu'un ingénieur CNC puisse faire un demote en quelques minutes si un utilisateur signale une régression dans la première heure.

Les erreurs qui cassent cette procédure en pratique

Le mode de défaillance le plus courant est de sauter l'étape XREF. Un développeur change la clé dans BVDA, fait le build, promeut, et découvre seulement deux semaines plus tard qu'un UBE de fin de mois dépendait de l'ancien tri. À ce stade, un mois entier de rapports a été émis avec le mauvais ordre de lignes, et les réémettre devient une discussion finance, pas développement.

La deuxième erreur consiste à regrouper une modification de clé avec une modification de colonne dans le même checkout. Quand quelque chose casse, vous ne pouvez pas savoir quelle modification l'a causé. Les checkouts atomiques ne sont pas de la bureaucratie — ils permettent de garder le scénario de rollback simple. Une modification par checkout, un projet OMW par modification.

La troisième consiste à créer le nouvel index sur une table JDE standard sans consulter CNC. Une table custom préfixée B55 relève de votre domaine développeur ; F4211 non. Ajouter un index à une table standard sans sign-off CNC est une voie vers un index supprimé silencieusement lors de la prochaine application d'ESU, ou pire, vers un problème de performance en production sur un chemin de code que vous n'avez pas mesuré.

La quatrième consiste à traiter la promotion BSVW comme une tâche purement développeur. Sur les environnements SOJ, le clic est petit, mais la modification atteint chaque UBE consumer à l'instant où la spec arrive. Il n'y a pas de soft-launch. La discipline qui rend cela sûr est la liste de régression et le snapshot du dataset figé, pas l'interface OMW elle-même.

Si ce niveau de détail procédural est ce dont vous avez besoin pour le travail opérationnel quotidien sur JD Edwards, les articles associés de ce site couvrent l'analyse de données SQL sur tables standard et custom, la mesure de performance BSFN avec logs et timings, ainsi que les patterns de projet OMW qui sécurisent les environnements multi-développeurs. Le portfolio de projets montre où ces techniques ont été appliquées à de vrais travaux d'upgrade et de retrofit.