“You are making my point!”

In the BizTalk Pipeline component, often times you need to construct new messages out of the received messages in the Disassemble stage before passing them on to the orchestration. This can be done in a few different ways.

The easiest way is to build a concatenated XML string using StringBuilder or something similar, and load it into a new XmlDocument object. However, this is very inflexible. If the structure of the message is changed, the Pipeline component would have to be recompiled and redeployed. Another approach will be to load the XML strings from a configuration file at runtime, or keep it as a separate resource file to be loaded at the runtime. This approach avoids the recompilation process when the XML structure is changed, but you still have to worry about keeping the external XML file in sync with the actual BizTalk schema file.

What if you can programmatically create an XML document based on the your XML schema? Or even better, what if you can use the schema that is validated and compiled by BizTalk and stored in the BizTalk management database? This way you don’t have to worry about manually keeping the schema and the external XML file in synch since there is no external XML file any more. Any change you make in the schema is directly reflected in the Pipeline component when you build your new message. Well, it turns out that there is an undocumented API called “CreateXmlInstance” just for that. Here is the code snippet that does this.

public XmlDocument CreateBTDoc(string schemaName)
{
    XmlDocument doc = new XmlDocument();
    BtsCatalogExplorer explorer = new BtsCatalogExplorer();

    explorer.ConnectionString = @”Integrated Security=SSPI; Server=localhost\SQL2005; Database=BizTalkMgmtDb;”;
    Schema schema = explorer.Schemas[schemaName];

    if (schema != null)
    {
        DocumentSpec spec = new DocumentSpec(schemaName, schema.BtsAssembly.DisplayName);
        StringWriter sw = new StringWriter(new StringBuilder());
        doc.Load(spec.CreateXmlInstance(sw));
        sw.Dispose();
    }
    return doc;
}
Essentially this code would go directly to the BizTalk management database, find the specified schema, and then create an empty XML document based on the schema. To use this code, you need to add references to Microsoft.BizTalk.ExplorerOM and Microsoft.BizTalk.Pipeline assemblies. Your using statements should include Microsoft.BizTalk.Component.Interop and Microsoft.BizTalk.ExplorerOM.

From here on, you can programmatically populate/manipulate the XML element/attribute values as needed. One thing to note is that this code is not entirely immune to changes either. If you add new elements/attributes to your schema (which is the case for most situations), the code will be fine since it simply creates blank values for the new fields. However, if you remove some elements/attributes, or make changes to existing elements/attributes, and if your subsequent processing code access them, you will have to modify the code to accommodate the changes.

BizTalk Orchestration Designer is the core tool for laying out components representing business processes, and connecting them with logic operations when designing BizTalk applications in Visual Studio. Behind the scene, the XLANG compiler actually generates C# source code before compiling it into .NET assemblies. If you ever want to look under the hood and view the C# source, here is a little trick.

Use your favoriate registry editor (I simply use RegEdit.exe), go to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0. This is where some key properties of Visual Studio 2005 IDE are stored. Add a DWORD value named “GenerateCSFiles”, and set the value to 1.

Next time you launch Visual Studio to open a BizTalk project with orchestration files (.odx file) in it, click on the “Show All Files” icon in the Solution Explorer after the project is built. You will see along side with your abc.odx file, there appears an abc.cs file. This is the C# source code generated by XLANG out of your orchestration. You can open the file and view all the code, assuming the compilation succeeded (otherwise the cs file is blank). You will notice all your orchestraction artifacts are actually translated into one big chunk of XML embedded in the C# code.

I have always been a fan of ISNULL. Recently a boring (not to mention unpleasant) task of updating someone else’s stored procedures fell onto my lap. The original developer used COALESCE extensively through out the code. Half way through my search and replace, I started thinking, maybe I should performance-test these two techinques. I am not exactly sure how the internals of these two work, but it must be some kind of variation of CASE WHEN statements. And I have an inkling that ISNULL will be faster. It doesn’t spell easier for nothing!

Of course these days before you actually do anything, you always GOOGLE first. Surprise! A search on “ISNULL vs. COALESCE” turns out 800 entries. Adam Machanic’s post was the most interesting one. But the general consensus is that ISNULL is 10-20% faster than COALESCE. So my suspicion is correct. However, Adam’s beef with ISNULL is that it is doesn’t comform with ANSI SQL standard. It is ture, however these scripts that I am dealing with will not be ported to any non-SQL Server database in a million years. So ISNULL is the obvious winner here.

“Replace All?” 

“Yes!”