Debatching d’un message XML dans une orchestration avec un pipeline

Hao Wu
Publié par Hao
Catégorie : BizTalk
11/03/2019

 

Le contexte

Dans quels cas est-il nécessaire de débatcher un message XML dans une orchestration avec un pipeline au lieu d’utiliser « classiquement » un composant de pipeline sur un emplacement de réception ?

Il peut exister différents cas, mais nous identifions les 2 scénarios suivants :

  • Nécessité d’appliquer une map présente sur un Receive Port avant le débatching,
  • Les messages debatchés doivent être traités différemment après le débatching.

Dans cet article, nous allons nous intéresser au deuxième cas cité précédemment : découper un message au sein d’une orchestration afin d’appliquer des traitements différents selon la valeur contenu dans les sous-ensembles de ce message.

 

Description d’un cas exemple

Prenons l’exemple d’un processus métier qui consiste à réceptionner une liste de commandes. Notre besoin est d’identifier les commandes des clients VIP afin d’appliquer, par exemple, une remise commerciale. En fonction de cette information, nous appliquerons une map différente dans notre orchestration.

Pour ce faire, nous allons débatcher la liste des commandes dans une orchestration avec un pipeline. Nous obtenons alors des commandes unitaires. Sur chacune de ces commandes, nous effectuons un test pour contrôler si le client est VIP ou non, et nous appliquons une map différente selon les cas.

Ci-dessous se trouve le schéma XSD qui définit la liste des commandes et leurs contenues. Nous avons positionné propriété Envelope à yes sur le schéma.

Notons également que nous avons défini la propriété « estVIP » comme Distinguished Field pour l’utiliser simplement au sein de l’orchestration.

Si une commande n’émane pas d’un client VIP, le traitement appliqué est le suivant :

Si un client VIP réalise une commande, nous appliquerons une seconde map nommée Cmd_To_CmdVIP  :

Le script retourne un coefficient de 0.9 (remise de 10%) si le champ « estVIP » est vérifié (ici « 1 » représente vérifié). Notons également qu’un commentaire est ajouté pour les commandes VIP.

 

Contenu de l’orchestration

Voici l’orchestration qui permet de débatcher les commandes avec un pipeline :

Remarque : le projet Visual Studio doit référencer les assemblies Microsoft.XLANGs.Pipeline et Microsoft.BizTalk.Pipeline.

Au début de l’orchestration, un Receive Port permet la réception des commandes.

Le message de type System.Xml.XmlDocument permet de positionner le curseur dans un document XML.

Nous configurons le scope Debatch avec les propriétés Isolation Level = Serializable et Transaction Type = Atomic.

Par la suite, on déclare une variable GetMsgDebatch de type Microsoft.XLANGs.Pipeline.ReceivePipelineOutputMessages.

Dans la shape Expression nommée ExecutePipeline, l’expression contient le code suivant :


GetMsgDebatch = Microsoft.XLANGs.Pipeline.XLANGPipelineManager.ExecuteReceivePipeline(typeof(Microsoft.BizTalk.DefaultPipelines.XMLReceive), msgEntree);

La méthode ExecuteReceivePipeline() de la classe XLANGPipelineManager prend en paramètre un seul échange et retourne une collection de zéro ou plusieurs messages.

Dans la boucle GetAllCommandes, nous ajoutons l’instruction GetMsgDebatch.MoveNext(), elle permet de faire le boucle sur la collection de commande. En effet, cette méthode, issue de la classe ReceivePipelineOutputMessages, retourne un booléen qui s’il vaut false permet de sortir de la boucle.

Dans le shape Message Assignment GetMsg, le code est le suivant :


msgSorti = null;
GetMsgDebatch.GetCurrent(msgSorti);

msgSorti est un message de type Commande.

A cette étape, nous avons débatchées les commandes. Nous réalisons alors le test sur la propriété estVIP de la commande comme suit:


msgSorti.NomClient.estVIP == "1"

Si la commande concerne une client VIP, nous la traitons par la map Cmd_To_CmdVIP, sinon nous exécutons l’autre map.

Une fois l’assembly déployée, nous créons un ReceivePort et deux SendPort physiques puis nous les lions aux ports logiques de l’orchestration, comme illustré sur la figure ci-dessous:

Pour le test, nous avons constitué un message contenant 3 commandes dont 2 commandes VIP:

Comme attendu, les 2 commandes VIP sont présentes dans le répertoire VIP :

Nous pouvons vérifier que le traitement est correctement appliqué en regardant le contenu d’un des messages générés :