Blogging BizTalk

Lets Discuss BizTalk

Tag Archives: long running

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.



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 :

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