Le projet comporte trois orchestrations :

1. City.odx pour gérer les messages validés par le schéma Ville.xsd.
2. Others.odx pour les autres types de message.
3. Main.odx pour agréger et envoyer les fragments d'un même message source vers le pipeline de sortie.

L'orchestration finale est la suivante :Les fragments sont déposés dans la message box. Ainsi il faut que l'orchestration City.odx soit capable de récupérer depuis la message box les messages validés par le schéma Ville.xsd. A cet effet l'orchestration utilise le mécanisme de direct binding.
Pour mettre en oeuvre ce principe il suffit de positionner les paramètres du port comme suit :Bien entendu si nous ne voulons pas récupérer tous les messages il faut les filtrer :Lors de l'étape de transformation il ne faut pas oublier de copier les paramètres de contexte du fragment donné en entrée vers le nouveau message. Ceci peut se faire ainsi (vous noterez l'utilisation de * pour signifier tout) :Toutefois une copie de contexte a l'inconvénient de démoter les propriétés personnalisées promues. En effet si on regarde de plus près avec l'outil d'administration de Biztalk on se rend compte, par exemple, que MsgSetID n'est plus promue :Pour promouvoir à nouveau ces propriétés il est possible de le faire soit par programmation soit, dans notre cas, en en créant un type de corrélation :Ensuite il suffit d'attacher cette dernière à la sortie de l'orchestration :Le résultat est bien celui attendu :Pour avoir plus d'informations sur la corrélation je vous recommande l'article de Roch sur le site du Biztalk User Group

Le port de sortie de l'orchestration City.odx redirige le résultat de la transformation vers la message box. Si nous n'y prenons pas garde cette dernière peut être consommée à nouveau par City.odx car elle répond aussi aux critères de filtrages attendus par cette orchestration. Ceci entrainerait une boucle infinie dans le système.
Pour éviter cette situation il faudrait un moyen de préciser que ce message est à destination de l'orchestration qui recompose le message de sortie et seulement cette dernière. Pour cela on dispose du mécanisme appelé Forward Partner Orchestration Direct Binding et qui consiste à faire en sorte que le port de sortie référence le port d'entrée de l'orchestration partenaire :Tous les autres de types de messages qui n'ont pas d'orchestration capable de les traiter sont consommés par Others.odx qui dans notre cas ne fait rien d'autre que de stocker l'entrée dans la message box en la redirigeant vers le pipeline d'entrée de l'orchestration de recomposition Main.odx (en suivant le mécanisme décrit pour City.odx) :L'orchestration de recomposition Main.odx est démarrée sur un message d'entrée, puis itère autant de fois qu'il y a de fragments provenant du même message source que le fragment qui a initié l'orchestration :Le nombre de fragments est stocké dans la propriété MsgCount et les messages provenant d'une même source sont identifiés par la propriété MsgSetID qui est utilisée dans une corrélation set :Le phénomène qui consiste à recevoir des messages en plusieurs points d'entrées de l'orchestration se nomme convoi. Le site msdn donne une explication détaillée de ce principe :PS : Le code de l'assembleur de sortie est quasiment inchangé.