La salle des machines – Doctrine DAL

(Troisième partie de la série en six parties « Le guide de la migration »)

Dans la première partie, nous avons défini la stratégie et l'approche simplifiée. Dans la deuxième partie, nous avons établi la gouvernance et l'importance de l'enrichissement de l'expérience utilisateur. Les réunions sont maintenant terminées. La salle de réunion est vide. Il ne reste plus que vous, le serveur et un fichier contenant des milliers d'enregistrements de fiches articles.

Bienvenue dans la salle des machines.

C’est là que le plan théorique se heurte à la dure réalité des données. Dans l’écosystème Infor LN, cette phase est souvent mal comprise. Nombre de consultants pensent que la migration se résume à écrire un script pour insérer des données dans des tables. Ils se trompent. Les ERP comme Infor LN sont des systèmes complexes, imprégnés de logique métier. Toute tentative de les alimenter de force les fera dysfonctionner.

Aujourd’hui, nous explorons le cœur technique de la migration : le cadre d’échangenon négociable doctrine DALet le piège psychologique des faux positifs.

La boîte à outils : bien plus que du SQL

À l'époque des anciens ERP sur site, nous avions un accès direct à la base de données. Pour créer un client, il nous suffisait, en théorie, d'écrire une requête SQL directement dans la table. Aujourd'hui, avec CloudSuite, cet accès est verrouillé. Nous devons utiliser les outils officiels fournis par la plateforme.

Bien que le marché propose des outils externes performants et qu'Infor fournisse des alternatives comme les compléments Excel (parfaits pour les mises à jour ponctuelles et de petite envergure), nous mentionnerons les schémas d'échange comme principal vecteur de migration, car il s'agit d'une solution intégrée déjà disponible pour tous.

Les schémas d'échange représentent le meilleur compromis entre performance et intégrité. Outil natif intégré directement à Infor LN, il traite les données localement sur le serveur tout en respectant pleinement la validation de la logique métier (DAL). C'est l'outil robuste conçu précisément à cet effet.

Considérez Exchange Schemes non pas comme un simple outil d'importation, mais comme un moteur de traduction. Il vous permet de mapper vos fichiers plats aux structures de tables internes de LN, en gérant les conversions à la volée. Que votre fichier source utilise des formats de date spécifiques ou nécessite un mappage de champs complexe, Exchange le convertit automatiquement selon la logique interne de LN. Il permet également la gestion par lots, vous assurant ainsi de pouvoir regrouper les importations et de respecter les dépendances, comme le chargement des groupes d'articles avant les fiches articles elles-mêmes.

La doctrine DAL : vitesse contre sécurité

Il s'agit du concept technique le plus important de toute la série. Infor LN repose sur une couche d'accès aux données (DAL). Cette couche logicielle se situe entre l'interface utilisateur (ou l'outil d'importation) et les tables physiques de la base de données.

Pour plus de détails techniques sur la manière dont le DAL maintient l'intégrité des activités, reportez-vous à la présentation officielle Infor LN DAL.

Lorsque vous créez manuellement un ordre de production à l'écran, vous ne vous contentez pas de saisir des données. Le DAL (Data Access Layer) effectue en arrière-plan des validations, vérifiant l'existence de l'article. Il gère les valeurs par défaut et renseigne automatiquement l'entrepôt selon la logique du groupe d'articles. Plus important encore, il gère les déclencheurs.
La création d'un en-tête peut déclencher la création d'opérations de routage par défaut ou l'allocation de stock dans une table distincte.

Soyons honnêtes : la couche d'accès aux données (DAL) présente des avantages et des inconvénients. Son principal défaut réside dans sa lenteur, car la validation de la logique enregistrement par enregistrement est gourmande en ressources de calcul. Désactiver la DAL accélère considérablement la migration, permettant de charger des millions de lignes en quelques minutes. Cependant, cette rapidité a un coût élevé : la sécurité.

