Traitement par lots de messages pour l'envoi

Gestion par lots de l’adaptateur d’envoi

Lorsque vous utilisez des transactions côté envoi, la même transaction créée par BizTalk Server et utilisée pour l’envoi au système cible est utilisée pour la suppression de message correspondante une fois qu’elle a été envoyée avec succès. En cas d’échec, la transaction peut être terminée, auquel cas la suppression est abandonnée et les données restent dans BizTalk Server et non dans le système cible. Cela empêche la duplication des messages. Les transactions ne sont prises en charge que pour les adaptateurs d’envoi asynchrones. Vous ne devez pas utiliser de transactions avec des adaptateurs d’envoi synchrones.

Mais l’adaptateur ne peut pas simplement mettre fin à la transaction ; il doit également gérer correctement l’état des messages qu’il a reçus. Plus précisément, l’adaptateur doit appeler les méthodes Resubmit, MoveToNextTransport et MoveToSuspendQ de manière appropriée selon le nombre de nouvelles tentatives et si un transport de sauvegarde est disponible.

Il est important de placer les opérations Delete et SubmitResponse ensemble dans un lot qui utilise la même transaction. L’échec est géré en terminant la transaction (pour vous assurer que les données ne sont envoyées qu’une seule fois à un système externe). Toutefois, vous souhaitez toujours renvoyer le message ou appeler MoveToNextTransport pour le traiter à nouveau sur le serveur BizTalk. Pour ce faire, utilisez un lot normal (non transactionnel) distinct pour ces types d’opérations.

La figure suivante montre l’utilisation de lots distincts pour les messages de réponse.

Tri des lots transactionnels Send-Side par point de terminaison

Les lots de messages envoyés par BizTalk Server à l’adaptateur peuvent s’étendre sur plusieurs ports d’envoi (ou points de terminaison). Étant donné que l’adaptateur souhaite généralement avoir une transaction vers un point de terminaison unique, l’adaptateur doit trier les messages en fonction du port d’envoi (SPName ou OutboundTransportLocation). En procédant ainsi, l’adaptateur peut créer une transaction qui s’étend uniquement sur un port d’envoi particulier.

Par exemple, lorsqu’un adaptateur d’envoi FTP reçoit un lot de messages de BizTalk Server, il obtient un lot mixte de messages pour tous les ports d’envoi FTP actuellement actifs. Cela se produit parce que l’API est basée sur singleton, ce qui signifie que seul un seul adaptateur FTP est chargé, pas un par port d’envoi.

L’adaptateur doit d’abord trier le lot de messages qu’il a reçus par BizTalk Server en lots distincts, un pour chaque point de terminaison. Ensuite, il peut traiter chaque point de terminaison à son tour et construire probablement des lots de suppression pour chaque point de terminaison. Les classes réutilisables génériques BaseAdapter dans l’exemple de code du Kit de développement logiciel (SDK) fonctionnent de la même façon.

Triage pour envoi dynamique

Une orchestration BizTalk Server peut envoyer un message à un port qui n’a pas été configuré tant qu’il fournit des détails de configuration suffisants dans l’en-tête du message et dans l’URL elle-même. BizTalk Server doit reconnaître le protocole de l’URL.

Lors du tri des messages, vous devez prendre soin d’établir ce qui définit un point de terminaison. Cela est particulièrement vrai dans le cas d’un envoi dynamique. Si seul l’URI définit le point de terminaison, les choses sont simples. Toutefois, dans une session FTP, les informations de connexion de l'utilisateur peuvent être utilisées par le serveur FTP pour définir le point de terminaison véritable. Dans ce cas, si l’adaptateur se connecte en tant que compte différent, il peut être connecté à un autre répertoire.

Dans certains cas, le point de terminaison true n’est pas connu tant que vous n’avez pas exécuté la commande Enterprise Single Sign-On (SSO) ValidateAndRedeemTicket.

Dans le cas de MQSeries, la détermination de l’utilisation des transactions est configurable. Étant donné l’architecture et l’utilisation d’un objet COM+ distant, il est préférable de considérer un point de terminaison transactionnel comme distinct d’un point de terminaison non transactionnel.

Pour résumer, le tri des messages dans leurs lots de points de terminaison uniques est parfois une tâche nontriviale et peut impliquer des étapes supplémentaires telles que la prise en compte des valeurs de contexte et même le résultat d’un appel à l’authentification unique.

Tri de l'envoi statique

Si le point de terminaison est un point de terminaison configuré de manière statique, il existe un GUID unique sur le contexte de message appelé l’ID de port statique (SPID). Cette valeur peut être utilisée pour trier le point de terminaison. Le code suivant peut être utilisé pour le récupérer :

string spid = (string)message.Context.Read("SPID", "http://schemas.microsoft.com/BizTalk/2003/system-properties");  

Cela est utile lorsque vous tenez compte des problèmes introduits par l’infrastructure de configuration basée sur XSD (XML Schema Definition). Avec ce cadre, vous disposez d'une propriété qui pourrait faire partie de la clé de point de terminaison, enterrée dans le XML, au sein d'une seule propriété de contexte. Si vous avez un SPID dans le contexte, vous pouvez l’utiliser comme moyen de trier le lot. Sinon, vous effectuez un envoi dynamique et vous devez construire une autre clé avec laquelle trier le lot.

La figure suivante montre le tri des messages par point de terminaison.

N’oubliez pas que le nombre de tentatives d’un message ne tient pas compte de la réussite ou de l’échec d’un lot. Côté envoi, un lot de messages peut échouer, car certains messages du lot ont échoué. L’adaptateur doit déterminer chaque message qu’il reçoit. Dans le scénario de traitement par lots ayant échoué, vous pouvez supposer que chaque message est renvoyé. Toutefois, si tous les messages d’un lot défaillant sont resubmises, le nombre de nouvelles tentatives (qui est géré par le moteur BizTalk Server) est incrémenté de manière incorrecte même pour les messages réussis, car ils se trouvent dans le même lot que les messages ayant échoué. Dans ce cas, un adaptateur pourrait reformer le lot sortant et retenter l'envoi des messages réussis vers le système externe.