Share via

BizTalk Server 2006 Business Rules and Static Methods

  • Article

The Business Rules Engine that ships with BizTalk Server 2006 now supports the usage of static objects without passing that particular object
into the rule as a "fact." However, a registry change is needed to get it working. Why is this valuable? Now you can build business rules
that only require stateful objects to be passed in as facts, and leave helper functions, lookups and the like as static objects.

I was recently working on setting a timestamp on my XML document from within a business rule. With BizTalk Server 2006's changes for static
object support, I wanted to use the standard "DateTime.Now" function contained in the mscorlib assembly, without passing an instance of that
object into the rule as a fact. My business rule looked like this:

However, each time I ran it, I got nothing back in my XML node. After a request on our internal distribution list for some guidance, I got
some help from the grand poo-bah of business rules, Jurgen Willis. Apparently the following key is required in the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BusinessRules\3.0\StaticSupport (DWORD)

There are three valid values for this key:

  • 0 - This is the default key, and pretty much mimics the behavior of BizTalk Server 2004 where an instance of an object is
    always required as an input fact, and the method is only called when the rule is evaluated or executed.
  • 1 - An instance of the object is NOT required, and the static method is called whenever the rule is evaluated or executed
  • 2 - An instance of the object is NOT required, but the static method will be called at rule translation time (only if the
    parameters are constants). This is primarily meant as a performance optimization. However, note that static members used as actions
    will NOT be executed at translation time, but static methods used as parameters may be.

So obviously in my case, I needed to use keys 1 or 2, with 1 being the only legit choice since for a static method like DateTime.Now, I'd want
it evaluated during execution, not at rule translation!

The key wasn't present on my machine, so I'm not sure if this is something we're going to include in the RTM bits. But now you know, and knowing
is half the battle.

Comments

  • Anonymous
    November 14, 2005
    The comment has been removed
  • Anonymous
    November 18, 2005
    Excellent! Thx for the registry spelunking...more on BRE to come!
  • Anonymous
    November 29, 2005
    I hope it will get into the RTM. But please without the need to go into the registry!

    This would simplify all the type conversion functions!

    Marco
  • Anonymous
    December 08, 2005
    The comment has been removed
  • Anonymous
    December 09, 2005
    Paul, Make sure you don't add the "System" assembly from the "browse" menu for the .NET Fact. Instead, reference the mscorlib assembly, and then you'll find the DateTime class.
  • Anonymous
    January 21, 2009
    PingBack from http://www.keyongtech.com/327391-case-sensitive-in-bre