Dans un certain nombre de cas un système informatique reçoit des messages qu'il traite, transforme, enrichi... puis expédie vers un autre système. Quelques fois ce qui nous intéresse dans les messages reçus est un sous ensemble noyé au milieu d'autres informations et qui n'est pas nécessairement à la même position d'un message à l'autre.
Par exemple un système de traitement des commandes peut recevoir des fichiers de demandes en provenance de plusieurs sources, chacune contenant les données d'une commande d'un client au sein d'autres informations spécifiques à l'émetteur.

L'objectif de cet article est de vous faire découvrir le développement d'un désassembleur BizTalk qui prend en entrée n'importe quel document XML et construit un document multi-part en extrayant les fragments qui sont reconnus par des orchestrations de l'application BizTalk. Cela revient en gros à implémenter une enveloppe dont on ne connaît pas le schéma.
Pour cela l'utilisateur donne en paramètre au composant une liste de schémas (XSD) qui sert de pattern de recherche dans le document source.

Le schéma suivant résume ce que nous souhaitons faire :

1. Etape 1: l'utilisateur précise les fragments qu'il souhaite extraire à l'aide de schémas. Ces fragments peuvent se trouver n'importe où dans le document XML dont on ne connait pas la structure à l'avance.
2. Etape 2: le désassembleur extrait les fragments cibles et les remplace dans le document source par des éléments de type <Guid>....</Guid> qui seront utile lors de la reconstruction du document de sortie à la fin des traitements. Le nouveau message BizTalk est de type multi-part dont le body contient le message source mis à jour et les autres parts les fragments reconnus (un peu comme un email dont le corps serait le message source et les pièces jointes les fragments). Si je trouve un peu de temps, dans un quatrième article, on pourra implémenter une autre technique qui consiste non plus à créer un message multi-part mais N messages reliés entre eux via un interchange.
3. Etape 3: Une orchestration maître itère sur les fragments ainsi créés et appelle les sous-orchestrations capables de les traiter en fonction de leur type (XSD).
4. Etape 4: les orchestrations filles reçoivent en entrée un message typé et retournent un document XML qui est le résultat de leur transformation.
5. Etape 5: Nous avons un nouveau message multi-part à jour (les fragments sont remplacés par ceux provenant des orchestrations filles).
6. Etape 6: un assembleur reconstitue le message de sorti en intégrant les fragments transformés dans la source c'est-à-dire le body du message multi-part.

Ainsi l'idée serait de ne plus considérer les messages comme un bloc monolithique mais plutôt comme un ensemble de petits morceaux plus stables dans le temps limitant ainsi les risques liés à l'évolution de la structure du message. De cette façon l'impact d'un changement est limité à la structure élémentaire

Au cours de ces trois articles nous aurons l'occasion d'aborder les notions suivantes :

• Receive port
• Pipeline
• Message box
• Orchestration
• Map
• Send port

PS : l'objectif de ces articles est de manipuler un maximum de concepts BizTalk.