Geeks With Blogs
Simon Emmanuel RIVAS

This is a detailed explanation of a something I posted a few month ago on stackoverflow, concerning a weird behavior (a bug, in my opinion? I'd be happy to to read your opinions) of the delivery notifications in BizTalk.

Reminder: what are delivery notifications

Mechanism

BizTalk has the ability to automatically publish positive acknowledgments (ACK) when it has succeeded transmitting a message or negative acknowledgments (NACK) in case of a transmission failure. Orchestrations can use delivery notifications to subscribe to those ACKs and NACKs in order to know if a message sent on a one-way send port has been successfully transmitted.

Delivery Notifications can be “activated” in two ways:

  • The most common and easy way is to set the Delivery Notification property of a logical send port (in the orchestration designer) to Transmitted:

clip_image002

  • Another way is to set the BTS.AckRequired context property of the message to be sent to true:

clip_image004

NOTE: fundamentally, those methods are strictly equivalent since the fact of setting the Delivery Notification to Transmitted on the send port only tells BizTalk the BTS.AckRequired context property has to be set to true on the outgoing message.

Related context properties

ACKs and NACKs have a common set of propoted context properties, which are :

Property

Description

AckType

Equals ACK when successful or NACK otherwise

AckID

MessageID of the message concerned by the acknowledgment

AckOwnerID

InstanceID of the instance associated with the acknowledgment

AckSendPortID

ID of the send port

AckSendPortName

Name of the send port

AckOutboundTransportLocation

URI of the send port

AckReceivePortID

ID of the port the message came from

AckReceivePortName

Name of the port the message came from

AckInboundTransportLocation

URI of the port the message came from

Detailed behavior

The way Delivery Notifications are handled by BizTalk is peculiar compared to the standard behavior of the Message Box: if no active subscription exists for the acknowledgment, it is simply discarded. The direct consequence of this is that there can be no routing failure for an acknowledgment, and an acknowledgment cannot be suspended.

Moreover, when a message is sent to a send port where Delivery Notification = Transmitted, a correlation set is initialized and a correlation token is attached to the message (Context property: CorrelationToken). This correlation token will also be attached to the acknowledgment. So when the acknowledgment is issued, it is automatically routed to the source orchestration.

Finally, when a NACK is received by the source orchestration, a DeliveryFailureException is thrown, which can be caught in Catch section.

Context of the problem

Consider this scenario:

  • In an orchestration, Delivery Notifications are activated on a One-Way send port
  • In case of a transmission failure, the messaging instance is suspended and the orchestration catches an exception (DeliveryFailureException).
  • When the exception is caught, the orchestration does some logging and then terminates (thanks to a Terminate shape).

So that leaves only the suspended messaging instance, waiting to be resumed.

Symptoms

Once the problem that caused the transmission failure is solved, the messaging instance is resumed. Considering what was said in the reminder, we would expect the instance to complete, leaving no active or suspended instance.

Nevertheless, the result is that the messaging instance is once more suspended, this time because of a routing failure:

clip_image002[7]

The routing failure report shows that the suspended message has the following attached properties:

clip_image004[7]

Explanation

Those properties clearly indicate that the message being suspended is an acknowledgment (ACK in this case), which was published in the message box and was supended because no subscribers were found.

This makes sense, since the source orchestration was terminated before we resumed the messaging instance. So its subscription to the acknowledgments was no longer active when the ACK was published, which explains the routing failure.

But this behavior is in direct contradiction with what was said earlier: an acknowledgment must be discarded when no subscriber is found and therefore should not be suspended.

Cause

It is indeed an outright bug, which appeared with the SP1 of BizTalk 2006 R2 and was never corrected since then: not in the next 4 CUs, not in BizTalk 2009, not in 2010 and not event in 2013 – though I haven’t tested CU1 and CU2 for this last edition, but I bet there is nothing to be expected from those CUs (on this particular point).

Side effects

This bug can have pretty nasty side effects: this behavior can be propagated to other ports, due to routing mechanisms.

For instance: you have configured the ESB Toolkit and have activated the “Enable routing failure for failed messages”. The result will be that the ESB Exception SQL send port will also try and publish ACKs or NACKs concerning its own messaging instances. In itself, this is already messy, but remember that those acknowledgments will also have the source correlation token attached to them… See how far it goes?

Well, actually there is more: in SQL send ports, transactions will be rolled back because of the routing failure (I guess it also happens with other adapters - like Oracle, but I haven’t tested them). Again, think of what happens when the send port is the ESB Exception send port: your BizTalk box is going mad, but you have no idea since no exception can be written in the exception database!

All of this can be tricky to diagnose, I can tell you that…

Solution

There is no real solution, only a work-around, but it won’t solve all of the problems and side effects. The idea is to create an orchestration which subscribes to all acknowledgments. That is to say:

  • The message type of the incoming message will be XmlDocument
  • The BTS.AckType property exists
  • The logical receive port will use direct binding

By doing so, all acknowledgments will be consumed by an instance of this orchestration, thus avoiding the routing failure. Here is an example of what this orchestration could look like:

clip_image002[9]

In order not to pollute the HAT and the DTA Db (after all, this orchestration is only meant to be a palliative to some faulty internal BizTalk mechanism, so there should be no trace of its execution), all tracking must be deactivated:

clip_image002[11]

Posted on Monday, November 11, 2013 4:00 PM BizTalk , routing failure , delivery notification , bug | Back to top


Comments on this post: BizTalk – Routing failure on Delivery Notifications (BizTalk 2006 R2 to 2013)

# re: BizTalk – Routing failure on Delivery Notifications (BizTalk 2006 R2 to 2013)
Requesting Gravatar...
Use Scope on that Oneway Sendport solved the problem. Donot put any Timeout for Longrunning Scope
Left by Sandeep on May 15, 2014 5:12 PM

# re: BizTalk – Routing failure on Delivery Notifications (BizTalk 2006 R2 to 2013)
Requesting Gravatar...
You mean a second scope, nested in the one used for catching the DeliveryFailureException?? Seems a bit odd to me, but I'll give it a try...
Left by Simon on Jul 11, 2014 9:53 AM

# re: BizTalk – Routing failure on Delivery Notifications (BizTalk 2006 R2 to 2013)
Requesting Gravatar...
I'm facing the same issue, but with one particular case.

After the DeliveryException throwned I have a suspend shape and wait user action to solve the probem in Send Port.
After the problem is solved (orchestration still exists) and start the send the port and also get the Routing failure problem.

I've done what you wrote here, but I'm a little concern with performance and biztalk healthy.

Did you manage to solve this in another way? Or any other advice?

Ah, also tried the "second shape", but didn't work

thanks,
Left by Ric bessa on Jan 14, 2015 7:14 PM

# re: BizTalk – Routing failure on Delivery Notifications (BizTalk 2006 R2 to 2013)
Requesting Gravatar...
Hello Ric,

No, I haven't found another way of solving it, and yes for a time I was a little concerned about performances too.
But I think the resource consumption overhead is minimal if you deactivate all tracking on this new orchestration - this "patch" is deployed on some production environments I know, without any significant difference in performance.

Moreover, if you really need those delivery notifications, the problem is simple : wether you take the risk of lower performances (but that can be measured with proper testing, and certainly managed by fine tuning your hosts), or you accept that your BizTalk box will potentially behave in a funny way!
Left by Simon on Jan 26, 2015 3:01 PM

# re: BizTalk – Routing failure on Delivery Notifications (BizTalk 2006 R2 to 2013)
Requesting Gravatar...
Thanks for the post. I wrote this post http://kentweare.blogspot.ca/2007/11/biztalk-delivery-notification.html several years ago and have not had to build a Delivery Notification interface in a long time. Was very surprised with the routing errors that I was getting until I ran across this post. I will send a note off to Microsoft to see what I get back as Delivery Notification is "broken" right now IMO
Left by Kent Weare on Feb 11, 2015 10:50 PM

# re: BizTalk – Routing failure on Delivery Notifications (BizTalk 2006 R2 to 2013)
Requesting Gravatar...
You're welcome Kent.
Please do keep me informed about what Microsoft thinks of this issue!
Left by Simon on Feb 12, 2015 9:50 AM

Your comment:
 (will show your gravatar)


Copyright © S.E.R. | Powered by: GeeksWithBlogs.net