Blogging BizTalk

Lets Discuss BizTalk

Tag Archives: Microsoft BizTalk Server

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.

BizTalk : Error: Failed to add resource(s).Resource (-Type=”YOUR ASSEMBLY NAME”) is already in store and is either associated with another application or with another type.

Error: Failed to add resource(s).Resource (-Type=”YOUR ASSEMBLY NAME”)  is already in store and is either associated with another application or with another type.

You will see this error if no Application Name Property (Properties>>Deployment>>Application Name)was mentioned and you have deployed  In this case the BizTalk artifact installs itself into the default BizTalk Application 1 container or to the application container which is set to default application.


Now if you try to redeploy it to some other container you will see this error reason the assembly is allready present in some other BizTalk container.

Solution : You need to remove this before trying a redeploy. Manual way is to go to “All Artifacts” search for it and remove resource.

Or else a simple way is to just run this in your batch file

BTSTask RemoveResource -ApplicationName:”Your BT Container Where It Got Installed By Mistake”% -Luid:”YOUR ASSEMBLY NAME”

The second approach will come more handy when you are using a build server to create your msi. You may also need to remove the other assemblies which are already using it. Overall not a very pleasant experience and can be avoided by keeping a close eye before you hit the deploy button.

Please leave me a comment in case you have questions.

Working with FLAT files in BizTalk

In this example I will demonstrate how we can use BizTalk capabilities to work with flat files. One thing which is different about flat file when compared to xml files is, it doesn’t have a namespace hence the subscription for these kind of messages is handled in a unique way by BizTalk. However please note once inside the Biztalk server every thing is purely XML, doesn’t matter what format source system did send the message in FLAT, EDI, HL7 ..etc.

So in this example we have an inbound flat file and a receive port will pick it up and from there it will be subscribed by a send port to route it to our desired destination, like all of my previous examples I will be using file type adapter, this will allow users to implement the solution easily.

Step1> Create a new BizTalk project. Add a new schema and use the “Define Record From Flat File instance” to create your schema, I will share the project files soon in case anyone wants to reuse them. We are going to have 2 schemas one for inbound message and other for outbound. We will also use a simple map to concatenate some of the values in the inbound map and create the output message.


Step2>Add a Receive Pipeline and in the drag a “Flat file disassembler” to the disassemble block. In the properties of the Flat file disassembler set your inbound schema against Document Schema property.


The purpose of creating this pipeline component is to use it in the Receive port, when the flat files arrives this pipeline component converts it to XML format for internal usage of BizTalk engine. Note: It not necessary to set the Document schema property, you can also set the DocumentSpecName property manually post deploying in the receive  port. In case you set the Document schema property in your visual studio solution after deploying pipeline the DocumentSpecName will be automatically set.


step3>Create a map which will convert the inbound message to outbound format. I have used a simple map. We are going to use this map at our send port.


Note: We can use an orchestration as well to use this map and implement the same scenario, please refer my previous post : Content Based Routing Using An Orchestration with DirectBound Port

Step 4>Create a send pipeline and at the assemble stage drag the Flat File Assembler control from toolbox.Set up the Document Schema property to your outbound message type. This pipeline component will convert the xml back to flat file format for output.


Step 6>Deploy your visual studio solution

Step 7>Create your physical receive a send port.For receive port in the receive pipeline use your custom pipeline. Same way for send port the send pipeline used should be your custom send pipeline. Also in send port use the map we have created in the solution.

SendPipelineflatPhy RcvPipelinePhysical

Step 8>Start all your ports and restart HIS.

Our solution is ready, when you drop a flat file to your receive location BizTalk should pick it and give you a flat file output at you send location in the outbound message format.

Please let me know if there are any questions.

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

Content Based Routing using a direct bound orchestration

We can achieve the content based routing with orchestration, however like in my previous posts where the input and output message was the same this scenario may get a little tricky.

In this example we will receive an inbound message >> A Receive Port Subscribes to it >> Sends that message to an orchestration >> The orchestration routes it to a send port.

I have used the direct bound port orchestration in my example.

1>Create a receive port

2>Add a new orchestration to your visual studio solution.

In the solution create two schemas for input and output message out of orchestration (This may be little tricky here since we are supposed to route the same message to the outbound location hence the question is, why we are using two separate schemas? >> Explanation : If you have the same message type for both Receive and Send from the orchestration you will end up in infinite loop of same orchestration being triggered multiple times. The reason: orchestration will publish the output in message box, this message should be routed to the send port but instead it will be again subscribed by the orchestration because the message type will be matching the subscription of the orchestration. Hence to avoid this we need to create one more schema having the same structure but will keep a different namespace, hence insuring the output message type is not same  as the input message type.)

This is how our orchestration will look:


Incoming Schema:


OutGoing Schema:


5>Add two maps, one to be used for construction the output message and other to be used in send port for converting the output message from orchestration to map the original input message sent by source system, remember we are supposed to get the same input message at the output.

6>Deploy your orchestration schemas and maps.

7>Create a send port to which the orchestration logical send port would be bound.In this port use the second map which transforms the output message of the orchestration to input type.


8> Bind the orchestration’s logical port to the physical send port, since the logical receive port is directly bound to message box we wouldn’t need an explicit binding for it after deploying the orchestration. However if you wish you can as well use a specify later type of binding for the orchestration logical receive port.

8>Start the orchestration Receive and Send Port and refresh HIS.

Try placing your input file in receive location and you shall be able to see one instance of the orchestration getting triggered successfuly and that on completion will place the output message in your send location.

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

Simple Content Based Routing Using Send Receive Ports in BizTalk

When the routing decision within the BT server are made based on the content of the message it falls under the category of the message based routing


In this example I am taking a sample incoming order message and based on the “State” node value we may need to route to respective locations, for example SendLocationStateTN and SendLocationStateME. Below is the picture of how our invoice schema will look.


Create a schema for incoming order in you BizTalk project.

2>We need to route the message based on the value of ‘State’ node hence we need to ensure this property is written to the context of message. This can be achieved by promoting the ‘State’ node. It can be achieved by right clicking on the desired node to be promoted and pick promote>>quick promotion, you will see following alert from VS

“Visual Studio will create a property schema that contains all your quick promotions. Do you want to add the property schema to your project?”
Go ahead and say yes to it.

3>Now the state value will be available in the filter properties for us to use. Lets create a receive port of file type and define a receive localion in you machine.

4>Create 2 send location to cater to TN and ME state values per the inital requirement.

Apply following filters there in both ports respectively.

BTS.ReceivePortName == ReceiveOrder  And
SimpleRoutingDemo.PropertySchema.State == TN   Note:SimpleRoutingDemo is the name of my BizTalk project in visual studio.


BTS.ReceivePortName == ReceiveOrder  And
SimpleRoutingDemo.PropertySchema.State == ME  

5>It is ready for content based routing . Any xml with state as ME shall go to SendLocationStateME and with  state as TN will go SendLocationStateTN.

This is a very simple example of content based routing using ports only. Please note we can achieve it in multiple ways for example by using orchestrations or ESB. Please let me know if you have any questions

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