Why would we need to debatch an XML message in an orchestration with a pipeline instead of using straight the receive pipeline on the port ?
It turns out that is interesting for the following scenarios:
- Require mapping before the debatching on a Receive Port,
- Require processing the debatched messages with different mappings.
In this article, we will illustrate the method of debatching in an orchestration with a user-case for the second scenario.
Here is the scenario: a list of orders (“Commandes” in French) is first received. Each order must be processed in a different way according to if the order is dedicated to VIP customers or not. For that, the list of orders will be debatched in an orchestration with a pipeline. Once a debatched order is obtained, a test is performed to check if customer is defined as VIP or not and to apply the right mappings
Following is the schema representing the orders list that contains the unit order with the property Envelope to yes. In the unit order, the estVIP property is defined as a Distinguished Field so that its value could be easily read in the orchestration.
We will limit the case to a very simple treatment : apply a different map according to value of the “estVIP” property.
For a simple order, here is the map that will be applied:
Whereas for a VIP order, the map named Cmd_To_CmdVIP will be as follow :
In the script, a sold (field Montant) of 0.9 is returned if the field estVIP is true (here “1” represent true). A comment for the order VIP is added in the mapping as well.
Hereunder is the orchestration that allows to debatch orders with a pipeline and process them.
Please note that the references Microsoft.XLANGs.Pipeline and Microsoft.BizTalk.Pipeline are required for the Visual Studio project.
In the beginning of the orchestration, a ReceivePort which receive orders is in place. The Message Type is System.Xml.XmlDocument that permits to position in a XML document.
The Debatch scope is defined with an isolation level set to Serializable and transaction type to Atomic value.
Thereafter, GetMsgDebatch variable of type Microsoft.XLANGs.Pipeline.ReceivePipelineOutputMessages is created.
In the shape Expression named ExecutePipeline, instructions are:
GetMsgDebatch = Microsoft.XLANGs.Pipeline.XLANGPipelineManager.ExecuteReceivePipeline(typeof(Microsoft.BizTalk.DefaultPipelines.XMLReceive),msgEntree);
ExecuteReceivePipeline() method of the XLANGPipelineManager class consumes either a single message or an interchange and yields zero or more messages.
In the looping GetAllCommandes, we do the following code
With the use of MoveNext(), we can do a looping through the collection. The method MoveNext() of the class ReceivePipelineOutputMessages returns a Boolean. If the returned value is false, we quit the loop.
In the shape Message Assignment with name GetMsg executes :
msgSorti = null;
Not that, the msgSorti variable is of Type Commande.
Until this step, we got the orders debatched. We realize a test on the order property:
msgSorti.NomClient.estVIP == "1"
if the order is coming from a VIP order, the map Cmd_To_CmdVIP is applied. If not, the other map is applied.
Now, let deploy the Visual Studio project into BizTalk server and create a physical ReceivePort and two physicals SendPort. We need to bind the ports to the logical ports of the orchestration, as shown in the following picture.
Then, we depose a message with three orders (Commande), in which contains two VIP orders, in the receive folder.
We have received therefore two VIP orders in the associated folder and one order in the other defined folder,
With the BizTalk map successfully applied: