La partie difficile d’un projet JD Edwards EnterpriseOne Table Conversion pour migration de données legacy n’est presque jamais le mapping. Le mapping champ à champ est un travail mécanique qu’un analyste fonctionnel peut spécifier dans un tableur en deux semaines. Ce qui tue ces projets, c’est l’ordre de chargement entre F0101Address Book Master table — le fichier maître auquel chaque table transactionnelle dans JDE fait référence via la colonne AN8., F4101, F0911 et les tables transactionnelles associées, ainsi que l’absence d’un pack de réconciliation que le métier accepte de signer.

J’ai dirigé six migrations legacy vers JDE au cours des cinq dernières années, avec des volumes allant de 800 000 lignes à environ 40 millions sur l’ensemble des tables chargées. Le schéma qui distingue les cutovers clôturés à temps de ceux qui ont généré des tickets de support pendant neuf mois est constant — et il n’a rien à voir avec l’intelligence de la logique de transformation.

Ce qu’une Table Conversion signifie réellement dans JDE

Dans la terminologie JDE, la Table Conversion est un type d’objet spécifique (TC), généré via OMWObject Management Workbench — l’outil JDE utilisé pour extraire, modifier et promouvoir tout objet custom, y compris les Table Conversions, BSFNs, UBEs et applications. et exécuté via une logique de type R98403. L’effort d’ingénierie plus large qui déplace les données d’un système sortant vers les tables de production JDE combine presque toujours trois outils d’exécution : l’objet TC généré, des UBEs custom construites dans RDA, et des flux Orchestrator pour les chargements plus légers.

Un objet TC pur est l’outil le moins coûteux à construire et le plus difficile à étendre. Il fonctionne bien lorsqu’une ligne source se mappe proprement vers une ligne cible avec une transformation légère — conditions de paiement, catégories article, extensions address book. Dès que le chargement nécessite des écritures multi-tables, comme une commande client qui touche F4201 et F4211, avec d’éventuels prix F4209 et prix de base F4106, l’acquisition de NextNumbers ou une validation par ligne contre des tables UDC, l’objet TC cesse d’être le bon choix. Une UBE custom construite dans RDA, avec des Event Rules propres et des appels BSFN, est la seule réponse honnête.

Le malentendu que je vois le plus souvent, chez les clients comme chez les consultants juniors, consiste à traiter "Table Conversion" comme un synonyme de la migration complète. C’est un outil dans la boîte à outils, pas la boîte à outils elle-même. Si ce point est mal compris au début du projet, toute l’estimation est fausse d’un facteur deux.

L’ossature en cinq étapes qui ne change pas

Toute migration réussie vers JDE E1 suit la même ossature en cinq étapes : extract, stage, convert, load, verify. Les outils changent d’un projet à l’autre. Les étapes non.

Extract extrait les données du système sortant vers un format neutre — exports SQL, CSV ou fichiers plats écrits sur un partage de staging. La règle que je ne transgresse jamais : ne connecter aucun processus JDE directement à une base de données legacy active. Prenez un snapshot figé et auditable que vous pouvez rejouer autant de fois que nécessaire. Les replays ne sont pas optionnels ; ils auront lieu, généralement à 2 h du matin un samedi.

Stage dépose les lignes extraites dans des tables custom F55* côté JDE, calquées sur la convention de la table d’interface standard F5511Z1 : chaque colonne source, plus les colonnes de contrôle EDUS, EDBT, EDTN, EDLN, EDSP et un indicateur de statut de traitement. Le staging est l’endroit où les requêtes de validation s’exécutent à répétition sans toucher la production. Convert transforme chaque ligne stagée selon les règles JDE : validation UDCUser Defined Codes — les tables de lookup JDE stockées dans F0005 et F0004, qui valident les codes utilisés par pratiquement toutes les tables transactionnelles. contre F0005, normalisation des dates en julien, NextNumbers depuis F0002 lorsque la colonne cible est un numéro de document. Load écrit uniquement les lignes validées en production JDE. Verify boucle le processus avec des comptages, des contrôles d’intégrité des clés et des totaux financiers.

La seule phase que la plupart des projets sous-financent est verify. Trois à cinq jours de travail de réconciliation, planifiés dès le départ, évitent trois à six mois de bruit de support post-go-live.

L’ordre de chargement qui détermine si le projet se termine proprement

