Migrer de l’adaptateur MSMQT vers l’adaptateur MSMQ
Cette rubrique décrit les aspects à prendre en compte en relation avec la livraison chronologique de bout en bout des messages, la cohérence transactionnelle, la haute disponibilité et l'évolutivité avant de procéder à la migration des solutions de l'adaptateur BizTalk Message Queuing (MSMQT) vers l'adaptateur Message Queuing (MSMQ). Dans le cadre de cette rubrique, la livraison chronologique des messages, la cohérence transactionnelle, la haute disponibilité et l'évolutivité sont définies comme suit :
Livraison chronologique des messages. Garantie que les messages sont envoyés depuis BizTalk Server dans l'ordre dans lequel ils ont été reçus.
Cohérence transactionnelle. Garantie que les messages traités ne sont pas perdus ou dupliqués en raison d'une défaillance matérielle, logicielle ou du réseau.
Haute disponibilité : Garantie que les services utilisés pour traiter les messages sont toujours disponibles pour le traitement.
Scalabilité. Possibilité d'augmenter la capacité existante de traitement des messages.
Livraison chronologique de bout en bout des messages
L'adaptateur MSMQT assure la livraison chronologique de bout en bout des messages. Ainsi, si une application MSMQ envoie les messages 1, 2 et 3 à un emplacement de réception lié à l'adaptateur MSMQT, ces messages sont remis à une orchestration ou un port d'envoi dans BizTalk Server dans le même ordre : 1, 2, 3. Par exemple, cette fonctionnalité peut être utile pour les opérations boursières qui doivent être transmises et exécutées dans l'ordre dans lequel elles ont été reçues.
La livraison chronologique de bout en bout des messages avec MSMQT requiert le fonctionnement conjoint de divers composants. La séquence d'événements suivante illustre cet aspect avec l'adaptateur MSMQT :
L'API MSMQ sur un ordinateur distant reçoit les messages 1, 2 et 3 et les transmet à une file d'attente locale transactionnelle dans le même ordre : 1, 2, 3.
Un client MSMQ sur l'ordinateur distant extrait les messages de la file d'attente et les envoie à la file d'attente MSMQT dans l'ordre : 1, 2, 3.
L'adaptateur MSMQT reçoit les messages dans l'ordre 1, 2, 3 et les transmet au composant MessageAgent de BizTalk dans le même ordre : 1, 2, 3.
Le composant MessageAgent de BizTalk vérifie que les messages sont envoyés à la base de données MessageBox dans l'ordre : 1, 2, 3.
La base de données MessageBox achemine les messages et, si ceux-ci sont acheminés à la même instance d'une orchestration ou d'un port d'envoi, vérifie qu'ils sont remis à cette instance dans le même ordre : 1, 2, 3.
En BizTalk Server 2004, MSMQT était le seul adaptateur capable de garantir la livraison de bout en bout des commandes. Tous les autres adaptateurs BizTalk intégrés peuvent modifier l'ordre des messages au cours des étapes 3 à 5 indiquées ci-dessus. La plupart des autres adaptateurs intégrés effectuent l'étape 3 à l'aide d'un composant appelé Gestionnaire de points de terminaison. Celui-ci étant multithread par nature, il ne conserve pas l'ordre des messages. L’adaptateur MSMQ BizTalk Server 2004 utilisait une fonctionnalité de « traitement en série » qui préserve l’ordre pour l’étape 3, mais il ne demande pas ensuite à MessageAgent de conserver l’ordre à l’avenir, de sorte que les messages peuvent être acheminés vers une orchestration ou envoyer un port dans le désordre.
Livraison ordonnée de bout en bout avec l’adaptateur MSMQ
Pour obtenir une livraison ordonnée de bout en bout avec l’adaptateur MSMQ, procédez comme suit :
Activez la propriété Remise ordonnée sur le port de réception pour l’orchestration ou le port d’envoi abonné. Dans BizTalk Server, les ports de réception dans les orchestrations et les ports d’envoi ont une option de configuration Livraison ordonnée. Lorsque celle-ci est activée, le port de réception de l'orchestration ou le port d'envoi demande à la base de données MessageBox de lui remettre les messages dans l'ordre dans lequel ils ont été envoyés à la base de données MessageBox.
Définissez la propriété Traitement ordonné pour l’emplacement de réception lié à l’adaptateur MSMQ sur
True. Dans BizTalk Server, les emplacements de réception qui utilisent le transport MSMQ peuvent être configurés pour utiliser le traitement ordonné qui, s’il est activé, garantit que les messages sont envoyés à MessageBox dans le même ordre qu’ils ont été reçus.Définissez la propriété Transactional pour l’emplacement de réception lié à l’adaptateur MSMQ sur
True.Vérifiez que les files d'attentes MSMQ surveillées par les emplacements de réception MSMQ sont marquées comme « transactionnelles ». Cette propriété doit être définie sur les files d'attente pour assurer la livraison chronologique des messages.
Notes
La livraison chronologique des messages n'est garantie que si la ou les files d'attente MSMQ surveillées par les emplacements de réception BizTalk sont traitées par un seul ordinateur. Une telle configuration peut présenter des problèmes d'évolutivité, comme décrit ci-dessous.
Utilisation des transactions lors du traitement des messages avec l'adaptateur MSMQT et l'adaptateur MSMQ
Le traitement des messages par les adaptateurs MSMQT et MSMQ diffère du point de vue de l'utilisation des transactions.
Lorsque l'adaptateur MSMQT est utilisé, les processus ayant trait à la réception d'un message du réseau et à son traitement avec BizTalk Server sont gérés sous une seule transaction. De même, les messages d'accusé de réception générés pour l'expéditeur indiquent que le message a été reçu et traité par BizTalk Server.
Lorsque l'adaptateur MSMQ est utilisé, les processus ayant trait à la réception d'un message du réseau et à son traitement avec BizTalk Server sont gérés sous deux transactions distinctes (une pour la réception du réseau et une pour le traitement avec BizTalk Server). De même, les messages d'accusé de réception générés pour l'expéditeur indiquent seulement que le message a été reçu du réseau, pas qu'il a été traité par BizTalk Server. L'expéditeur reçoit un accusé de réception du serveur Microsoft Message Queuing lorsque le message est reçu du réseau et conservé dans la file d'attente MSMQ locale, que BizTalk Server soit installé ou non. Une fois le message conservé dans la file d'attente MSMQ, l'adaptateur MSMQ le récupère, le traite et le publie dans la base de données MessageBox. En cas d'échec de ce processus, le message est envoyé à la file d'attente des messages interrompus de BizTalk ou conservé dans la file d'attente MSMQ locale (lorsque le traitement transactionnel est utilisé), et l'expéditeur n'est pas informé de l'échec du traitement du message dans BizTalk Server.
Si votre architecture inclut la réception d'accusés de réception en cas de traitement réussi des messages par BizTalk Server, vous pouvez ajouter les accusés de réception au niveau de l'application si vous effectuez une migration de l'adaptateur MSMQT vers l'adaptateur MSMQ. Vous devez mettre à jour votre orchestration et l'application d'envoi pour implémenter les accusés de réception au niveau de l'application.
Haute disponibilité (transactionnelle, chronologique)
Pour assurer la haute disponibilité de l’adaptateur MSMQT, vous pouvez ajouter plusieurs ordinateurs à l’hôte de réception et configurer l’équilibrage de la charge réseau (NLB) pour la tolérance de panne, ou vous pouvez mettre en cluster l’hôte BizTalk par défaut. Si vous exécutez l'adaptateur MSMQT avec l'équilibrage de la charge réseau, les autres serveurs gèrent la charge d'un serveur tombé en panne. Si vous exécutez les gestionnaires de l'adaptateur MSMQT sur un hôte en cluster, l'échec d'un nœud d'hôte provoque l'échec du logiciel du cluster via l'hôte en cluster sur l'autre nœud. Lorsque l'adaptateur MSMQ est utilisé, l'équilibrage de la charge réseau ne fonctionne pas si vous devez utiliser le traitement transactionnel sans perte de données car l'adaptateur MSMQ utilise les files d'attente MSMQ locales pour le stockage intermédiaire. Dans ce cas, si un message remis à une file d'attente MSMQ locale n'est pas consommé par l'adaptateur MSMQ, il est perdu lorsque l'ordinateur échoue.
Pour fournir une haute disponibilité et une cohérence transactionnelle avec l’adaptateur MSMQ, vous devez effectuer les opérations suivantes :
Configurez Microsoft Message Queuing (MSMQ) en tant que ressource mise en cluster dans un groupe de clusters de serveurs Windows Server sur vos serveurs BizTalk Server.
Configurez le gestionnaire de réception de l'adaptateur MSMQ dans une instance d'hôte BizTalk préalablement définie en tant que ressource de cluster dans le même groupe de clusters que la ressource MSMQ en cluster.
Configurez la ressource de cluster pour l'instance d'hôte BizTalk afin qu'elle maintienne une dépendance sur la ressource MSMQ en cluster.
Pour implémenter la livraison ordonnée avec cette architecture, suivez les étapes présentées précédemment sous « Livraison ordonnée de bout en bout avec l’adaptateur MSMQ ».
Haute disponibilité (non transactionnelle, non chronologique)
Pour implémenter la haute disponibilité sans le traitement transactionnel à l'aide de l'adaptateur MSMQ, vous devez implémenter l'équilibrage de la charge réseau et exécuter les instances d'un hôte configuré avec les gestionnaires d'envoi et de réception MSMQ sur plusieurs serveurs BizTalk derrière l'équilibrage de la charge réseau. Lors de l’implémentation de l’équilibrage de charge réseau avec MSMQ, vous devez suivre les meilleures pratiques décrites dans l’article de la Base de connaissances Microsoft 899611 : Comment Message Queuing peut fonctionner sur l’équilibrage de charge réseau (NLB). Dans ce scénario, l'échec d'un des serveurs BizTalk provoque l'indisponibilité des messages exécutés dans l'instance d'hôte sur ce serveur jusqu'à la récupération du serveur BizTalk. Dans cette configuration, la haute disponibilité est assurée comme suit : si l'un des serveurs BizTalk n'est pas disponible, l'équilibrage de la charge réseau achemine les demandes vers l'autre serveur BizTalk.
Évolutivité (non transactionnelle, non chronologique)
Pour implémenter l'évolutivité, suivez les directives relatives à la haute disponibilité (non transactionnelle) et ajoutez des instances d'hôte supplémentaires. Cette architecture favorise la livraison rapide et l'évolutivité, mais n'assure pas la livraison chronologique des messages.
Évolutivité (transactionnelle, non chronologique)
Pour implémenter la livraison transactionnelle des messages sans livraison chronologique, vous pouvez combiner l'équilibrage de la charge réseau avec MSMQ et le clustering Windows. Cette architecture requiert la configuration d'au moins deux groupes de cluster dans deux environnements en cluster Windows distincts en suivant les étapes de la section « Haute disponibilité (transactionnelle, chronologique) » pour chaque cluster Windows. Vous devez ensuite implémenter l'équilibrage de la charge réseau pour répartir la charge entre les groupes de cluster. Comme l'équilibrage de la charge réseau n'est pas pris en charge sur un cluster Windows, ce scénario requiert une solution d'équilibrage de la charge réseau matérielle. Le diagramme suivant illustre cette architecture.
Notes
Cette architecture n'assure pas la livraison chronologique des messages.
Évolutivité (transactionnelle, chronologique)
L'évolution horizontale d'une architecture qui assure la haute disponibilité, la cohérence transactionnelle et la livraison chronologique des messages pose problème si MSMQ 3.0 ou une version antérieure est utilisée. En effet, les lectures transactionnelles à distance ne sont pas prises en charge sauf si l'ordinateur BizTalk Server et le serveur MSMQ distant exécutent MSMQ 4.0. Lorsque MSMQ 3.0 ou une version antérieure est utilisée, vous devez procéder à l'évolution horizontale à l'aide de plusieurs files d'attente MSMQ locales. Dans ce cas, si la connexion TCP/IP entre la session MSMQ et l'équilibrage de la charge réseau est interrompue, elle peut être restaurée par l'équilibrage de la charge réseau vers un autre ordinateur, ce qui peut entraîner une livraison non chronologique.
Pour contourner cette limitation, vous pouvez équilibrer manuellement la charge associée à la livraison des messages en affectant des files d'attente de destination à différents ordinateurs. Pour ce faire, vous devez lier des instances d'hôte BizTalk spécifiques à des files d'attente MSMQ spécifiques. Par exemple, si vous recevez un grand nombre de document d'un partenaire commercial particulier, créez un hôte distinct et une file d'attente de réception sur un serveur BizTalk particulier pour ce partenaire commercial uniquement.
Si possible, exécutez MSMQ 4.0 sur les ordinateurs distants lorsque les lectures transactionnelles distantes et l'équilibrage de la charge sont requis.
Résumé
Le tableau suivant récapitule les architectures que vous pouvez implémenter pour prendre en charge les fonctionnalités spécifiques.
| Fonctionnalité | Ni équilibrage de la charge réseau, ni cluster | NLB | Cluster | Équilibrage de la charge réseau et cluster |
|---|---|---|---|---|
| Livraison chronologique des messages de bout en bout | Oui | Non | Oui | Possible avec une configuration manuelle |
| Cohérence transactionnelle | Non (les messages peuvent être perdus ou dupliqués en cas de défaillance du service) | Non | Oui | Oui |
| Haute disponibilité | Non | Oui | Oui | Oui |
| Évolutif | Non | Oui | Non | Oui |
Voir aussi
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour