How to handle Zombie

I’m glad to present the first release of BizTalk Zombie Management. You can find it at

What is BizTalk Zombie Management ?

This is a codeplex project. It proposes a solution to process zombie message after their zombified state. It’s a windows service that need to be install on each BizTalk machine.
When a zombie is raised, the service catch it and retrieve back the message. Next the message is published for a BizTalk adapter.

Here is the process flow :

When use BizTalk Zombie Management ?

A zombie message is a message that was routed to a running orchestration from the messagebox and was « in flight » when the orchestration ended. An « in flight » message is a message that has been routed to a service instance and so is in a messagebox queue destined for the service instance. Since the message can no longer be consumed by the subscribing orchestration instance, the message is suspended and marked with a ServiceInstance/State value of « Suspended (Non-resumable) ».

A zombie service instance is an instance of an orchestration which has completed while a message that was routed to the orchestration instance from the messagebox was still « in flight ». Since the orchestration instance has ended, it cannot consume the « in flight » messages and so is suspended and marked with a ServiceInstance/State value of « Suspended (Non-resumable) ».

The occurrence of zombies typically falls into one of the following categories:

Terminate control messages – The orchestration engine allows the use of control messages to cancel all currently running work in a specific orchestration instance. Since the control message immediately halts the running orchestration, zombie instances are not unexpected. A number of Human Workflow related designs tend to use this mechanism as well as some other designs.

Parallel listen receives – In this scenario the service instance waits for 1 of n messages and when it receives certain messages it does some work and terminates. If messages are received on a parallel branch just as the service instance is terminating, zombies are created.

Sequential convoys with non-deterministic endpoints – In this scenario, a master orchestration schedule is designed to handle all messages of a certain type in order to meet some type of system design requirement. These design requirements may include ordered delivery, resource dispenser, and batching. For this scenario, the tendency is to define a while loop surrounding a listen with one branch having a receive and the other having a delay shape followed by some construct which sets some variable to indicate that the while loop should stop. This is non-deterministic since the delay could be triggered, but a message could still be delivered. Non-deterministic endpoints like this are prone to generating zombies.

(source : MSDN)

The service cover all case which generate zombie. Warning, this service does not prevent Zombie generation. It only provide a way to avoid loosing data

How does it work ?

BizTalk Zombie Management is C# service which keep an eye on BizTalk WMI table. When a zombie occur a special BizTalk event is generated and catched for processing.

For more information go to the documentation page :


Laisser un commentaire

Choisissez une méthode de connexion pour poster votre commentaire:


Vous commentez à l'aide de votre compte Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )


Connexion à %s