Thursday, August 28, 2014

Zombie messages in Parallel Convoy

What are Zombies ?

Zombie messages are those messages which are consumed by the BizTalk server but are not routed to any subscribers. Zombies do not occur for Activating receive shape and they occur mostly in convoy patterns. In this post I am going to show how zombies occur in Parallel Convoys. 

I'll not be talking about Parallel Convoy in this post. For details on parallel convoy click here.

Lets start our Zombie tour :)

First of all below are the conditions in which Zombies occur :
1. Orchestration instance is running beyond the Receive shape.
2. Orchestration has stopped execution before the message was delivered to Orchestration.
3. A message with same correlation set is received more than once (To be demonstrated in this article)

Here's the look of the Orchestration that I have used :

In this Orchestration I have used Parallel convoy which accepts two types of Messages i.e. Customer and Order. I have created an Correlation type CustomerID field present in both the Input schemas.

Following are the Input Customer and Order schema's and also the Output schema and Property schema.

Customer :

Order :

Property Schema :

Output Schema :

After building, deploying and configuring the project, lets start dropping the messages at Receive location :

CASE 1 : A single Customer file(with CustomerID = 1) is dropped and after some time a single Order file(with CustomerID = 1) is dropped
RESULT : Firstly an Orchestration instance fires up and is dehydrated waiting for Order file, after Order file is dropped and Output file is created.

CASE 2: Ten customer files(CustomerID from 1-10) is dropped and after some time ten Order files(CustomerID from 1-10) are dropped.
RESULT : Firstly 10 Orchestration instances are fired up and are dehydrated waiting for Order files. When order files are dropped, Ten output files are created.

CASE 3: Ten Customer files (CustomerID from 1-10) are dropped and after some time a single Customer file (with CustomerID=1) is dropped and after some time Order message (with CustomerID=1) is dropped.
RESULT : Firstly 10 Orchestration instances are fired up, now after dropping again a Customer file with CustomerID=1, no new Instance is fired up.The existing instance with CustomerID=1 consumes this message. Now when I dropped the Order Message with CustomerID = 1 the first message with CustomerID=1 gets completed and the Output file is generated but  the second message is not consumed and thus it becomes an Zombie message with following error :

Bottom Line : In an Parallel convoy a correlation set can only be initialized only once at a time i.e. subscription should be unique. If we try to initialize correlation set with value already in use BizTalk will create an Zombie message.

Note : The condition demonstrated in this article is only one case in which Zombies can occur in Parallel Convoy. There are other conditions also like a branch of Parallel convoy gets terminated while others are awaiting messages.

Tuesday, July 15, 2014

Different methods of property promotion inside Orchestration

What is Property Promotion ?

Property promotion is a core concept in BizTalk which is used for subscription. Basically property promotion writes that particular property's value into the context of the message and also promotes it.

Now there can me many ways to do Property Promotion inside BizTalk Architecture. I have come across three ways to do it. If you guys find out more, do tell me !!!!!

1. Promotion using Schema :

This is pretty simple and every BizTalk developer (New or Experience) must be aware of it. Using Quick promotion will create an Property Schema automatically with the property ID in it.

2. Promotion using Custom Pipeline component :

Properties can be promoted using Custom Pipeline component using a simple one liner .NET code i.e.

// Promote the MessageType property

string messageType = “http://” + “” + “#” + “Request”;
message.Context.Promote(“MessageType”, BTSSystemPropertiesNamespace, messageType);

The Promote() method is used to write the property value into the message context but also sets the property as promoted so that it is available for routing. 

3. Promotion using Correlation (Initializing an correlation set):

We all know we need Correlation set and correlation type inside the Orchestration to create correlation. Correlation set is based on correlation type which is set of properties with some values. When we Initialize a correlation set automatically these properties are promoted in the context of that message. Well one more thing you don't need to follow the correlation set in case you just want to promote the properties. Initializing correlation set won't create an subscription it will just promote the property.

Lets see how to do it :

1. Creating a property schema with the desired property to be promoted

Note: Change its Property Schema Base to MessageContextPropertyBase. By doing this we are creating a custom property to flow with the message context.

2.  Create an simple Orchestration which will receive a message transform it into other message and send the message to File folder.

3. Now create a correlation type selecting the ID property that was created in Property Schema.

4. Create an correlation set using the above created correlation set and Initialize that set on the send shape.

5. Other thing to note here is that we need to initialize this property in order to use it further for promotion, so I have just assigned an value to this ID property inside an message assignment shape.

6. Finally after building, deploying , configuring this application and dropping an sample file at receive location we get the desired output i.e. ID field getting promoted. :)