Blogging BizTalk

Lets Discuss BizTalk

Tag Archives: Convoy

Orchestration To Orchestration Call Via Direct Bound Ports For A Synchronous Process

This is a demo for calling one orchestration from another orchestration via direct bound port. Please note there is a strong binding between receiver and sender orchestrations hence if the receiver orchestration contracts or version changes at any point of time you will have to incorporate that in your sender orchestration as well.

Scenario: The main orchestration calls the sub orchestration and waits upon the reply to come back from sub orchestration to continue further.

Logic Behind: The main orchestration refers to the contract of the suborchestration via an assembly or directly (as I have done in this example). The main orchestration passes a unique promoted property to the sub orchestration(It can be a set of properties as well).Please ensure whatever property you are promoting has to be unique for each instance of the calling orchestration. The sub orchestration does its flow and before sending back the response it also returns the promoted property written in context of its response, back to the main orchestration. Now the main orchestration has a receive port listening on the sub orchestration response, it is following a correllationSet defined for the promoted property. Confused ? Ok, lets  walk through on how this has been implemented from coding perspective and I hope you will know what I am trying to explain.

1>Create a new BizTalk project and add two orchestration files there.

  • MainOrchestration.odx
  • SubOrchestration.odx

Define the request and response schemas for each of the orchestration. The body of the orchestration will look like this. I am not doing any complex logic here. The main orchestration creates the sub orchestration request>> sends it to the messegebox>> pick up the response from the message box>>creates its own response and sends it to a file send location. The main orchestration body will look like this.


2>We need to assign a unique property to the sub orchestration request message. I have created a property schema and will be using it to define my correlation property.


3>Since this unique property has to be available in the context of the sub orchestration request message it has to be promoted , we accomplish this by creating a new correlation set with the identified unique property.

4>Initialize this correlation set on the send shape for sending sub orchestration request and follow it on receive shape for the sub orchestration response.

write the remaining portion of Main Orchestration and you are done with it here.

5>The sub orchestration will look like this.


6>Since the sub orchestration needs to return the property which was sent by the main orchestration here also you need to create another promoted property used to store the value sent by main orchestration.


=Please note all the ports used to communicate with the sub orchestration is of direct binding type( Silly to mention but that is what I have designed this solution around)

Create a file receive port and trigger your orchestration. You should be able to see the following execution.This completes the demo. Please leave me a comment if you need some clarification or help. I will get back ASAP. Thanks.


Sequential Convoys / Singleton Orchestration In BizTalk Demo

A sequential convoy enables multiple single messages to join together to achieve a required result. A sequential convoy is a set of related messages that have a predefined order. Although the messages do not have to be exactly the same, BizTalk Server must receive them in a sequential order.

Few usage of them could be an aggregator orchestration or to introduce throttling. I will be covering those in later blogs.

In our example below all the messages arriving to one ReceivePort will trigger our orchestraion and all of them will be consumed within a SINGLE INSTANCE of the orchestration. In other words each incoming message is not triggering a new orchestration instance. I have tried to keep the orchestration simple but hopefully by the time you will finish reading this you will know what how the sequential convoys operate.

Using correlated Receive ports are key to sequential convoys. Here are the steps.

1>Create a new BizTalk solution and define your incoming and outgoing message schemas(You can refer to my previous posts in case you want to for doing that)

2>Add a new orchestration to your solution and design it similar to the Picture below.


3>Define correlation set and types and in the correlation properties we will use the “BTS.ReceivePortName” property since we want to have the convoy configured on all the messages arriving on a particular receive port.


Note:We can use a lot of other properties to define the “correlation ” for the sake of simplicity I have picked ReceivePortName.Let me know if you want to use some other properties and discuss it here.

4>On the first receive shape we will initialize this correlation set.


5>The second receive shape will follow this correlation set.


6>Create a physical receive port and send port. Bind orchestration and start all the ports, orchestration

When the first message arrives in the message box the orchestration picks that up and starts while initializing the correlation, when the 2nd message arrives instead of being subscribed for a new orchestration instance it rather goes to the 2nd receive shape which is following the correlation initialized by the first receive shape hence this message gets consumed by the existing orchestration instance. This loop goes on unless we write a logic for when to break it.

Try dropping xml files to your receive location, the admin console will show you all the artifacts triggered notice there is only on orchestration instance triggered. During the time when there are no messages coming into the receive location or orchestration will be in dehydrated state and and will rehydrate in event of a new message arriving into the port. Also this orchestration is not designed to complete, you may want to add a branch with delay shape to exit the infinite loop in the code, anyways thats a simple thing to do and we may handle this in mutiple way. Hope the example comes handy.


