The DocumentSpec class in the Microsoft.BizTalk.Component.Interop namespace of the Microsoft.BizTalk.Pipelines assembly is commonly used in custom pipeline components (particularly assemblers in disassemblers) to represent a compiled BizTalk schema (a document specification).

This class has one interesting method: CreateXmlInstance(), which can generate an sample instance XML based on the associated schema [1]. Recently I saw a question in the BizTalkGurus forum about how to use this functionality if you had a schema definition with multiple potential root elements.

Turns out its pretty easy, once you understand how DocumentSpec works and how Schemas are compiled into BizTalk assemblies.

The constructor for the DocumentSpec class takes two arguments: The docSpecName (schema name) and the name of the assembly it is defined in.

The clue to support multi-root schemas is that the docSpecName is, in reality, the namespace + type name of the class generated by the compiler when you compile the Schema into the BizTalk assembly. Each schema becomes one class in the generated code.

If the schema has a single root, that's the end of it; All you need to know is that docSpecName == Namespace.ClassName. If the schema has multiple roots, however, each root becomes a nested class within the schema class.

The way to select which root element to use for the sample instance generation, then, is to provide the type name of the root element nested class as to the DocumentSpec constructor instead of the name of the schema class. In other words, in this case docSpecName == Namespace.SchemaClass+RootClass.

[1] One annoyance of this method is that it takes a TextWriter argument but doesn't actually write the generated XML into it; instead it returns a Stream you need to read!

BizTalk Server 2006

I just pushed all the source code for my BizTalk 2006 PipelineTesting library to GitHub. I'll keep this public repository updated whenever I make any changes to the library, so if you're interested in keeping track of the code or forking it, this should make it a lot easier.

You can find the clone URL for the new repository is: git://github.com/tomasr/pipelinetesting.git

Enjoy!

BizTalk Server 2006, PipelineTesting

Here's a sample PowerShell script/functions to start/stop BizTalk orchestrations. This is an extended version of the Stop-Orchestration VBScript included in the BizTalk 2006 SDK, which I hope someone finds useful .

The script can be used to start or stop either a specific orchestration or a group of orchestrations defined in a BizTalk assembly. For example, to stop and unenlist all orchestrations in a given assembly, you could use this:

Here's the code for the script:

BizTalk Server 2006, PowerShell

... or how automatic formatting of XML files can make you miserable.

During the last few days I've been helping out a client get ready for deploying a BizTalk solution. One of those things this involved was taking the existing BizTalk Binding XML files and making minor edits to them so they would match the new environment.

I did the changes, and the BizTalk Administrator used the updated Binding Files to import them into the new BizTalk Servers. They imported without any errors at all. A couple hours later he noticed some test messages were getting incorrectly routed to the wrong send ports (there's a lot of messaging only stuff in this solution)., so he checked the send port configuration.

There were no filters defined at all! We checked the Binding files again, and yes they were clearly defined there. Why were they not getting imported?

The culprit turned out to be Visual Studio. I had edited the binding files in VS and, for several reasons, this involved doing copy-and-pasting the entire XML content of the binding files between machines. Normally this isn't a problem, but this time it was.

VS will reformat XML content when you paste it into VS. This is usually a welcomed feature, but not now. Turns out that VS reformatted the <Filter> elements of the Send port configurations like this:

See anything weird? I didn't see it either at first. The problem is the line break and extra white space caused by the indentation between the opening <Filter> element and the actual string-encoded XML of the filter expression.

Apparently, BizTalk can't deal with this at all and simply treats it as if the <Filter> element had been empty when it imports the binding file. No warnings, no errors, it simply ignores it silently.

I removed the space leaving it like this:

And now it was imported correctly and all the Filters were recreated successfully. This was maddening to say the least, and it's one of those pesky bugs that can make deploying BizTalk solutions an even more miserable experience than it already is. Definitely a very annoying bug in the Binding importer code.

BizTalk Server 2006, XML

I just uploaded a new update to my PipelineTesting library. This one comes courtesy of Gregory Van de Wiele, who kindly made me aware of a nasty bug: The library wasn't handling schemas with no targetNamespace correctly when adding them to the pipeline context.

Because of this, you needed to specify the documentSpec name as "#root" instead of simply "root". This has now been fixed in this version and I added a new unit test to make sure it doesn't come up again. Thanks a lot Gregory!

As usual you can download the updated code/binaries from here.

BizTalk Server, Testing