Charles Young

  Home  |   Contact  |   Syndication    |   Login
  196 Posts | 64 Stories | 510 Comments | 373 Trackbacks

News

Twitter












Article Categories

Archives

Post Categories

Image Galleries

Alternative Feeds

BizTalk Bloggers

BizTalk Sites

CEP Bloggers

CMS Bloggers

Fun

Other Bloggers

Rules Bloggers

SharePoint Bloggers

Utilities

WF Bloggers

Wednesday, September 14, 2011 #

Following the previous post, here is a second bit of wisdom.  In the Load method of a custom pipeline component, only assign values retrieved from the property bag to your custom properties if the retrieved value is not null.  Do not assign any value to a custom property if the retrieved value is null.

This is important because of the way in which pipeline property values are loaded at run time.  If you assign one or more property values via the Admin Console (e.g., on a pipeline in a Receive Location), BizTalk will call the Load method twice - once to load the values assigned in the pipeline editor at design time and a second time to overlay these values with values captured via the admin console.  Let's say you assign a value to custom property A at design time, but not to custom property B.  After deploying your application, the admin console will display property A's value in the Configure Pipeline dialog box.  Note that it will be displayed in normal text.  If you enter a value for Property B, it will be displayed in bold text.  Here is the important bit.  At runtime, during the second invocation of the Load method, BizTalk will only retrieve bold text values (values entered directly in the admin console).  Other values are will not be retrieved.  Instead, the property bag returns null values.  Hence, if your Load method responds to a null by assigning some other value to the property (e.g., an empty string), you will override the correct value and bad things will happen.

The following code is bad:

    object retrievedPropertyVal;
    propertyBag.Read("MyProperty", out retrievedPropertyVal, 0);

    if (retrievedPropertyVal != null)
    {
        myProperty = (string)retrievedPropertyVal;
    }
    else
    {
        myProperty = string.Empty;
    }

Remove the 'else' block to comply with the inner logic of BizTalk's approach.


Here is a small snippet of BizTalk Server wisdom which I will post for posterity.  Say you are creating a custom pipeline component with custom properties.  You create private fields and a public properties and write all the code to load and save corresponding property bag values from and too your properties.   At some point, when you deploy the BizTalk application and test it, you get an exception from within your pipeline stating, unhelpfully, that "Value does not fall within the expected range."  Or maybe, while using the Visual Studio IDE, you notice that values you type into custom properties in the Property List are lost when you reload the pipeline editor.

What is going on?   Well, the issue is probably due to having failed to initialise your custom property fields.  If they are reference types and have a null value, the PipelineOM PropertyBag class will throw an exception when reading property values.  The Read method can distinguish between nulls and, say, empty strings, due to the way data is serialised to XML (e.g., in the BTP file).   Here is a property initialised to an empty string:

            <Property Name="MyProperty">
              <Value xsi:type="xsd:string" />
            </Property>

Here is the same property set to null:

            <Property Name="MyProperty" />

The first is OK.  The second causes an error and leads to the symptoms described above.

ALLWAYS initialise property backing fields in custom pipeline components.  NEVER set properties to null programmatically.