Yesterday I came across an interesting production issue – a service-window that BizTalk Server 2006 had incorrectly created on a response message subscription due to the way it handles daylight savings time.
Background to the Problem
The orchestration in question consumes a third-party web-service via the SOAP adapter. The request had been successfully sent, however the orchestration was dehydrated with the web-service response message in the ‘Queued (scheduled for later delivery)’ state. As described on Technet, this status indicates that the message is waiting to be sent by a send port that has a service window set.
Now that’s strange: the Send Port in question is dynamic, so no chances of an overly enthusiastic BizTalk Admin applying a service window, or a service window being applied in code (you can’t configure a service window on a dynamic port). So how did we get a service window on the response message subscription?
After some digging , I came across Microsoft Hotfix 939797 (http://support.microsoft.com/kb/939797/en-us) which addresses a problem whereby message delivery may be delayed until 11:59 PM in BizTalk Server 2006.
A Bug in the BizTalk 2006 MessageBox Logic?
There appears to be a bug in the BizTalk MessageBox logic which only manifests itself during months where daylight saving time is in effect. To paraphrase the Hotfix: When BizTalk creates a subscription for a request-response message, it converts Universal Time Coordinated (UTC) time to the local time. To do this, it calculates the difference between the current local time and the current UTC time and then adds this value to the service window of the send port. If this operation is delayed for any period of time, the BizTalk engine incorrectly interprets this as a service window and applies it to the response subscription, even though a service window has not been specifically applied on the port.
As a result, the subscription does not activate until 23:59, at which time the response message is rehydrated and the orchestration is allowed to continue. Why 23:59 I don’t know, but looking at the subscriptions table in the BizTalkMsgBoxDb databases, we did in-fact have a rogue service window applied to the response subscription, as shown in the red-box below:
When I checked the next morning, the orchestration had rehydrated and was running; the response message was no longer queued awaiting later delivery, as expected.
This bug may also explain some of the other behaviour we have seen: business processes appear to hang and our Operations Team restart them, but when our Dev’s do further investigations there are no suspended instances as we would expect had there been an error.
If you’re experiencing queued response messages within orchestrations, or rogue service-windows as described above, this Hotfix may resolve your issue. Be aware though that the Hotfix is only to be used on BizTalk Server 2006 – it is included in BizTalk Server 2006 R2 and BizTalk Server 2009 by default.