Share via

BizTalk Server: Zombie Messages in Parallel Convoy

  • Article

What are Zombies?

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

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

First of all below are the conditions in which could create scenarios where Zombies messages 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:

http://1.bp.blogspot.com/-xLfW2vFdRTE/U_9vRhdq14I/AAAAAAAAAbk/29DxNc7wVGk/s1600/Orchestration.png

In this Orchestration I have used Parallel convoy which accepts two types of Messages i.e. Customer and Order. I have created a 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

http://2.bp.blogspot.com/-YtgupT3TRss/U_9wkrbQ_4I/AAAAAAAAAbs/17PM15P4PlY/s1600/Customer.png

Order

http://3.bp.blogspot.com/-rkEf6L-f3Ks/U_9xApCSK-I/AAAAAAAAAb0/dtFmSS9f-eI/s1600/Order.png

Property Schema

http://3.bp.blogspot.com/-I7ndmFHG9qM/U_9xKTi_RuI/AAAAAAAAAb8/0kVcsGxnwqM/s1600/PropertySchema.png

Output Schema

http://1.bp.blogspot.com/-3L0wf9exTbQ/U_9xVhQJWKI/AAAAAAAAAcE/cZmIlXHZXbY/s1600/Output.png

After building, deploying and configuring the project, let's start dropping the messages at Receive location:

Cases

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 a Zombie message with following error:

http://2.bp.blogspot.com/-RL6CVbG3ThM/U_93Kd5BzrI/AAAAAAAAAcM/_YOOGQLSOt8/s1600/Error.png

http://2.bp.blogspot.com/-PVZ5iBwKWAs/U_93MndflvI/AAAAAAAAAcU/U7DOqPkTsIQ/s1600/Error_2.png

Conclusion

In a 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 a 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.

Source Code

Sample  code of this project can be found here on Technet Wiki Gallery

See Also

Another important place to find an extensive amount of BizTalk related articles is the TechNet Wiki itself. The best entry point isBizTalk Server Resources on the TechNet Wiki.