Traitement du message

Tous les composants décrits jusqu’à présent jouent un rôle dans le traitement des messages au fur et à mesure qu’ils transitent par BizTalk Server. Cette section fournit plus de détails sur la façon dont ces composants interagissent fonctionnellement, en commençant par la réception d’un message. La figure suivante montre la création d’un port de réception et le flux d’un message via le processus de réception.

Un port de réception se compose d’un ou plusieurs emplacements de réception et de zéro ou plusieurs cartes. Les cartes sont des feuilles de style XSLT (Extensible Stylesheet Language Transformations) utilisées pour transformer des messages XML d’une structure ou d’un format vers une autre et sont souvent utilisées dans le processus de réception pour normaliser les messages dans un format interne. Les emplacements de réception contrôlent les points de terminaison qui reçoivent les messages. Un emplacement de réception se compose de la configuration d’un point de terminaison pour un adaptateur de réception et d’un pipeline de réception.

Rôle de l’adaptateur

L’adaptateur de réception lance le processus de réception des messages en lisant un flux de données et en créant un message. Par exemple, l’adaptateur de fichier voit qu’un fichier a été placé à son emplacement configuré et lit ce fichier dans un flux. L’adaptateur crée un message (une implémentation de l’interface Microsoft.BizTalk.Message.Interop.IBaseMessage), y ajoute une partie (une implémentation de l’interface Microsoft.BizTalk.Message.Interop.IBasePart) et fournit le flux de données dans le contenu du composant.

En outre, l’adaptateur écrit et promeut dans les propriétés de contexte de message liées à l’emplacement, au type d’adaptateur et à d'autres éléments liés à l’adaptateur. Une fois le message et son contexte créés, l’adaptateur transmet le message au Gestionnaire de points de terminaison. Le message est ensuite traité via le pipeline de réception, qui a été configuré pour l’emplacement de réception. Une fois le message traité par le pipeline, une carte peut être utilisée pour transformer le message dans le format souhaité avant que endpoint Manager publie le message avec l’Agent de message.

Rôle du pipeline

Bien qu’il s’agit de l’adaptateur qui crée le message initial, la plupart du traitement qui se produit sur un message reçu se produit dans le pipeline de réception. Le traitement du pipeline traite du contenu du message ainsi que du contexte de message. Le contenu du message est généralement géré dans les phases de décodage, de désassemblement et de validation, tandis que le contexte du message peut être géré dans toutes les phases. Toutefois, un pipeline n’agit pas nécessairement sur le contenu ou le contexte. Par exemple, le pipeline pass-through par défaut n’a aucun composant configuré et n’effectue aucun traitement sur le contenu ou le contexte du message. Par souci de simplicité, ce document se concentre sur les composants de désassemblage, car ils ont généralement le plus d’impact sur le routage des messages.

Le travail du désassembleur consiste à traiter un message entrant à partir d’un adaptateur et à le désassembler dans de nombreux messages, et à analyser les données du message. Lorsqu’un message entrant comporte de nombreux messages plus petits, il s’agit d’un échange. Le désassembleur de fichiers plats et le désassembleur XML gèrent les échanges en permettant à un développeur de configurer des informations sur le contenu d’encapsulage (autrement dit, un schéma d’en-tête et de fin pour le désassembleur de fichiers plats et un schéma d’enveloppe pour le désassembleur XML) et le contenu du corps (potentiellement répétitif). En outre, ces deux désassembleurs analysent le message d’origine en contenu XML. Un désassembleur personnalisé n’analyse pas nécessairement le contenu en XML si un traitement XML supplémentaire dans BizTalk Server n’est pas obligatoire. Un exemple de scénario peut inclure une situation de routage simple dans laquelle les messages entrant dans le système à un emplacement de réception particulier sont envoyés à un port d’envoi spécifique sans mappage ni autre traitement XML.

Routage avec le type de message

