BizTalk Business Rule Engine Compare DateTimeNow within a range of dates?

Question

I try to use Between predicate to compare the current datetime with a range of date time.

I reference mscorlib assembly and use get_Now() within DateTime class in the assembly to get DateTimeNow. I have problem to compare this current datetime with the range.

my condition is like:

• DateTimeNow is between 2012-08-03 07:00:00 and 2012-08-04 07:00:00

• DateTimeNow at my region should be 2012-08-03 16:33:20 for this moment. It should between the range I specified. But it seems does not work. If I replace DateTimeNow with 2012-08-03 16:33:20, it works.

It seems for some reason my DateTimeNow does not work. Anyone has any idea?

Answer 1

I found to use Get_Date() function in .net mscorlib assembly, you have to modify your machine registry

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BusinessRules\3.0\StaticSupport (DWORD), give value 1

Details in:

http://blogs.msdn.com/b/richardbpi/archive/2005/11/14/492489.aspx

http://kinnaribhute.blogspot.co.nz/2008/04/some-interesting-stuff-about-biztalk.html

I am not sure how this will affect the production server, if the production server environment is not clustered with multiple node, there will be an outage for reboot the server.

Answer 2

There is an impedance mismatch between the way facts are logically modelled in the engine and the way objects are modelled in .NET code, and one effect of this is the problem of calling static methods. If you set the StaticSupport flag as described by Xiao Han, the engine changes its behaviour, treating static methods much as if they were built-in functions or predicates. By default, however, the engine treats static methods as behaviour of facts. Physically, a fact is an object in the working memory of the engine, and each fact has to be asserted to the engine before it's methods can be used. So, to call the static Now property getter on DateTime, you first have to assert a DateTime object to the engine. Of course, DateTime is a value type (structure), but that's OK because, when you execute a rule set, you assert a single fact as an Object or a collection of facts as an Object array. .NET will automatically box a DateTime (internally wrap it as an object) passed in this way.

It seems mad, I realise, having to assert an object to the engine in order to call a static method (or, in this case, a property getter, which is really a method, of course) on the type of that object. It would probably have been better if the engine had been built to treat static methods as built-ins by default. However, that was not the case. In addition, it would have been much better if Microsoft had implemented the StaticSupport flag at the level of individual rule sets, or even individual rules. Implementing it in the registry (machine-level), or alternatively configuring it in the .config file (application-level; use ) in this way can pose real problems because it can break rule sets that were written to use the opposite value of the flag.

Another point to bear in mind in that the Static Support can also be set to '2'. In this case, if you call a static method with no parameters, or if you call it with constant values only, and if you call it as a predicate in a condition or as an argument to another function, then the engine will evaluate the static member just once and cache the result.