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 Sequential Convoys.

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

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

Schema

Here is the Schema used for this which contains a promoted field StudentID, which will be used for correlation.


Orchestration

The Orchestration contains simple sequential convoy which receives the messages and send those messages out into a folder. There is delay of 2 minutes in the loop shape and after all the messages are received then again I have applied an delay shape (2 minutes) so that a message is dropped after the Orchestration has run beyond the second receive shape.

Sample Files

The below sample files contains same correlation ID i.e. StudentID so that these messages could be correlated to a single instance of the Orchestration.

Message 1 :

Message 2 :


Message 3 :
Message 4 :

Working of the Solution

Suppose the first sample file is dropped then this file will initialize the correlation set and will fire up a new instance of the Orchestration. The Orchestration will now become dehydrated and will wait for any further event like receiving of the new message or the delay going off. Now if I drop the rest of the files then these files would be subscribed by the second receive shape which is following the correlation set and is in the loop shape. So this receive shape would subscribe to all the messages that will be coming after the first message. Now if the messages are not coming for 2-3 minutes and an delay of 2 minutes is applied in the delay shape inside the loop shape then what would happen ? The right branch of the listen shape will get executed and the loop would break and now the execution would come to the delay shape which is outside the scope shape. Now I have applied an delay of 5 minutes just to create zombie message. Consider this delay as any processing logic that could be there in the real world scenarios. Now if I'll drop an message then this message will become an zombie message and after the completion of the delay shape our Orchestration would get suspended and error message will be like this:

Cases

Lets create some cases which could occur while working with Sequential convoy :

Case 1 : When message 1 is dropped and then message 2 is dropped.
-> When message 1 is dropped a new instance of Orchestration fires up and a correlation set is initialized on first receive shape and when message 2 is dropped then this will also be consumed by this instance as both have same correlation set i.e. StudentID = 1.  After dropping message 2 no further message is dropped. Now since I have applied delay of 2 minutes on the delay shape, so after 2 minutes the process will come to the right branch of the listen shape and the process will come out of the loop shape and again will come to the delay shape at the end of the Orchestration. Now after 2 minutes the process will end successfully.

Case 2 : When message 1 is dropped then message 2 and then again message 1 is dropped.
->
This will work fine and no zombie would be created and we would get output in the folder.

Case 3 : When message 1 is dropped then message 2 and after delay of 2 minutes message 3 is dropped.
-> This will create the  message 3 a zombie message as the Orchestration is running beyond the receive shape i.e. the instance subscription of the second receive shape is finished. The process would be in 2nd delay shape so this would create an zombie.

Case 4 : When message 1 is dropped then message 2 then after 2 minutes message 3 and then message 4
-> In this case message 3 will become zombie i.e. same as Case 3 but the message 4 would fire a new instance of an Orchestration. Message 4 would create an new instance of an Orchestration because it contains a new correlation set i.e. StudentID = 2

Zombie Zone


The red line depicts the zombie zone where the Orchestration is running beyond the second receive shape (instance subscription)and if any message with the same correlation set comes, will become an zombie message.

Resolutions

Well to be very frank there is no specific resolution to the Zombie message problem but having said that zombies could be minimized. Following are the two points :

  1. By increasing the time of the delay shape in the loop shape. This will impose an maximum window in which messages could come.
  2. By separating the zombie zone logic to some other Orchestration. We could create an separate Orchestration for the processing logic present in zombie zone. But this resolution will work in some specific business scenarios. Something like below :

We have separated the processing logic in separate orchestration and used Start Orchestration shape to call it. But this is purely upon requirement, some cases could not cater to use Start Orchestration like this.

See Also

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