Need source code, please drop a comment with your email id and I will revert back ASAP.

Understanding Resume Pattern In BizTalk

So what if you are placed against a scenario to design a process which does multiple service calls and if one of the service return a fault with message ” ______field is not available at the moment but it will be after 2 hours” (May be because it is trying to look up some value from the database which is not yet created but soon will be created) you should be able to retry.

Note: This implementation is useful when you are making multiple synchronous service call, for example in an orchestration.If that is not the case you are better off having the retry done from the send port.

We achieve this by wrapping our send receive port within a scope which will suspend in event of exception.

I am trying to demo this here.

1>Create an orchestration which will look something like this. I will breakdown each component’s explanation further.


We have used two nested scopes having the “Long Running” transaction type, this is important since the atomic transaction is designed to just complete and cannot be resumed.

2>Use a loop shape and put your inner transaction scope within. Also define a variable which will govern if the loop should be executed or not.


3>Within the scope_suspend (That what I have named it, you can discard if you don’t like it ;-)) add an exception block. Also add the message construct shape to create your service request and have your send receive shape to service within as shown in the picture. In the exception block add the suspend shape. The variable which is governing execution of the loop has to set appropriately within exception block and outside exception block just after your service response receive shape.  your solution is ready.


How It Works:

When the orchestration makes the service call and there is a valid response returned from it goes to the 1st expression shape where we reset the flag for looping to insure it exits  the loop.

When the orchestration makes the service call and bumps into fault instead of a valid response it hits the “scope_suspend” catch exception block. There it sets the looping flag to true and goes to suspended resumable mode courtesy our next suspend shape. At this point the state of your orchestration is persisted.

So when you resume it the next time it basically restart the inner scope and check the loop flag which directs it to make the service call again.

That completes the demo.

Please note that Biztalk send port retires 3 times by default in case of failure. You may want to change this setting to 0 retries in case your service method is doing any add update or delete. Also you will see two suspended instances in admin console, one the orchestration which is resumable and other is the send port which upon resume will cause no effect to the orchestration. The suspended send port thou doesn’t brings any harm to your BT server but it may pile up in time and may cause performance issues. So you may want to enable failed message routing to take care of this. I will cover this topic later in a separate blog.

Please leave a comment if you need the source code or need any help implementing this.

Auto Resume An Orchestration

If there is a requirement of automating the resume of a suspended orchestration you may want to replace the suspend shape in orchestration with  delay shape.

So if the requirement is to auto resume orchestration after 10 hours, replace the suspend shape with delay shape of 10 hours. Either ways your orchestration state will be persisted.

How to implement resume pattern :

Parallel Convoys in BizTalk Demo Part 1

A parallel convoy enables multiple single messages to join together to achieve a required result. The set of related messages can arrive in any order, but BizTalk Server must receive all of them before starting the process.Attending Interviews : Jump on this page for a better framed definition:

Now lets concentrate on our purpose “HOW TO IMPLEMENT IT?”  In this example we are going to design a BizTalk solution which is expecting an order XML file and an Shipment Confirmation XML file from warehouse which may come in any order. Once these two are received we need to notify the customer via an outgoing XML file (ps: A customer will not understand a XML file hence we will need to have some service in  place to format the output XML and do the SMTP work and this is not in the scope of our current discussion) We are going to accomplish this by writing an orchestration with a design pattern of parallel convoys.

There are two key components to implement a parallel convoy orchestration.

  • Parallel Action shape
  • Correlation sets which will be initialized in all the receive shapes in the Parallel action branches.

Again like my previous post I have tried to keep the example simple to avoid confusion ( You are allowed to confuse your self later when you implement a more complex scenario around this model :-))

1>Add three schemas for Order(Inbound message), Warehouse shipment confirmation(Inbound message) and Customer Notification(Outbound message) to your BizTalk project.


2>Design an orchestration per this screen. Define correlation set  We are using two branches in parallel action and we need to initialize the correlation in the receive shape of both the branches. The purpose of having this initialize on both is to allow initializing of the correlation when either of the messages arrives. After the parallel shapes I have used a transform to create output message taking both the inbound message as the source of map(Check the picture below)





3>Create your receive and send ports, deploy your solution and complete binding of the orchestration. Start all of them and recycle HIS.

4>Drop an incoming Order xml file in your receive location. You will see a rcv pipeline and then an orchestration service started, you will also notice the orchestration has gone into dehydrate state since it is waiting for the other xml file for shipment confirmation. Drop the  shipment confirmation file. Check your admin console and you will see the orchestration has completed and the output xml file will show up in the send location.

AdminConsole Debugger

