Modélisation des flux de travail de cartographie
Dans Anveo EDI Connect, vous utilisez normalement plusieurs mappages pour modéliser un processus EDI. Dans la suite, nous allons examiner des exemples très simples et un autre plus complexe. Le module est très flexible et vous pouvez modéliser le processus comme vous le souhaitez, mais les exemples suivants sont notre façon recommandée de modéliser le processus.
Avant d’entrer dans les détails, clarifions quelques concepts. Un mapping en Anveo EDI Connect peut être exécuté. Ensuite, il y a le concept de transaction de base de données. En termes simples, une transaction de base de données rassemble toutes les modifications apportées à la base de données au cours d’une transaction. A la fin de la transaction, les données peuvent être soit stockées de façon permanente, ce qui est appelé un commit de base de données. Ou bien les modifications peuvent être réinitialisées, c’est-à-dire que toutes les modifications apportées pendant la transaction sont annulées et non sauvegardées. Chaque exécution d’un mappage se fait dans une transaction de base de données distincte. S’il y a une erreur pendant l’exécution du mappage, la transaction est annulée. Sinon, la transaction est engagée. (Ceci est vrai pour la plupart des cartographies. Dans Anveo EDI Connect, il y a des triggers de table qui peuvent exécuter du code arbitraire. Si ce code contient une commande COMMIT, le module ne peut pas annuler les modifications. Cela peut conduire à des comportements indésirables).
Commande client XML entrante
Nous utilisons trois mappages dans cet exemple, pour importer un fichier XML. C’est le minimum recommandé. Dans un premier temps, nous allons mapper la structure des données externes sur des tables tampon. L’idée est d’importer les données, même si toutes les données ne peuvent pas être traitées. Cela permettra à l’utilisateur final de corriger les erreurs dans la transaction EDI, sans avoir à connaître le format des données externes. Bien entendu, cela n’est possible que s’il y a des erreurs de données, et non si la structure du fichier ne peut pas être analysée.
L’étape suivante consiste à vérifier les données. Ici, vous pouvez ajouter tout contrôle logique sur les données de gestion. Nous recommandons de le faire dans une étape séparée avant le traitement pour collecter plusieurs messages d’erreur et donner à l’utilisateur final un protocole d’erreur complet. Si vous devez rechercher des données dans la table système et que vous souhaitez les conserver, nous le faisons dans une quatrième étape entre le mappage externe et le mappage de contrôle.
La dernière étape est la création du document Microsoft Dynamics 365 Business Central. Nous le faisons dans une étape séparée, pour que les verrouillages des tables du système soient aussi courts que possible.
Facture EDIFACT sortante
Sur les documents sortants, vous avez généralement quelques valeurs, qui ne sont pas directement enregistrées dans la table source de la Microsoft Dynamics 365 Business Central. Pour donner à l’utilisateur final la possibilité de voir ces données et pour simplifier le mappage des formats de données externes, nous recommandons d’écrire d’abord les données dans une table tampon. Dans cette étape, vous pouvez rechercher des valeurs et effectuer des calculs.
Le mappage d’exportation prend juste les données mises en mémoire tampon et les écrit dans le format cible.
Processus EDI avec confirmation
Le processus n’a pas besoin d’être linéaire. Si vous devez envoyer des confirmations ou si vous voulez regrouper des données, vous pouvez toujours appeler plusieurs mappages à partir d’un seul. Vous pouvez également utiliser des conditions et un branchement conditionnel, pour exécuter différents mappages en fonction des données.
Comment configurer le workflow
Nous entrerons dans les détails plus tard. Si vous souhaitez aller de l’avant, nous utilisons deux techniques pour structurer le flux de travail de cartographie. Les opérations commerciales et le post-traitement.