Lorsque vous contournez la couche d'accès aux données (DAL) (en utilisant les modes de mise à jour de table), vous supprimez une protection essentielle. Le système n'effectue aucun contrôle d'intégrité lors de l'insertion. Il accepte aveuglément les données que vous lui fournissez. Le risque est de charger avec succès des données erronées qui semblent correctes dans la table de base de données, mais qui provoquent des dysfonctionnements dès qu'un utilisateur tente d'interagir avec elles.

Par exemple, vous pouvez charger un élément, mais comme la couche d'accès aux données (DAL) n'a pas été déclenchée, des champs cachés importants restent nuls. Lorsqu'un utilisateur clique sur cet élément dans l'interface utilisateur, l'écran se bloque ou affiche des erreurs obscures.

Mon avis : contourner la couche d’accès aux données (DAL) n’est pas interdit, mais exige une extrême prudence. Cette pratique doit être réservée aux cas exceptionnels et gérée uniquement par des consultants techniques experts qui savent précisément quels champs cachés et quelles tables associées doivent être renseignés manuellement pour garantir la cohérence du système. Pour la plupart des migrations, la méthode DAL, plus lente mais plus sûre, reste le choix le plus judicieux.

Le piège des faux positifs

Une fois que vous vous engagez à utiliser le DAL, vous devez vous préparer à un phénomène particulier susceptible de provoquer la panique : l’erreur de faux positif. Le DAL est conçu pour être exhaustif. Lors de l’importation d’une structure complexe, comme un bon de commande de 50 lignes, le système valide chaque ligne individuellement. Cependant, pour chaque ligne traitée, le DAL revérifie souvent la logique de l’en-tête afin d’assurer la cohérence.

Imaginez la migration d'une commande d'achat où le fournisseur est signalé par un code d'erreur. Au chargement de la première ligne, le système vérifie l'en-tête et consigne une erreur : « Problèmes de qualité chez le fournisseur ». Au chargement de la deuxième ligne, l'erreur se répète. À la fin de la migration, le journal affiche 500 erreurs. En réalité, vous avez migré avec succès 10 commandes, et le système vous a simplement rappelé 500 fois un avertissement.

Pour gérer cela, l'équipe en charge de la migration doit filtrer les journaux. Il est essentiel d'identifier, lors des tests à blanc, les messages logiques répétitifs et non bloquants, et de créer une liste de codes sécurisés correspondant à du bruit. Si ce mécanisme n'est pas expliqué au préalable aux utilisateurs métier, ils douteront de l'intégrité des données à la vue d'un journal d'erreurs.

Performance contre intégrité

Passons à un autre aspect. Il ne s'agit pas seulement de la vitesse d'insertion brute, mais aussi de la gestion de la fenêtre de basculement. Lors du traitement de volumes de données massifs, comme la migration de milliers de lignes d'ordres ouverts, le temps de traitement estimé peut facilement dépasser les 48 heures disponibles pendant le week-end.

La solution ne consiste pas à contourner la couche d'accès aux données (DAL), mais à optimiser votre stratégie de traitement par lots grâce traitement parallèle. Au lieu de charger un fichier volumineux séquentiellement, divisez vos données en blocs logiques plus petits. Exécutez plusieurs lots simultanément sur différents ensembles de données qui n'entrent pas en conflit sur les mêmes tables. Cette approche vous permet d'exploiter pleinement la puissance de traitement du serveur et d'intégrer une charge de travail importante dans la planification du week-end sans jamais compromettre la sécurité et l'intégrité de la DAL.

Conclusion

Nous avons sélectionné nos outils. Nous savons lire les données sans paniquer. Le moteur est prêt, mais un moteur performant ne sert à rien si l'on ne connaît pas le circuit.

Dans la prochaine partie, nous élaborerons le plan. Nous aborderons le Plan de migration de la mise en service, le document principal qui définit précisément ce qui se passe, quand et qui déclenche la mise en service lors du week-end critique de lancement.

Écrit par Andrea Guaccio 

26 mars 2026