SBUG Mini Meeting – Integration Testing with MockingBird – 29th July at 8pm

The SBUG guys are holding their second online mini-meeting on Wednesday 29th July 2009 at 8pm (BST). Santosh Benjamin will be demonstrating the excellent Mocking Bird web-service mocking tool – I’ve been using it for a couple of weeks and I’m a convert; no need to stub our web-methods, just add virtual endpoints to a config and you’re done!

This should only be a 30-45 min meeting and is open to all via Live Meeting. Hope you can join us and see this excellent tool in action.

Full details – including registration – are available on the SBUG Website: http://sbug.org.uk/forums/p/156/232.aspx#232.

VirtualBox 3.0: New Full-Screen Toolbar

Update: The full-screen toolbar can be moved to the top of the screen, which (IMHO) is a much more usable location. To move it to the top of the screen, open the Settings dialog for any VM, select General->Advanced and tick the Mini Toolbar: Show at Top of Screen.

—

It looks as though the VirtualBox Team have added a nice new feature in their 3.0 release – the full-screen toolbar!

When running a VM in full-screen mode, moving your mouse to the bottom of the screen displays the new toolbar, as shown below.

All of the features available when running the VM in windowed mode are now available in full-screen mode, including: mounting devices, shared folders, shutdown options etc. The toolbar can also be pinned open if required.

For those Windows users reading this post, the toolbar behaves just like the Remote Desktop toolbar that is displayed at the top of the screen during a Terminal Services session.

This new feature is only available in the Sun VirtualBox 3.0 release and above. Download it now from VirtualBox.org.

Rogue Service-Windows Created for Response Subscriptions in BizTalk 2006

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.

Wrap-Up

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.