L’une des propriétés de message les plus courantes utilisées dans le routage est le type de message. Lorsqu’un développeur crée un schéma pour définir la structure des messages, ce schéma définit le type de message pour ce message. Le type est déterminé par le nœud racine et l’espace de noms dans la définition de schéma. Par exemple, un document XML qui ressemble à ce qui suit aurait un type de message http://tempuri.org/samples/MessageType#Message

<Message xmlns=http://tempuri.org/samples/MessageType>  
<SomeOtherElement type="sample"/>  
</Message>  

Pour utiliser le type de message dans le routage, il doit être promu dans le contexte. Les désassembleurs sont utilisés pour intégrer cette valeur dans le contexte du message, ainsi que par les composants de pipeline ayant la connaissance la plus précise de la structure des messages. Les désassembleurs xml et de fichier plat favorisent le type de message lors du traitement des messages, et tout désassembleur personnalisé doit également promouvoir cette propriété pour garantir un routage approprié.

Il est important de noter qu’un message n’est pas requis de avoir un type. Comme mentionné précédemment, les parties d’un message peuvent être des données binaires et n’ont pas besoin d’un schéma qui définit leur structure. Ce type de partie de message est généralement transmis par BizTalk Server sans qu'il y ait beaucoup de traitement, le cas échéant, effectué par BizTalk Server lui-même, bien que des composants de pipeline personnalisés, des adaptateurs ou du code appelé depuis des orchestrations puissent interagir avec ces parties.

Les composants de pipeline, tels que les adaptateurs, écrivent et mettent également en avant des propriétés au sein du contexte du message. En fait, les composants de pipeline sont le mécanisme le plus courant que les développeurs utilisent pour obtenir des propriétés dans le contexte de message. Les développeurs créent des schémas et peuvent promouvoir des propriétés dans le schéma. Ces informations sont stockées dans le schéma sous forme d’annotations qui peuvent ensuite être utilisées par les composants de pipeline. Tous les composants de désassembleur et d’assembleur intégrés ( FlatFile, XML et BizTalk Framework) utilisent le schéma de document pour récupérer des informations sur les propriétés à promouvoir. À l’aide de l’instruction XPath (XML Path Language) des annotations, le désassembleur connaît l’emplacement dans le document d’éléments à promouvoir. Pendant le processus de diffusion en continu via le document, le désassembleur recherche les éléments qui correspondent à l’une des instructions XPath et promeut ou écrit la valeur dans le contexte selon les besoins.

Les composants de pipeline personnalisés peuvent également être conçus pour intégrer les propriétés au contexte de données arbitraires présentes dans un message reçu ou envoyé. Pour promouvoir une propriété dans le contexte et être utile pour le routage, ce qui est probablement la raison pour laquelle la valeur est promue, un schéma de propriété avec une définition pour la propriété doit être créé et déployé sur BizTalk Server. Avant de définir un schéma de propriété à utiliser par des composants personnalisés, vous devez comprendre les différents types de propriétés promues. Les propriétés promues définies dans un schéma de propriété peuvent avoir l’un des deux types de base :

• Microsoft.XLANGs.BaseTypes.MessageContextPropertyBase ou

