Blogging BizTalk

Lets Discuss BizTalk

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.


25 responses to “Sequential Convoys / Singleton Orchestration In BizTalk Demo

  1. EdZ November 27, 2013 at 10:36 pm

    Do you have the code for this? can you share?

    • Pushpendra Singh November 27, 2013 at 10:43 pm

      Hi Ed,

      Thanks for checking. It is there towards the bottom of my post, however please note this is a very simple example.Let me know if you face any challenge while implementing. Also I ave not provided the bindings of send and rcv ports. you will have to create them on your own.

      Pushpendra Singh

  2. Daniel Nguyen February 21, 2014 at 12:45 pm

    with your scenario can be occurs zombie? And, when one message errors can suspend orchestration instance, so how to handle to save this error message or something like that, then process next message?

  3. chinhvan2311 February 21, 2014 at 1:18 pm

    with your scenario can be occurs zombie? And, when one message errors can suspend orchestration instance, so how to handle to save this error message or something like that, then process next message?

    • Pushpendra Singh February 21, 2014 at 4:20 pm


      This solution will not have a zombie since it is not designed to complete and I have mentioned it in my comments as you may want to put a delay to complete the orchestration. To your question yes you are always at risk of getting into zombie situation when you have a sequential convoy/Aggregator pattern. There is always a chance that a message might come in after you exit the convoy loop and before orchestration is marked complete. The error may look like : instnce compled w/o consuming al of its messges. You need to insure there is a minimal transaction happening after teh convoy loop meets an exit. Apart from that you may want to adjust your throttling settings. Also please not the zombie situation may only occur in high load scenarios


      • Simon Rivas February 28, 2014 at 12:38 pm


        Indeed zombies can occur, especially if the host is being throttled, which is very likely to happen in a message intensive scenario. Moreover performances may drop dramatically in such a scenario (tried and explained it a bit here :
        Nevertheless, this pattern is still very usefull and those drawbacks can be quite easily managed.

        Btw : Great post Singh! 🙂

      • Pushpendra Singh February 28, 2014 at 1:50 pm

        Thanks Simon

  4. Daniel Nguyen February 22, 2014 at 4:06 am

    thank for your response!
    I had tried create a biztalk project like you then I tested it.
    1. When one incoming message error, if we haven’t transaction (catch exception), the orchestration became
    suspended and do not process any next message.
    2. If we put a delay to complete the orchestration, the zombie
    can be occur when any message come after exit loop but haven’t completed orchestration instance.
    3. If I use the BTS.MessageType properties instead of BTS.ReceivePortName properties
    it’s work fine?

    • Pushpendra Singh February 22, 2014 at 4:15 am


      Nice to know you tried it. Since your orchestration got triggered it looks fine.

      I was wondering how your orchestration gets triggered direct bound port or specify later?


  5. Daniel Nguyen February 22, 2014 at 4:36 am

    I use the specify later port. so I’m wondering what are different happens between direct bound port and specify later at here?

    • Pushpendra Singh February 22, 2014 at 5:16 am


      As long as you can see the ReceivePortName as promoted in the context of incoming msg it wont make any diffirence. I am really not sure why it is not working for you. Will you be able to send me your orchestration project.( One more thing the port should not use the pass thru pipeline only xml rcv)


  6. chinhvan2311 February 22, 2014 at 7:15 am

    I’m using XML Recieve pipeline,
    I have post the reply contain link to download my project, but I don’t know why I posted can not show.

  7. Bane March 26, 2014 at 7:40 pm

    good work 🙂 !

    • Pushpendra Singh April 1, 2014 at 7:38 pm

      Thanks Bane

  8. Santosh. September 8, 2014 at 9:20 am

    Could you share the code please

    • Pushpendra Singh September 10, 2014 at 3:17 pm

      Hi Santosh,

      Just in boxed you the source code.

  9. Dave.bae July 21, 2015 at 7:46 am

    I read your article with interest.
    Could you share the code please?
    Have nice day.

    • Pushpendra Singh July 21, 2015 at 3:07 pm

      Hi Dave,

      Sent the code on your Gmail id.


  10. Ankit Khandelwal April 19, 2016 at 7:02 am

    Hi Pushpendra,

    Nice article for a beginner to understand the correlation.
    My question is,

    Is Singleton Orchestration and Sequential convoy are same?

    If not, then what is the difference?


    • Pushpendra Singh April 19, 2016 at 10:43 am

      Yes they are same

  11. Usman December 28, 2016 at 8:16 am

    Hi Pushpendra,
    Nice article and can you please share the code.

  12. ankur jain May 3, 2017 at 2:01 pm

    Hi Pushpendra,

    I tried many ways to implement Convoy, every time Orchestration goes in Dehydration and not responding to next message received.
    Please advise whats wrong I am doing.

    Problem Statement:- Messages should be received in Order and should go for further processing in same sequence.


    • PK January 31, 2018 at 3:38 am

      Sorry for replying late . Dehydration in convoy is normal. It means it is waiting for next rcv. How you have written your orchestration ?

  13. pavan January 31, 2018 at 3:05 am

    howto give looping condition please povide me solution as early as possible

    • PK January 31, 2018 at 3:33 am

      Use looping functiod on 2nd receive shape which follows correlation .What is your requirement ?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

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

All about BizTalk Server, Azure and .NET

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, and Enterprise Integration

%d bloggers like this: