sfeldman.NET

I was writing a custom component to copy message parts of an untyped message, invoked from orchestration. This message was created in a custom pipeline, and body part name had to have “Body”. For some bizarre reason, when message body part is handled outside of orchestration and passed into .NET code as XLANGMessage, body part name is “part”. ??? The other parts have the original names. I have no idea why this is happening, but thought it could save someone a question or two, especially when writing tests and expecting that the name of the part is “Body”.

Sometimes you have to get to the lower level of debugging (ie debugging auto-generated code) to understand what happens. This is what you can do to achieve it in BizTalk.

Link 1 (Auto-generated code)

Link 2 (MMC)

For the project I work on, processing involves multiple files. Files are packaged in a ZIP archive and it’s BizTalk application that opens the archive and builds a message for processing. In BizTalk terminology, this is a multi-part message.

Interestingly, if you search for more information, mostly you’ll find how to receive a MIME message that is already multi-part message (i.e. BizTalk can already handle it) or how to do it with Orchestration, by defining a contract (schema) of the multi-part message. But what if you want to construct your multi-part message within a pipeline? And what if you don’t know how many parts you have?

In my scenario a message is defined as a document with any number of attachments. Document becomes the body part, attachments become additional message parts. So far quite simple. Except that there’s a catch – order of parts at creation time of a multi-part message matters. It is not enough to mart the body part with a boolean flag to indicate that that’s a body part, you also have to insert the body part first, and only after that any additional parts. If that’s not happening, BizTalk throws a nice WrongBodyPartException exception.

From the API point of view, this is a little bit of a smell, since you expect the engine to be smart enough to read first the part that is marked as a body (why would you mark it as a body then). The doubt that I’ll give it is that I am not fully aware how internals are working. So hopefully this will save someone time and efforts of troubleshooting an issue like this.

For the project I wanted to document it, and again, the best way to document it was tests. First I needed the test to fail to verify the expected issue. Once custom pipeline component was fixed, the test passed, and documentation is a living and breathing code. And code doesn’t lie.

I have posted before about Bizmonade testing library for BizTalk orchestrations testing. Unfortunately, there’s something something that looks like a limitation – testing orchestrations that receive any document type (System.Xml.XmlDocument). I posted a question on StackOverflow and curious to see if get anything at all. How do you test your general schema orchestrations?

Update 2010-07-08: I'm in contact with the main developer of Bizmonade, and he'll be releasing soon an updated version that will allow scenario I am looking for. 

Working with BizTalk pushes the creativity sometimes. This time around, I needed to have an assembly deployed to GAC (so that BizTalk application can easily use it) and at the same time being able to configure this assembly without re-deploying it to GAC again.

Normally, an assembly has a configuration file (.config) that is bundled with assembly and serve as it name indicates. With GAC it’s different. Regardless of method of deployment into GAC, it only accepts an assembly file, nothing else. This is where shared knowledge and creativity kick in.

How assembly is actually deployed?

GAC is file based structure typically located at %windir%\assembly. If you type the location in Explorer, this is how it looks like:

You can’t drill in, unless you specify another path that exposes GAC as file system, %windir%\assembly\gac_msil. This opens the actual file structure of GAC, which is structured very logically.

Assume you have deployed an assembly called zUtility with version 1.0.0.0. Once this assembly is deployed into GAC, a folder is created with named as the assembly, and inside another sub-folder, named accordingly as the version and public key token of the assembly. Inside that folder zUtility assembly is found. This way GAC can contain multiple versions of the same assembly.

This should technically allow us to drop the configuration file and have it loaded by assembly once it’s used. But no, it’s not working that way. Even without GAC, a satellite assembly is always using configuration file of the main assembly. It would be nice if it was using it’s own configuration file first, but it doesn’t. Either way, back to our case. Solution for this problem would be to “force” reading of configuration file through custom code.

Executing assembly location is full path and name of zUtility.dll. Appended to that .config gives us the configuration file full path and name. The rest is usual.

Now BizTalk can reference a fully configurable assembly deployed to GAC without being redeployed every single time we need to update a connection string, or a URL or some constant value. Hard-coding is bad, so avoid it.

Bizmonade is a project allowing to simulate execution of BizTalk orchestrations without deployment to BizTalk server. What is it good for? Testing. Unit testing. The fact that the logic can be tested without deployment hassle is good. There are a few issues that I have encountered so far, and my experience with the particular tool is less than 24 hours (so excuse me in case I am not accurate – corrections are welcomed always):

1. You have to use orchestrations that subscribe to a specific schema message. What if I subscribe on any message (System.Xml.XmlDocument) based on receiving port? No documentation on that, neither clear if it’s possible from the samples.
2. Default configuration/documentation assumes Bizmonade is GAC-ed. Personally, I don’t like that. For Continuous Integration scenario it is better to be self-contained with-in a project. Good news is that you can do it easily.
3. Lack of API documentation. It would be nice to have some sort of documentation. Yes, code should be self descriptive, yet would be nice to have documentation, or at least some hints.
4. __Simulated classes. This is not truely Bizmonade issue, maybe more of the ReSharper, but having no intellisense on those is annoying a bit.

Bottom line, from the entire list the only serious one I find #1. I hope there’s an option to achieve what I want. The this library becomes a real gem for my project.