Real-life experiences gained on cutting edge BizTalk projects from the City of London.

Sunday, August 07, 2005

Assembly probing when adding pipeline components to the Toolbox

We had an issue at a customer about a month ago when a Pipeline Component was refusing to be added to the Toolbox and the error said something like 'You have selected an invalid Pipeline Component'.

The error message doesn't really give you much to go on, but one of our consultants eventually managed to work it out. It turns out that the pipeline component referenced another assembly that wasn't in the GAC and the design environment must navigate the relationships when the component is added to the Toolbox for some reason.

The approach uses the standard .NET assembly probing rules, so it will look for the assembly in the same directory as the pipeline component (e.g. C:\Program Files\Microsoft BizTalk Server 2004\Pipeline Components\) and then will look in the GAC if it doesn't find it there.

So if you get this spurious message when adding the pipeline component to the Toolbox, check that all other assemblies are where they should be...

Messages are immutable.... or are they??

David & I wrote a BizTalk exam plus InfoPath exam simulator for TechEd 2005 in Orlando and travelled over in June to have some fun and get some sun . The exam consisted of 25 or so pretty hard questions on real world BizTalk stuff (150 took the exam and I think approx. 10 passed!). One of these questions was based on whether or not messages could be changed. ie: whether they are immutable.

As far as orchestrations are concerned, we know that if you want to change a message, you have to clone it first and then make your ammendment. But how does it work with the rules engine? If you pass in a message to the rules engine and use some Set operations to update the message, when the message is returned to the orcehstration, the message has miracoulously been updated. Therefore, messages are immutable except for when you use the Rules Engine right?

Lee Graber sat the exam (and passed by the way, although he didn't come first!). After the exam we had a chat about the message behaviour with the rules engine and he was adamant that messages are always immutable, so we had a play around and he showed us that he was in fact right, the Rules engine automatically performs the same operation by cloning the message and passing back a copy of the message with the values updated. This was easy to check by looking at the MessageId of the before and after message to confirm that it had in fact changed.

This raises some interesting questions:

  • What happens with .NET short-term facts? Are these cloned or just referenced as you would expect?
  • Does the cloning only occur when you use the 'set' operations or are messages always cloned when you use the call rules shape?
  • What happens if you use .NET messages rather than XML messages?
  • What is the performance penalty associated with a set operation on an XML message?
  • Is it more performant to pass in a .NET fact to catch the set operations
  • Is the same behaviour experienced with calling the Rules Engine from the API?
If I ever get some time off from my day job, I'll have a look into these and post part 2...