L’ordre de chargement est la décision technique avec le plus grand rayon d’impact dans tout le projet, et elle est presque toujours prise trop tard. La règle, dite franchement : masters avant transactions, toujours, sans exception pour des raisons de "commodité" ou de "nous corrigerons les orphelins plus tard". F0101 (Address Book Master) et F0111 (Who's Who) avant toute table transactionnelle qui référence AN8. F4101 (Item Master) et F4102 (Item Branch) avant les commandes clients, les commandes fournisseurs ou les transactions de stock. F0901 (Account Master) avant toute ligne de journal F0911. F4801 (Work Order Master) avant F4801T ou les détails de fabrication F31*.

Ce que "orphelins" signifie réellement en pratique : une ligne de customer ledger dans F03B11 avec un numéro client qui n’existe pas dans F0101 ne générera pas d’erreur au chargement, parce que les fichiers physiques JDE n’ont pas de clés étrangères imposées au niveau base de données. La ligne reste là. Trois semaines après le go-live, le rapport Aged Receivables affiche un solde qui ne se rattache à rien dans le customer master, et quelqu’un doit écrire une CTE pour trouver les orphelins, les comparer aux sauvegardes legacy, puis décider s’il faut créer ou supprimer.

Le coût d’un ordre de chargement correct est une semaine supplémentaire de travail sur le graphe de dépendances pendant la conception. Le coût d’un ordre incorrect est ouvert.

Idempotence, redémarrabilité et fenêtre de cutover

La propriété unique que chaque UBE de chargement du projet doit posséder est l’idempotence : exécuter deux fois la même UBE avec la même entrée produit le même état final. Le modèle le plus simple est "delete-where-source-batch-id then insert", limité à un numéro de batch que le chargement possède lui-même et écrit dans une colonne de contrôle. Sans idempotence, chaque échec pendant le cutover force une restauration depuis sauvegarde, ce qui, sur un dataset de 40 millions de lignes, double la fenêtre de cutover.

La redémarrabilité est la propriété liée : une UBE qui s’arrête à la ligne 4 millions doit pouvoir reprendre à la ligne 4 millions plus une, pas depuis la ligne une. Une logique de checkpoint dans la table de staging — une colonne "last_committed_row" mise à jour toutes les 10 000 lignes — représente vingt lignes de code EREvent Rules — le langage visuel de scripting utilisé dans les UBEs, applications et BSFNs JDE pour encoder la logique métier sans écrire de code C. et sauve des week-ends entiers de cutover. J’ai exécuté des cutovers où le chargement a échoué trois fois pour des raisons d’infrastructure sans lien entre elles, comme une coupure réseau, un token DB expiré ou un journal de transactions plein, et qui ont malgré tout atterri dans les temps parce que la logique de reprise était déjà en place.

La fenêtre de cutover elle-même est la période pendant laquelle les écritures legacy sont bloquées et le chargement delta final s’exécute. Plus la fenêtre est petite, plus les chargements delta ont été répétés auparavant. Deux week-ends de répétition delta avant le vrai cutover sont le minimum ; quatre sont normaux. Chaque répétition expose un mode de défaillance différent — la troisième trouve généralement la valeur UDC ajoutée au système legacy trois mois après le gel de la spécification.

La réconciliation comme livrable qui clôture le projet

Une migration se termine lorsque le métier signe le pack de réconciliation, pas lorsque la dernière UBE retourne RC=0. Le pack que je livre sur chaque projet comporte trois composants : les comptages de lignes par paire source-cible, les totaux financiers, comme la somme de AG dans F0911 rapprochée de la balance de vérification legacy au centime près, et une liste d’exceptions des lignes non chargées avec une raison typée pour chacune.

Les comptages de lignes sont la partie facile — une requête SQL à deux colonnes contre la table de staging et la table de production pour chaque paire. La réconciliation financière est la partie qui échoue le plus souvent, parce que les deux systèmes calculent les soldes de période différemment et que l’hypothèse naturelle selon laquelle "si les lignes de journal correspondent, les soldes correspondent" est fausse. Les soldes de période F0902 doivent être recalculés à partir des lignes F0911 chargées avec UBEUniversal Batch Engine — le moteur d’exécution batch de JDE, utilisé ici pour le job standard de recalcul des soldes de période F0902 après le chargement des lignes de journal. R09866 ou équivalent, sinon la balance de vérification sera décalée de la somme de chaque ligne de journal ayant franchi une limite de période.

La liste d’exceptions est l’endroit où vit la crédibilité d’ingénierie. Quarante mille commandes clients chargées, deux cent quatre-vingts rejetées avec des codes raison — c’est un résultat défendable. Quarante mille chargées, "quelques rejets" — c’est un projet qui n’est pas clos. Une fois que le métier signe ce pack avec des personnes nommées côté finance, la migration est réellement terminée. Tout ce qui apparaît plus tard relève du support post-implémentation, pas de la dette de migration. La discipline du pack de réconciliation transforme l’un en l’autre.

Si le niveau de détail ci-dessus correspond au type de perspective que vous recherchez sur le travail JDE, les articles liés sur le retrofit des copies de standard, les modèles de checkpoint UBE et la réconciliation F0911 après go-live approfondissent chacun des sujets abordés ici. Le portefeuille de projets techniques de ce site documente également deux des migrations qui ont produit ces conclusions, avec des chiffres anonymisés.