• Microsoft.XLANGs.BaseTypes.MessageDataPropertyBase

  Une propriété avec un type de base de MessageDataPropertyBase indique que la valeur de cette propriété provient du contenu du message. Il s’agit de la valeur par défaut des propriétés définies dans un schéma de propriété et est l’utilisation la plus courante. MessageContextPropertyBase indique une propriété destinée à faire partie du contexte de message, mais qui ne provient pas nécessairement directement des données du message. Les propriétés avec MessageContextPropertyBase comme type de base sont souvent promues par les adaptateurs et les désassembleurs et incluent des propriétés courantes telles que le type de message et le type d’adaptateur.

  Il est important de comprendre les différents types et de les utiliser correctement lors de la définition des propriétés. L’une des implications les plus importantes se produit lors de l’accès aux propriétés de contexte d’un message dans une orchestration. Si une propriété est identifiée en tant que MessageDataPropertyBase, le Concepteur d’orchestration examine le schéma du message reçu et garantit qu’il définit une propriété promue correspondante. Si aucune propriété n’est trouvée dans le schéma lié à la propriété promue accessible, le Concepteur ne vous permet pas d’y accéder. En revanche, si la propriété est définie comme étant un MessageContextPropertyBase, le type de message n’a pas d’importance et la propriété est accessible.

  Dans les pipelines personnalisés, le mécanisme de promotion ou d'écriture de propriétés au sein du contexte est très similaire. Pour écrire des propriétés, vous utilisez un appel à la méthode Write IBaseMessageContext pour placer la valeur dans le contexte. Pour les propriétés promues, vous utilisez simplement la méthode IBaseMessageContext Promote à la place. Chacune de ces méthodes prend un nom de propriété, un espace de noms et une valeur. Pour les propriétés promues, le nom et l’espace de noms sont ceux de la propriété définie dans le schéma de propriété et sont facilement accessibles en référençant l’assembly de schéma de propriété et en utilisant les propriétés sur la classe créée pour la propriété. Les champs distingués utilisent un espace de noms commun, http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFieldset l’expression XPath utilisée pour récupérer la valeur est généralement utilisée comme nom.

  Le code ci-dessous montre un exemple de promotion et d’écriture de propriétés dans le contexte. Notez que dans cet exemple, un champ distingué est écrit dans le contexte. Cela n’est utile que pour les orchestrations dans lesquelles le schéma de message identifie le champ distingué afin que le Concepteur d’orchestration connaisse le champ. Il peut être utile d’écrire des propriétés dans le contexte pour une utilisation par d’autres composants de pipeline côté réception ou envoi.

//create an instance of the property to be promoted  
SOAP.MethodName methodName = new SOAP.MethodName();  
  
//call the promote method on the context using the property class for name   
//and namespace  
pInMsg.Context.Promote(methodName.Name.Name, methodName.Name.Namespace,   
"theSOAPMethodName");  
  
//write a distinguished field to the context  
pInMsg.Context.Write("theDistinguishedProperty",   
"http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFields",   
"theDistinguishedValue");  

Gardez à l’esprit les faits suivants lors de l’écriture ou de la promotion de valeurs dans le contexte :

• Lorsqu'on écrit une valeur dans le contexte avec le même nom et le même espace de noms que ceux utilisés précédemment pour promouvoir la propriété, cela entraîne l'arrêt de la promotion de cette propriété. L’écriture remplace essentiellement la promotion.

• L’écriture d’une valeur null dans le contexte supprime la valeur, car les propriétés null ne sont pas autorisées.

• Les propriétés promues sont limitées à 256 caractères de longueur, tandis que les propriétés écrites n’ont aucune limitation de longueur.

  Les propriétés promues sont utilisées dans le routage des messages et sont limitées en taille pour des raisons d’efficacité dans la comparaison et le stockage. Bien que les propriétés écrites n’aient pas de limites strictes sur la taille, l’utilisation de valeurs excessivement volumineuses dans le contexte aura un impact sur les performances, car ces valeurs doivent toujours être traitées et transmises avec le message.

  Lorsqu’un message est prêt à être envoyé à partir de BizTalk Server, il subit un processus complémentaire dans le port d’envoi. Les mappages sont appliqués aux messages avant l’exécution du pipeline d’envoi, ce qui permet de transformer un message dans un format spécifique au client ou à l’application avant d’être traité par le pipeline et envoyé via l’adaptateur. Dans le pipeline d'envoi, au lieu de transférer des propriétés vers le contexte du message, celles-ci sont retirées du contexte pour être intégrées dans le message.

  

Voir aussi

Runtime Architecture
Comment BizTalk Server traite les messages volumineux