Problems with PropertyBag in custom pipelines

Some advice written by one of my colleagues, Zeb, who spent some time wrestling with a custom pipeline

I was recently tasked with building a custom pipeline component. I hit the net to look for some samples on doing this, and the first thing that I noticed was that there appeared to be a million blogs on how to do this, and they were all using the exact same code – right down to even using the same GUID for their class!

There are plenty of things I could write (and maybe I will), but the biggest issue I had was that none of them were really elaborating on the saving and extraction of custom properties. The basics were simple (implement IPersistPropertyBag), but as is so often the case what can seem simple, often turns out to be far from it! (Although it does tend to become simple and obvious in hindsight)

It was a long journey, and hard to debug, as the symptoms weren’t immediately pointing to the cause. So, below are the two biggest issues I had with the PropertyBag, and how to work around them:

Issue 1: Properties are visible in BizTalk, but not in Visual Studio

Now, this one really didn’t make sense at first, and honestly, it still doesn’t! I know the “how”, but not the “why”. Basically, Visual Studio uses reflection on the class to look for public properties and assumes that they are the properties that can be modified from within Visual Studio. BizTalk on the other hand looks at the actual serialized [sic] properties saved into the pipeline (i.e. if you look in the .btp file “Properties” node inside the component).

So, if you do what I did and move your properties into a seperate class (which I did because I wanted to make two versions of the component – one inheriting from FFDasmComp and one from XMLDasmComp), you need to be aware that you also need to expose them in the calling class as seperate public properties or they will not be visible in Visual Studio.

Issue 2: PropertyBag.Read method returning NULL

This was a strange one, as I was getting inconsistent behaviour. Sometimes my component would work, other times it wouldn’t, and my code changes did not appear to be impacting on the success rate.

The lucky break came when I noticed that the Load method was being called twice, and each instance was returning different values. It appears that BizTalk was calling Load once with the information that was saved when the pipeline was created in Visual Studio, and then a second time to get the customized [sic] values that were modified in the BizTalk Administration Console. The problem here is that if you don’t modify a value in BizTalk, it doesn’t get saved to that property bag, so the read will return NULL.

The way around this is to do the first read and use it to load default values for your properties, and then on the second read only overwrite those values if the Read returns a non-NULL value. I did this by creating a “GetProperty” function that accepted the PropertyBag, the key to read and a default value (which was loaded with the previously read value if available). If Read returned NULL (or error), I loaded the default value.

Thanks for the good work, Zebba.

Yay, we’re still relevant

Just incase you haven’t read this amongst the other 7394 blog posts today, Microsoft have confirmed the next version of BizTalk Server 2006 R3 2009.

Here’s the official Roadmap page.  Looks like there’s still a lot of life in the old girl yet!

Unable to refresh the BizTalk Group Hub

I have occasionally gotten either of the following errors in my BizTalk Administration console, and am then unable to refresh the BizTalk Group Hub:

"An instance of the FreeThreadedDOMDocument class cannot be created"
"Failed to create a CLSID_BizTalkPropertyBagFactory"

I still don’t know why it happens, but the solution is simple: Restart the Windows WMI Service.

With thanks to this blog article.