Also you may want to check the subscription of this orchestration and you will notice this has two subsctiption and thats how two seperate inbound messages are not triggerring two instances but they are rather consumed by only one instance.


This completes the demo. If you need the source code or have any questions please leave me a comment with your email id and will be glad to help you out.

Note: We can put the Receive Shapes in Scope Shapes with the Timeout property set to prevent the Convoy from waiting forever in case of multiple branches.




Find the maximum / minimum date in BizTalk maps using XSLT or with Cumulative Functoids

Challenge: BT maps xslt are essentially 1.0 indicating every data you see in there will be treated as string by default hence the sort function will not work for date time data type, please note xslt 2.0 does have the ability to recognize native data type.

Solution: First thing you need to do is string operate on the date time data to extract only the numbers, for example 2013-07-24T03:38:34.844467 shall be converted to 20130724033834 decimal which makes it fit to be sorted.

So my map will look like this.


Content of the scripting functioud:
public decimal ChangeDateToInt(string param1)
      return Convert.ToDecimal(((param1.Replace(“-“, “”)).Replace(“T”, “”)).Replace(“:”, “”));

In case you don’t want to use the cumulative max functoid please resort to following XSLT scrip to accomplish this, please note you will still need to do the string operation to extract the numeric equivalent value of the date time.:

        <!–Calculate Max Date Start–>
        <xsl:variable name=”MaxDate”>
         <xsl:for-each select=”YOUR XPATH TO THE DATE NODE COLLECTION”>
          <xsl:sort select=”.” data-type=”number” order=”descending”/>
           <xsl:when test=”position() = 1″>
            <xsl:value-of select=”.”/>
        <!–Calculate Max Date End–>
         <xsl:value-of select=”$MaxDate”/>

Please leave me a comment in case you have any questions.

Using Envelop Schema In BizTalk : Demo

What is Envelope Schema: It is a special type of schema which will allow you to carry multiple Payload messages wrapped in a single schema.

Where you Can Use it: Debatching, Aggregation.

The purpose of writing this post is to make us understand how it functions by picking up a simpler scenario, you can build on top of it to achieve more complex need.

What This Solution Does: Debatching

For the sake of simplicity I have created one envelope schema and one Payload Schema(Instances of which will be wrapped within envelope schema).

I have created a XML file Rcv Location where we will drop our envelope XML.Further I have created a send port having a subscription to the above Rcv port, hence whatever message arrives on the receive port will be sent to this send file location.

Our project is going to look like this:

For the sake of simplicity I have created only two schemas
1>SKU.xsd : It is your normal document schema.
2>SKUEnvelope.XSD : it is your envelope schema which will carry multiple SKU message XML within. Please see the picture.SchemaInstance

To create an envelope Schema you need to set the property Envelope to yes at the <Schema> node, and then you need to set the BodyXPath to the xpath of the node having the <any> element. Please see the below picture.


Once you have done that please go ahead and deploy. Create the receive and send port.
Now drop your envelope xml file to the receive location. The one I have used in this example has 4 SKU xml messeges wrapped within envelope schema. Hence when that gets picked up by the XMLReceive pipeline (This is the one which does the debatching) it results in 4 separate trigger of XML transmit pipeline component in turn reflecting on your  send port which will have 4 separate files each representing individual SKU payload XML we had wrapped within the envelope xml.


Please drop me a comment if you need any clarification. I will get back to you ASAP.

D Goins Insperience

Technological outformation for this day and age

[INACTIVE BLOG] Connected Thoughts - Thiago Almeida

Connected systems and the occasional picture

Uri Katsir's Blog

BizTalk , BizTalk RFID and .NET


My BizTalk Experiences

BizTalk Server Tutorial

BizTalk Server Concepts and Common Errors

Extremely Talented Monkeys

A Technical Blog by Ed Jones: Azure, .NET, BizTalk, WCF, and SQL Server

On All Things Web

Discussing web development without limits

Vikas Bhardwaj's Blog

Articles about BizTalk Server and .NET C#

Cloud develop

a blog about (cloud) development... because I'm a nerd

Hooking Stuffs Together

My learning logs from day to day work experience about Integration platform using Microsoft technologies.

Connected Pawns

Mainly BizTalk & Little Chess


a blogger in the process.

MS Innovations Blog

Tips, Tricks, and Workarounds for BizTalk and other Microsoft technologies


Katradhu Kaialavu,Kalladhadhu Ulagalavu!

Vijay Microsoft Technical

BizTalk, WCF, ESB ToolKit, Windows Azure

Mind Over Messaging

Musings on BizTalk, Azure, WCF, and Enterprise Integration