Yossi Dahan [BizTalk]


Monday, August 11, 2008


A lot has been written about Zombies in BizTalk, but somehow they never really caused me too much problem. until today.

In one of our processes we are calling a web service to perform a certain lookup.

That web service’s implementation (whether correct or not) is to return the instance of the class if found or null otherwise.

When the service returns a null BizTalk receives an empty message, which triggers an exception in the process -

Microsoft.XLANGs.Core.MissingPartException: The XLANG/s message has no part at index '0'. The total number of parts found in the message is '0'. If you expect a multipart message, check that the pipeline supports multipart messages such as MIME.

I’m quite all right with that, BizTalk is definitely correct – we have returned an empty stream as a message which means nothing.

And so - we've added an exception handler around the call to the service and our orchestration’s flow carries on correctly all the way to the end shape. as expected.

However, contrary to the expected at this point the orchestration instance gets suspended by BizTalk with the error - “The instance completed without consuming all of its messages. The instance and its unconsumed messages have been suspended.”

I believe this behaviour has been introduced in BizTalk 2006 - 2004 was quite “happy” to have the so called "zombies" in the process, and it was up to the developer to handle those (or not, as the case often was); since 2006 this had become an error and if a process ends with unconsumed messages the process gets suspended and the unconsumed messages are available for inspection.

Generally, I think that making a zombie an explicit error is a good idea, although it would have been nice to be able to set whether this behaviour is required on a per-process basis, however - in our case we found this very problematic - we were in a position where we couldn't consume the message properly (due to the exception handler) but although we have handled the exception we ended up with a suspended in stance as it appeared as a zombie. we could not win.

I have opened a support call on this one, waiting to hear if the product group agrees that this is incorrect behaviour or not (I seem to be getting conflicting thoughts). I'll try to keep this post updated when I get an answer.

Update: I've been exchanging quite a few emails with the product group on this one, but have not (yet) managed to convince them that this cannot possibly be the expected behaviour - I should be able to handle the exception and carry on without having a suspended instance; they think otherwise.

(You can read more details about this here - http://technet.microsoft.com/en-us/library/bb203853.aspx and http://blogs.msdn.com/biztalk_core_engine/archive/2004/06/30/169430.aspx

An interesting point is that this case is not listed in the list of causes for zombies in these articles, which makes me wonder – should an exception raised through a receive shape, which was properly handled by an exception handling result in a zombie?)

Labels: , , , ,


  • Hi Yossi,

    I think we encountered the same situation as you. What we did was to have our orchestration have an error handler to do what it does, but we also enabled routing errors on the send port and created a subscription which would pick up any of these errors and just log to the event log that it had cleaned up this message.

    Its a bit of a pain I completely agree but this work around did the job for us

    By Anonymous Anonymous, at 16/08/2008, 19:55  

  • Yes, that's what we're looking at doing, the problem is that you have to be very careful in the orchestration you use to "handle" the errors - you don't want to ignore any other failures, and you losse the native ability to retry on the other "real" errors.

    By Blogger Yossi Dahan, at 16/08/2008, 20:21  

  • Enable routing for failed messages can also cause zombies, if you use delivery notification in synchronized scopes.

    By Blogger Unknown, at 18/02/2010, 13:11  

Post a comment

<< Home