Determining the current Service Instance ID

Useful for matching debug info or event info up with whats in HAT. As per this blog entry from Stephen W. Thomas you can get the instance ID in an orchestration with:


OrchestrationInstanceID = System.Convert.ToString(Microsoft.XLANGs.Core.Service.RootService.InstanceId);


You can also have it in an external assembly easily enough. You'll want a reference to:

C:\Program Files\Microsoft BizTalk Server 2004\Microsoft.XLANGs.Engine.dll


public static string GetOrchestrationInstanceID()
{
try
{
return Microsoft.XLANGs.Core.Service.RootService.InstanceId.ToString();
}
catch(Exception exc)
{
return "Exception returning instance ID: " + exc.Message;
}
}


Bug in HAT

There's a bug in HAT that can cause incorrect configuration. In the configuration | Pipelines section where you set tracking options on pipelines, if you reorder the list (ordering by pipeline direction for example) and then step through the list changing options, the changes are not applied correctly. The changes are applied to the list in the original order they're shown, not in the new sort order.

In other words, the config is shown and saved for the items in name order, and sorting the list only changes the view of the list, losing the link between what configuration you're changing and the item that's selected.

Words fail me.

XmlPreProcess - false values are undefined!

The kind of problem that makes you check absolutely everything and declare that it should just work. We have this overly complicated MSI generation process that has two calls to XmlPreProcess in it. Our system test installer was working fine, but our production installer didn't work - an installed config file was coming out with an error message from XmlPreProcess stating that a particular property was not defined. It was. In the end I downloaded the source code for XmlPreProcess and stepped through the property parsing routines and found the following line, deep in a mass of uncommented functions:

if (null != propertyValue &&
!propertyValue.ToUpper().Equals("FALSE"))
{
properties.Add(propertyName, DeQuote(propertyValue));
}


In other words if the property is empty of equal to false, its undefined. WTF? To be fair, it does mention this in the documentation, which of course I hadn't read:

Boolean Properties
All property values are treated as strings with the exception of the word False (case is irrelevant). If you set a property to the value False, it will have the effect of un-defining it. There are some cases where you may actually want the literal value of "False" to be replaced. To accomplish this, enclose it in single or double quotes. The quotes will be stripped, and the value will simply be treated like any other string property.

This is the kind of undisclosed "feature" that drives me insane. Just like the "helper" function we had on our project that read an XML element value at an XPath - if it didn't find it it returned a blank string. Cue another baffling bug (null is not equal to false!). If you're going to write this kind of garbage, call the function "ReadXMLAtXPathAndReturnBlankIfItDoesntExist". And no, putting the info in the <Remarks> tag does not count.

Actually, writing APIs with this kind of stuff in it reminds me of this bit from HHGTTG:

Shortly before the Vogons demolish the Earth to make way for a hyperspace bypass, they inform the planet that "All the planning charts and demolition orders have been on display in your local planning department on Alpha Centauri for fifty of your Earth years, so you've had plenty of time to lodge any formal complaint and it's far too late to start making a fuss about it now." When someone objects to this, Protstetnic Vogon Jeltz replies, "What do you mean you've never been to Alpha Centauri? For heaven's sake mankind, it's only four light years away you know. I'm sorry, but if you can't be bothered to take an interest in local affairs that's your own lookout."