Persistance et durabilité du moteur

Cette section explique comment BizTalk Server intègre de manière fiable des processus métier faiblement couplés en persistant l’état du processus sur le disque via SQL Server. En persistant à des moments appropriés, en tirant parti des transactions, le système garantit qu’aucun état de processus n’est perdu même en cas de panne matérielle ou logicielle. Il s’agit de la durabilité du système.

Gestion des processus métier faiblement couplés

L’intégration de systèmes existants pour effectuer un processus métier logique unique nécessite la gestion de l’état du processus en dehors des systèmes existants. Que le processus métier soit long ou à courte durée, l’état du processus doit être maintenu indépendamment afin d’éviter l’explosion de chemins de communication personnalisés résultant d’un couplage étroit de systèmes.

Clairement, l’état d’une instance de processus métier en cours d’exécution doit être fiable si le processus métier est essentiel. Pour garantir que les processus métier sont fiables et durables, BizTalk tire parti des transactions SQL Server pour conserver l’état des processus et les données métier sur disque dans une base de données appelée base de données MessageBox. Pour plus d’informations sur la base de données MessageBox, consultez La base de données MessageBox.

Chaque message et toutes les instances de processus métier les plus triviales (par exemple, les instances d’orchestration) dans BizTalk Server sont conservées dans la base de données MessageBox au moins une fois pendant le traitement.

Persistance et durabilité

Le fait que BizTalk Server conserve tous les messages et la plupart des orchestrations a un impact direct sur la durabilité, comme indiqué dans Qu’est-ce que les performances durables ? À mesure que les messages arrivent dans la base de données MessageBox, ils sont routés vers des abonnés en attente (par exemple, des orchestrations et des ports d’envoi) et en file d’attente, ou publiés, dans des tables SQL messagebox pour attendre que les abonnés les récupèrent et les traitent. Certains messages arrivants activent de nouvelles instances d’abonné. D’autres messages arrivent et sont routés, via la corrélation, vers une instance en attente d’un abonné déjà en cours d’exécution, comme une orchestration corrélée.

Pour que les orchestrations corrélées continuent de traiter, les messages corrélés doivent rester non bloqués. Pour faciliter cette opération, BizTalk fait de son mieux pour s’assurer que les messages (à la fois activés et corrélés) continuent d’être reçus, même sous une charge élevée, afin que les abonnés en attente de messages corrélés puissent se terminer et rendre la place pour que d’autres processus s’exécutent. Cela signifie qu’il est possible de recevoir des messages plus rapidement qu’ils ne peuvent être traités et supprimés de la base de données MessageBox, ce qui crée un backlog de messages. Étant une technologie de stockage et de transfert, il est naturel que BizTalk fournisse ce type de mise en mémoire tampon ; cependant, des problèmes peuvent survenir si le taux de réception est constamment supérieur au taux de traitement, entraînant ainsi un important arriéré.

Chaque message reçu ou créé dans BizTalk Server est immuable. Autrement dit, une fois qu’il a été reçu ou créé, son contenu ne peut pas être modifié. En outre, les messages reçus peuvent avoir plusieurs abonnés. Chaque abonné d’un message particulier fait référence à la même copie unique de ce message. Bien que cette approche réduit le stockage, un nombre de références doit être conservé pour chaque message et maintenance doit être effectué régulièrement pour se débarrasser de ces messages qui ont un nombre de références de 0.

Si un backlog suffisamment volumineux est autorisé à s’accumuler dans la base de données MessageBox, les processus de maintenance de la base de données (implémentés en tant qu’ensemble de travaux SQL pour chaque base de données MessageBox) tombent en arrière et, si ce n’est pas l’occasion de rattraper, ils entraînent finalement des problèmes tels que l’épuisement de l’espace disque. Pour éviter cette situation, BizTalk Server fournit un mécanisme de limitation qui ralentit le taux de réception du message lorsque le backlog de base de données MessageBox passe à un niveau configurable par l’utilisateur. Pour plus d’informations sur la régulation, consultez Optimisation de l’utilisation des ressources via la régulation de l’hôte.

Compte tenu de toutes les activités et processus qui contribuent à la durabilité, la mesure principale de la durabilité au fil du temps est qu’un backlog n’est pas autorisé à croître indéfiniment. En d’autres termes, au fil du temps, il doit y avoir un équilibre entre les niveaux de débit élevé et faible pour que la base de données MessageBox puisse maintenir un backlog moyen constant et gérable. La mesure principale du backlog est la profondeur de la file d'attente, qui se présente comme un compteur de performances BizTalk Server appelé BizTalk:Message Box:General Counters:Spool Size. Pour plus d’informations sur ce compteur de performances, consultez Compteurs de performances de boîte de message.

Pour plus d’informations sur l’utilisation de la taille du pool et d’autres compteurs pour déterminer le débit maximal qu’un système peut supporter, consultez Mesure du débit maximal du moteur durable.

Recommandations

BizTalk Server conserve tous les messages et la plupart des orchestrations et peut, sans vérification, développer un backlog de messages pouvant entraîner des problèmes tels que l’épuisement de l’espace disque. La mesure principale du backlog est la profondeur de la table de la bobine de messagebox, qui est exposée en tant que compteur de performances appelé : BizTalk : Message Box : General Counters : Spool Size.

Lorsque vous envisagez un débit pérenne, la taille de la bobine doit maintenir une moyenne stable au fil du temps. Autrement dit, le spool ne peut pas continuer à croître indéfiniment. Dans la mesure du débit maximal du moteur durable, ce comportement est abordé plus en détail et une méthode de détermination du débit maximal qu’un système peut maintenir est fournie, ce qui tire parti de la taille du pool et d’autres indicateurs de performances.

Voir aussi

Mesure du débit maximal du moteur durable
Qu’est-ce que les performances durables ?
Conseils et astuces sur les performances
Compteurs de performances de la boîte de message