Considérations sur les messages
BizTalk Server fournit un ensemble complet de fonctionnalités pour l’envoi, la réception, la transformation et le traitement des messages. Il s’agit notamment des fonctionnalités suivantes :
Possibilité d’envoyer et de recevoir des messages à l’aide de plusieurs transports standard du secteur, tels que HTTP, SMTP, FTP/FTPS et WCF. La prise en charge du niveau de transport pour l’envoi et la réception de messages s’effectue à l’aide d’adaptateurs BizTalk Server. L’intégration de BizTalk Server traitement des messages avec diverses applications métier est effectuée à l’aide de l’un des nombreux accélérateurs ou adaptateurs BizTalk Server disponibles, tels que l’accélérateur BizTalk pour HIPAA, l’accélérateur BizTalk pour SWIFT ou l’adaptateur SAP BizTalk. Ces accélérateurs et adaptateurs sont conformes aux normes de l’industrie, qui à leur tour prennent en charge l’intégration simple de BizTalk Server avec des systèmes conformes à des normes sectorielles particulières.
Possibilité de traiter plusieurs formats de message, tels que le texte brut, XML, binaire et autres. Cette fonctionnalité est essentielle pour assurer l’intégration de BizTalk Server avec un large éventail de partenaires commerciaux.
Prise en charge de la transformation des messages ou du mappage de documents. Le mappage s’adresse à la transformation des données entre différents schémas. Par exemple, le mappage peut être utilisé pour transformer le contenu d’un bon de commande client reçu en reçu avec notification d’expédition à renvoyer au client.
BizTalk Server orchestrations fournissent des fonctionnalités permettant de créer des processus métier qui s’étendent sur le temps, les organisations, les applications et les personnes. BizTalk Server fournit l’orchestration Designer interface graphique pour développer des processus métier qui incluent la prise en charge des transactions (à la fois de type MSDTC « atomique » traditionnel et de longue durée), la gestion des exceptions, le débogage, le suivi et l’extensibilité pour l’appel de code externe.
Notes
Consultez Optimisation des performances d’orchestration pour obtenir des conseils sur les meilleures pratiques à suivre lors de l’utilisation d’orchestrations dans BizTalk Server. Consultez la rubrique Création d’orchestrations à l’aide de l’Designer d’orchestration (https://go.microsoft.com/fwlink/?LinkId=158997) dans la documentation BizTalk Server pour obtenir des informations détaillées sur l’utilisation des Designer d’orchestration.
Le reste de cette rubrique décrit les considérations relatives aux performances liées à la taille, à la complexité et au profil de distribution des messages qui sont traités dans un environnement BizTalk Server.
Considérations relatives à la taille des messages
Bien que BizTalk Server n’impose aucune restriction sur la taille des messages, des limites et dépendances pratiques peuvent vous obliger à réduire la taille de vos messages, car les messages volumineux nécessitent davantage de ressources de traitement. À mesure que la taille des messages augmente, le débit global (messages traités par seconde) diminue. Lors de la conception de votre scénario et de la planification de la capacité, tenez compte de la taille moyenne des messages, du type de message et du nombre de messages BizTalk Server processus. N’utilisez pas de noms d’attributs et de balises inutilement longs ; si possible, conservez la longueur sous 50 caractères. Par exemple, n’utilisez pas un nom de balise de 200 caractères pour une taille de message de seulement 1 octet.
Si la taille en mémoire d’un message reçu dépasse le nombre d’octets spécifié pour la taille de fragment de message volumineux (configurable dans la page Propriétés du groupe pour BizTalk Group dans la console d’administration BizTalk Server), le message est divisé en fragments de la taille spécifiée. En outre, les fragments sont écrits dans la boîte de message sous le contexte d’une transaction MSDTC (Microsoft Distributed Transaction Coordinator) comme suit :
Si le message entrant est publié dans le contexte d’une transaction MSDTC existante, cette transaction est utilisée lors de l’écriture des fragments de message dans la base de données BizTalk MessageBox. Par exemple, si le message entrant est publié par un adaptateur transactionnel configuré pour exiger des transactions, la transaction existante est utilisée lors de l’écriture des fragments de message dans la base de données MessageBox.
Si le message entrant n’est pas publié dans le contexte d’une transaction MSDTC existante, une nouvelle transaction MSDTC est créée pour écrire les fragments de message dans la base de données MessageBox. Dans ce scénario, les considérations suivantes s’appliquent :
Augmentez la valeur de la taille des fragments de messages volumineux afin de réduire la fréquence à laquelle les messages volumineux sont fragmentés et de réduire l’incidence de la création des transactions MSDTC associées. Veillez à augmenter la valeur de ce paramètre, car une utilisation excessive de transactions MSDTC est coûteuse d'un point de vue des performances. Notez que l'augmentation de cette valeur peut également augmenter la quantité de mémoire disponible.
Si l’écriture d’un message dans MessageBox prend plus de temps que le délai d’attente maximal autorisé de 60 minutes, la transaction expire, une erreur se produit et la tentative d’écriture du message échoue et est annulée. La valeur de taille de fragment de message volumineux doit être suffisamment augmentée pour éviter ce problème lors du traitement de messages très volumineux. En fonction de la mémoire disponible, vous pouvez augmenter cette valeur jusqu'à un maximum de 1 000 000 octets.
Chaque fragment d'un message crée un ou plusieurs verrous de base de données SQL Server sur la base de données MessageBox. Lorsque le nombre de verrous dépasse plusieurs centaines de milliers, il est possible que SQL Server génère des erreurs « hors verrou ». Si ce problème se produit, augmentez la valeur de la taille des fragments de messages volumineux afin de réduire le nombre de fragments (ce qui diminue le nombre de verrous de base de données SQL Server effectués sur la base de données MessageBox) ou envisagez de loger votre base de données MessageBox sur une version 64 bits de SQL Server. Le nombre de verrous disponibles est considérablement plus élevé sur la version 64 bits de SQL Server que sur une version 32 bits de SQL Server. La formule suivante peut être utilisée pour estimer le nombre maximal de messages par échange lorsque la base de données MessageBox est hébergée sur une version 32 bits de SQL Server :
200,000 / (Number of CPUs * BatchSize * MessagingThreadPoolSize)
Pour plus d’informations sur la façon dont BizTalk Server traite les messages volumineux, y compris les instructions relatives au traitement des messages volumineux, consultez Comment BizTalk Server traite les messages volumineux (https://go.microsoft.com/fwlink/?LinkID=154680).
Considérations relatives au type de message
Les messages sont reçus dans BizTalk Server dans l’un des deux formats principaux : fichiers XML ou fichiers plats. Le type de message doit toujours être pris en compte dans le profil de distribution des messages en raison des besoins en ressources variables des messages XML et des fichiers plats.
Fichiers XML Pour que BizTalk Server effectue un traitement sur un message autre que le routage direct, le message doit être au format de fichier XML.
Fichiers plats Les fichiers plats doivent être analysés dans un format XML avant que BizTalk Server puisse effectuer un traitement autre que le routage direct. La conversion d'un fichier plat au format XML peut considérablement augmenter la taille du fichier. Les fichiers plats ne contiennent pas de balises XML qui décrivent leurs données, alors que les fichiers XML enveloppent toutes leurs données dans des balises XML descriptives. Dans certains scénarios, l’analyse peut augmenter la taille d’un fichier plat d’un facteur de 10 ou plus, en fonction de la quantité de données descriptives contenues dans les balises XML du fichier.
Documents de fichier plat encapsulés dans un seul nœud de section CDATA dans un document XML Ce type de document est une combinaison de fichiers XML et plats, et est souvent gourmand en mémoire, car BizTalk Server devez charger l’intégralité du document de fichier plat encapsulé dans la mémoire avant de le traiter.
Considérations relatives à la surcharge
La plupart des applications BizTalk Server ne reçoivent pas de messages à un rythme spécifique et constant. En règle générale, le traitement des messages est soumis à des pics et à des vallées. , Par exemple, une application bancaire en ligne peut traiter un volume plus élevé de messages d’abord le matin, puis au milieu de la journée et en fin de journée. BizTalk Server solutions doivent être testées pour s’assurer qu’elles seront en mesure de gérer ces scénarios de surcharge. Pour déterminer dans quelle mesure une solution BizTalk Server peut gérer les scénarios de surcharge, le débit maximal durable (MST) de la solution BizTalk Server doit être déterminé. Le MST est la charge de trafic de messages la plus élevée qu’un système peut gérer indéfiniment dans un environnement de production. Pour plus d’informations sur MST, consultez Planification des performances soutenues (https://go.microsoft.com/fwlink/?LinkID=158065) et Qu’est-ce que les performances durables ? (https://go.microsoft.com/fwlink/?LinkID=132304) dans la documentation BizTalk Server.
Complexité du schéma
Le débit pour l’analyse des messages (en particulier l’analyse de fichiers plats) est affecté par la complexité des schémas. À mesure que la complexité du schéma augmente, les performances globales diminuent. Lors de la conception de schémas, réduisez la longueur des noms de nœuds et déplacez les propriétés promues vers le haut du schéma. Cela réduit le temps de récupération et augmente ainsi les performances.
Complexité de la carte
En fonction de la complexité des cartes, la transformation de carte peut être gourmande en ressources. À mesure que la complexité de la carte augmente, les performances globales diminuent. Pour améliorer les performances globales, réduisez le nombre de liens et de fonctoids utilisés dans vos cartes, en particulier les fonctoids qui appellent des ressources externes telles que le fonctoid Recherche de base de données.
Considérations relatives à l’analyse de fichiers plats
Les deux facteurs qui ont le plus grand impact sur les performances de l’analyse de fichiers plats sont la taille des fichiers et la complexité du schéma. Un schéma ambigu est un schéma qui contient de nombreux champs facultatifs. Lorsque des fichiers de grande taille sont utilisés, un schéma avec de nombreux champs facultatifs peut dégrader les performances, car des fichiers plus volumineux peuvent correspondre à différentes branches du schéma. La complexité des schémas a moins d’impact sur les fichiers plus petits que sur les fichiers plus volumineux.