L'orchestration principale est en charge de la lecture du message multi-part et de son exploitation.
La première étape consiste à créer cette orchestration. Pour cela on ajoute un élément nommé Main.odx, de type Biztalk Orchestration, au projet PipelineComponentTester créé lors du précédent article.

A cette orchestration nous allons ajouter un port qui va être le canal de réception des messages :Ce port a pour nom InputPort, pour type InputPortType et les autres paramètres sont les suivants :Il est important de noter que le pipeline de réception (champ Receive pipeline) est celui qui avait permis de tester le désassembleur lors du premier article.

Le message de réception est de type multi-part :Le premier bloc nommé, body, correspond au message reçu dans lequel les fragments reconnus ont été remplacés par des Guid. Ce dernier est un System.Xml.XmlDocument car on ne connaît pas à l'avance son type (qui est variable selon le message reçu en entrée).On ne crée pas les autres parts dans le designer car on ne connait ni leur nombre ni leur type. Le fait de se limiter à une seule part dans l'éditeur ne tronque pas les autres parts en provenance du désassembleur ; en effet elles sont encore accessibles par programmation.

Maintenant nous allons créer le message d'entrée de type PipelineComponentTester.MultipartMessageType que nous allons nommer InputMessage, puis, dans le designer nous allons ajouter un composant de type Receive et le configurer comme suit :

Pour mémoire dans le premier article nous avions créé quatre variables pour passer au désassembleur des variables qui :

1. Servent à filtrer les messages au niveau de l'orchestration cliente
2. Permettent d'attacher à la part le nom du XSD qui la valide.

Pour cela il nous faut créer un property schema auquel nous allons ajouter deux noeuds:Un premier, pour le message BizTalk, de type MessageContextPropertyBase ce qui lui permet d'être véhiculé dans le contexte du message et donc d'être facilement accessible. Si on avait choisi le type MessageDataPropertyBase alors l'information aurait circulé dans le message même et il aurait fallu le convertir vers son type avant de pouvoir y accéder.Le second noeud est utile pour les parts et il a pour type PartContextPropertyBase.

Voici donc les paramètres à donner au désassembleur au niveau du pipeline de réception:Grâce à ces propriétés nous pouvons maintenant filtrer les messages susceptibles d'être traités par notre orchestration :Le filtre s'applique sur la propriété de niveau message :

Plutôt que de vous montrer en fin d'article comment débugger une orchestration je vais le faire maintenant car ces techniques seront utiles pour valider au fur et à mesure le bon fonctionnement de l'application.
Pour cela nous allons déposer un composant de type Terminate sur le designer pour interrompre le traitement :Maintenant nous allons donner le nom de l'application BizTalk qui va héberger notre projet. Si cette application n'existe pas alors elle est automatiquement créée :Si nous souhaitons debugger l'application avec le Health Activity Tracker (HAT, nous allons découvrir cet outil dans un instant), il ne faut pas oublier d'activer la génération des pdb en sélectionnant l'option Generate Debugging Information dans le menu build de la section Configuration Properties.

Nous pouvons enfin déployer l'application avec Visual Studio :Il faut maintenant activer les ports de réception dans la console d'administration de Biztalk :Puis préciser le nom du host dans lequel l'orchestration va s'exécuter :On peut enfin démarrer l'orchestration :Le test consiste à placer le fichier XML vue lors du premier article dans le répertoire c:\test\in puis à utiliser la console d'administration pour récupérer les messages reçus par l'orchestration afin d'afficher leurs détails :L'affichage correspond à nos attentes :

1. Il y a bien un message multi-part composé de cinq parts dont le premier est le body (le Guid zéro)
2. Le contexte du message contient bien notre propriété DecomposerMessageProperty

Depuis cet écran il est possible de lancer le debugger d'orchestration :Ce dernier lance le HAT. Là il faut s'attacher à l'application BizTalk pour suivre le cheminement du message:Si votre compte de travail ne fait pas parti du groupe BizTalk Server Administrators alors une erreur d'affiche. Pour résoudre ce problème il suffit de mettre le compte de travail dans ce groupe.Si on souhaite debugger le code du désassembleur par exemple, en plus de la technique vue lors du dernier article, vous pouvez vous attacher au process BTSNTSvc.exe et profiter de toutes les fonctionnalités de Visual Studio.

La première question qui vient à l'esprit est comment parcourir les parts du message d'entrée sachant qu'on ne connaît à l'avance ni leur nombre ni leur nom. Si on inspecte le code généré avec reflector on note qu'un message multi-part est un message XLANG qui implémente l'interface IEnumerable et qui offre des indexeurs pour accéder aux parts par leur nom ou index :Pour accéder aux méthodes de cette interface il faut convertir notre message vers sa classe de base (sous le designer de BizTalk les méthodes héritées ne sont visibles qu'au niveau de la classe qui les implémente, dans notre cas XLANGMessage). Pour cela nous allons créer une variable de type XLANGMessage :Au niveau de l'orchestration nous allons ajouter un composant de type Set variables et faire les affectations suivantes :
InputBaseMessage = InputMessage;
Index = 0;

Ensuite il faut ajouter un composant de type loop pour parcourir les parts grâce à l'expression suivante :
Index < InputBaseMessage.CountMaintenant il nous reste à récupérer chaque part et à la traiter.
Une part est de type Microsoft.XLANGs.BaseTypes.XLANGPart, il faut donc céer une variable de ce genre pour acceuillir la part courante :
Part = (Microsoft.XLANGs.BaseTypes.XLANGPart)InputBaseMessage[Index];

Le nom du schema associé à la part est contenu dans la propriété PipelineComponentTester.DecomposerPartProperty car c'est à cet emplacement que le désassembleur a stocké cette information. Pour cela on ajoute un composant Set variables nommé Get part sur le designer avec le code suivant :
PartSchemaName = (System.String)(Part.GetPartProperty(typeof(PipelineComponentTester.DecomposerPartProperty)));

L'orchestration ressemble maintenant à ceci :Pour décider quelle sous-orchestration appeler nous allons ajouter un composant Decide qui fait un switch sur le nom du XSD retourné par la part. Dans notre cas elle se déclenche si la condition PartSchemaName == "SchemasContainer.City" est vraie :Nous allons maintenant créer une orchestration fille qui est spécialisée dans le traitement d'un message compatible avec le XSD City :