Developing custom tools for BizTalk

For the last four months I’ve been developing a benchmarking tool for BizTalk which is going to be released soon. However, I thought I’d share some of the pain you might run into while developing custom tooling for BizTalk.

The problem lies with communicating with BizTalk, where you’re pretty much left with two options; Microsoft.BizTalk.ExplorerOM (EOM) or WMI. First of all, each option is suitable for different purposes. If you want to manage ports and applications, ExplorerOM would be your best bet, where as if you’d like to manage hosts, host instances or handlers, WMI would be your only option.

The problem I ran into, is that neither one of these works if you are not running this from a BizTalk Server, which in some cases is not preferred.

The problem occurs where the user tries to start a port from the custom application and therefore needs to commit using the SaveChanges operation (EOM). In the worst scenario, the user is running the app from a server/desktop where BizTalk is not installed. BizTalk and SQL are installed on separate boxes.

Using EOM won’t work as it throws an “Object reference not set to an instance of an object” exception (see code below). This is because EOM require BizTalk to be installed on the same box, even though it doesn’t necessarily need to be part of the group you’re trying to connect to.   

static void Main(string[] args)
{
    Console.WriteLine("Server name?");
    string server = Console.ReadLine();

    BtsCatalogExplorer explorer = new BtsCatalogExplorer();
    explorer.ConnectionString = new SqlConnectionStringBuilder()
    {
        DataSource = server,
        InitialCatalog = "BizTalkMgmtDb",
        IntegratedSecurity = true
    }.ConnectionString;

    Console.WriteLine("Connected..."); // This works!

    try
    {
        explorer.SaveChanges(); // This fails!
        Console.WriteLine("SaveChanges were executed without exceptions.");
    }
    catch (Exception ex)
    {
        Console.WriteLine("An error occurd...");
        Console.WriteLine(ex.Message);
    }
    Console.WriteLine("\nPress any key to close...");
    Console.ReadKey();
}

Using WMI won’t work because of the  “double-hop authentication issue”, where credentials will be lost on the second jump (to SQL). This will result in a “Anonymous user does not have access blah blah blah” – SQL exception. http://www.microsoft.com/technet/scriptcenter/resources/wmifaq.mspx#EXLAC

I’d really like to see the product team to ship BizTalk with a Management Application, exposing services for the most common tasks.