BAM, BizTalk, Monitoring, Performance, Readings

BAM Tracking and Failed Messages, and a new issue of BizTalk HotRod

Mikael Håkansson has a post called How to Replace Tracking with BAM in BizTalk that features a performance comparison he made for disabling global tracking in BizTalk Server 2006 and how that would look if you replaced that with BAM – in hard figures. He also posts a sample solution and talks about concepts such as activities and tracking profiles. The post mentions that the approach is meant for tracking successful messages and he suggests (as an example) the use of a WMI service to catch suspended messages. A concept that he leaves out is the tracking of failed messages using BAM and failed message routing. As a fluke, at roughly the same time his post was published there was a white paper released at MSDN that describes the process of creating an activity, tying that to a tracking profile by connecting it to relevant context properties and deploying it for a failed message routing scenario, see How to Track Failed Messages in BAM. It’s a very basic step-by-step article. Now…I am not taking a stance to say that failed message routing is the way to go. There are many considerations to take into account before determining to opt for that or for allowing messages to get suspended. I just wanted to post this to tie these two articles together since I think they are both good reads and gives you a view of what is required to replace tracking in BizTalk with BAM, for both successful and failed messages. And what the performance benefits might be for your solution.

Also check out the new issue of BizTalk HotRod that (among other things) also discusses Failed Message Routing and how to log these message, but does so in the context of the ESB Guidance.

BAM, BizTalk, Download

BAM Poster available at Microsoft Download

The BizTalk Team announced that a new poster, the BAM poster, will see the light of day. I really like the posters that have been released as companions to the BizTalk Server documentation. I’m not really the graphical guy, at least not when it comes to creating graphics, but that doesn’t stop me from being just as critical as the next guy when it comes to reviewing graphics created by others 😉

For something that is said to “provide an overview of the entire BAM life cycle”, and since it contains other types of data flow, I would have liked to see something about partitioning and archiving. I see that as an important advantage of BAM, to get an thought through process for data handling out of the box. At least, that’s the story I would have added on top of what is in the poster if I would be explaining BAM to someone. Or is that to low level?

BAM, BizTalk

Enabling the BAM Excel Add-In for Excel 2007

Much has changed in the GUI from Office 2003 and earlier version to Office 2007. For many, menu option are hard to locate. This post is meant to be a short pictorial guide to one way of enabling the BizTalk Server 2006 BAM Add-In for Excel 2007. I’ll assume that BAM and Excel are already installed.

What we need to do is to add it to the ribbon so we can access it. We do that by going to More Commands…

This will open the Excel options dialog box and from there you can select Add-Ins. You should see Business Activity Monitoring listed.

Next, select Manage: Excel Add-Ins, and press Go… This will bring up a familiar dialog where you need to check the Business Activity Monitoring Add-In.

Having done this the BAM Add-In will now be accessible through the ribbon and you can edit your BAM Activities and Views.

BAM, BizTalk

Trouble with Excel automation in a non-English locale

Deploying BAM definitions from Excel files means automating Excel. Automating Excel has it’s issues when you work in a multilingual environment, like me. Specifically, when you use a non-English locale for your OS while having an English localized version of Excel installed may cause you to get the exception: 
ERROR: Failed to open BAM Excel workbook file – ‘C:Xxx.xls’.
Old format or invalid type library.

I always use the English versions of applications, and the Office 2007 Suite is no exception. This problem isn’t new, but it’s still with us. According to the KB that deals with this issue there are three possible solutions.

  1. Set the locale in the application doing the automation to English

  2. Set your environments (OS) locale to English

Option one isn’t really an option in this case since it’s bm.exe doing the automation. Option two isn’t really something you’d want in the long run, but it’s ok if you just need it as a temporary workaround during deployment. Option three – getting a language pack is really the preferred one and if you’re a MSDN Subscriber like me, the language packs are just a few clicks away. For the rest of you, sorry, you’ll have to buy them (they are $24.95 at the moment).