Geek Answers Handbook

BizTalk - Routing Failure in DSN

Recently, I ran into a very strange problem with delevery notifications. Here is the scenario:

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

  • When a messaging error occurs, the error is delayed by the orchestration (therefore, this means that the delivery notification mechanism worked properly), which performs some registration and then completes programmatically (completion form). The messaging instance still exists and is paused and resumed.

  • After resolving the problem that caused the messaging error, I resume the paused message instance.

At this point, I get two very suspicious messaging instances: a routing failure for the ACK and a message instance is still active (but does nothing ...). I am sure that the instance of the routing error is the delivery notification associated with the instance of the active messages, since they have the same CorrelationToken. One more detail: if I complete the active instance, it pauses (does not resume) and the error message says that the instance was completed without using all of its messages!

And last but not least, I only get this problem in certain environments ...

UPDATE It seems that the problem occurs in the BizTalk blocks that run BizTalk 2006 R2 SP1. This never happened on BizTalk 2006 R2 mailboxes without SP1. I will try to confirm this as soon as possible

UPDATE 2 : it looks like I was right in my last update: the problem occurs after installing Service Pack 1 (SP1) CU1 ... So, the next step: I will try to find if one of the following CU fixes the problem.

+7
source share
1 answer

In fact, CU does not fix the described problem. But there is one more thing: it seems like all new BizTalk versions: I ran tests on BizTalk 2009 with all CUs and BizTalk 2010 with all CUs, the problem still exists !!!

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

In fact, I discovered one more problem when allowing routing for error messages with delivery notifications : AckRequired property And the correlation token is copied to this means that the ACK will be published if this error message is sent by the send port (for example, the send port ESB exceptions) and that this ACK can be redirected to the original orchestration if it is still in progress. If so, it will end with a classic zombie reporting situation as the orchestration does not use this ACK! Now try to explain to your customers that your developers should not be blamed ...: p

+1
source

More articles:


All Articles