sfeldman.NET

I am getting involved in another project, that looks like has its own testing challenges (last project I was involved was a BizTalk based project, quite a few testing challenges!).

This might be helpful for those that work with SVN and require (read-only for now) access to code that is under GitHub

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.

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.

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?

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.

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):