Anveo EDI Connect / Config / Sujets avancés / Optimiser les performances
This is an automatic translation. The original post is available in Anglais.

Optimiser les performances

Anveo EDI Connect est construit pour avoir des mappings flexibles qui peuvent être modifiés au moment de l’exécution. La fonctionnalité de base est développée entièrement en Microsoft Dynamics 365 Business Central, avec tous les avantages et inconvénients. Tous les paramètres sont stockés dans la base de données et doivent être récupérés pendant l’exécution pour déterminer comment le module va traiter les données EDI.

La vitesse du module dépend fortement de la rapidité avec laquelle le niveau de service peut récupérer les propriétés EDI. Pour chaque champ qui est lu ou écrit à partir d’un fichier, le module devra obtenir un ensemble de paramètres de la base de données pour traiter les données correctement. Cette opération est effectuée sur un seul cœur de CPU sur le service tier. Il est donc important que le service tier dispose d’un nombre suffisant de cœurs de processeur unique, d’une connexion rapide à la base de données et de ressources suffisantes sur le serveur SQL et le service tier.

Exécuter des tests de performance

Lorsque vous démarrez un projet avec une charge EDI élevée, ou que vous souhaitez importer de gros fichiers, nous vous recommandons de configurer le mapping d’importation sans tous les détails et d’effectuer des tests de performance. Vous pouvez également contacter notre service d’assistance pour lui demander son avis sur la question de savoir si votre scénario peut être traité en toute sécurité avec le module ou si vous devez d’abord le tester.

Optimisations deMapping

Certaines propriétés auront un impact sur les performances de votre mapping. En général, vous devriez essayer d’éviter toute boucle qui n’est pas nécessaire. Si vous importez des données, la plupart des convertisseurs vérifieront la structure des données récupérées pour chaque ligne de table en mode écriture. Vous pouvez gagner en performance, si vous définissez le nombre minimal de répétitions sur les tables d’écriture si vous savez que les données seront présentes dans le fichier. (Et si vous obtenez un fichier corrompu, le module donnera quand même un message d’erreur, car la boucle ne peut pas être convertie).

Vous ne devez importer dans les tables tampons que les données qui sont utilisées soit dans le traitement ultérieur des données, soit par l’utilisateur pour trouver et comprendre les erreurs. L’importation de données qui n’ont aucune valeur pour l’utilisateur final et qui ne sont pas utilisées plus tard dans le processus aura un impact négatif sur les performances.

Réduire le nombre de lignes dans le mapping peut améliorer les performances.

EDIFACT

Sur les mappings d’importation, vous pouvez supprimer tout élément de données du mapping qui n’est pas utilisé. Le module n’aura besoin que des informations sur le segment. Chaque élément de données stocke une position dans le fichier, de sorte que la suppression d’éléments avant celui dont vous avez besoin ne modifiera pas le traitement. Le seul inconvénient de cette approche est que vous devrez peut-être ajouter à nouveau l’élément, si vous devez traiter les données à l’avenir. Si vous placez des tables sur les groupes EDIFACT, vous devez définir la répétition minimale sur la table, si le groupe est obligatoire.

Lors des exportations, vous pouvez supprimer tout élément de données qui ne contient pas de valeur. Le module écrira automatiquement à la bonne position si quelques éléments de données sont manquants et vous accélérerez l’ensemble du mapping.

TEXTE

Il est souvent possible de réduire le nombre de lignes dans le mapping pour un fichier texte, s’il y a une structure en fin de ligne qui n’est pas nécessaire. Au lieu de lire tous ces champs, vous pouvez utiliser une seule ligne mapping pour tout lire jusqu’à la fin de la ligne, si vous n’avez pas besoin de traiter l’information.