BizTalk - Routing failure on a delivery notification

Question

I've run into a very weird issue with delevery notifications lately. Here is the scenario :

• I have an orchestration which sends a message to a one-way send-port configured with delivery notification = Transmitted (btw the send port uses the FTP adapter, but I think it doesn't matter what the adapter is).

• When there is a messaging error, the error is trapped by the orchestration (therefore meaning that the delivery notification mechanism worked as expected), which does some logging and then terminates programatically (Terminate shape). The messaging instance still exists and is suspended and resumable.

• After solving the problem that caused the messaging error, I resume the suspended messaging instance.

At this point I get 2 very suspicious messaging instances : a routing failure for the ACK and the messaging instance still active (but doing nothing...). I am sure that the routing failure instance is the delivery notification related to the active messaging instance since they have the same CorrelationToken. One more detail : if I terminate the active instance, it gets suspended (not resumable), and the error message says that the instance completed without consuming all of its messages!

Last but not least, I get this problem only on certain environments...

UPDATE : It seems like the problem appears on BizTalk boxes that run BizTalk 2006 R2 SP1. It never occured on the boxes that run BizTalk 2006 R2 without SP1. I'll try and confirm this ASAP

UPDATE 2 : It appears I was right in my last update : the problem appears after installing SP1 CU1... So next step : I will try and find if one of the following CUs corrects the problem.

Answer 1

Actually no CU corrects the described problem. But there is more : it seems like all the newer BizTalk versions are concerned : I have made tests on BizTalk 2009 with all CUs and BizTalk 2010 with all CUs, the problem still exists!!!

The only solution I have found was to create an orchestration that subscribes to all Delivery Notifications... Not very clean, but it does the job - well at least most of it.

As a matter of fact I have identified 1 more problem when you enable routing for failed messages with delivery notifications : the AckRequired property AND the correlation token are copied to the routed failed message, which means that an ACK will be published if this failed message is consumed by a send port (eg : the ESB exception send port), and that this ACK can be routed to the originating orchestration if it is still executing. If so, that will end in a classic zombie message situation, since the orchestration doesn't consume this ACK! Now, try and explain to your clients that your devs are not to be blamed... :p