Anveo EDI Connect / Config / Sujets avancés / Optimiser les performances
C'est une traduction automatique. Le message original est disponible en 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 entièrement développée en Microsoft Dynamics 365 Business Central, avec tous ses 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 d’unité centrale unique, d’une connexion rapide à la base de données et de ressources suffisantes sur le serveur et le service tier SQL.

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.

Verrous de table

Chaque mapping s’exécute dans sa propre transaction de base de données et peut verrouiller les tables qui sont utilisées dans le mapping. En gardant les mappings aussi rapides et petits que possible, on peut réduire les verrous sur les tables utilisées dans le mapping.

Nous avons optimisé nos propres tables système pour qu’elles soient utilisées par plusieurs processus EDI en parallèle. Cependant, cela ne s’applique pas à nos tables tampons, qui, comme toute autre table, peuvent être verrouillées par un mapping. Nous recommandons donc d’exécuter les processus EDI en série et d’éviter autant que possible l’exécution parallèle.

Si les verrous se produisent principalement sur nos tables tampons, par ex. le document ANVEDI, il peut être utile de penser à des tables tampons propres pour les processus avec une grande quantité de données.

Les verrouillages de table sont principalement préoccupants dans les opérations normales de jour, où les utilisateurs attendent des ressources et où des charges différentes peuvent entraîner un comportement différent. Si le processus le permet, nous recommandons de programmer les travaux EDI la nuit, ou par exemple à l’heure du déjeuner, afin de réduire la charge sur le système.

Optimisations Mapping

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 position correcte 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.