Microsoft Business Rule Framework

BizTalk Server 2009 - Rule deployment issue

Charles Young — Fri, 20 Nov 2009 13:28:40 GMT

There is a small configuration issue with the Microsoft Business Rules Composer in BizTalk Server 2009. This will only affect you if you deploy the rules engine by itself without the rest of BizTalk Server. In a full installation of BizTalk Server, BTS provides a set of BTS-specific Rule Framework components in as assembly called Microsoft.BizTalk.RuleEngineExtensions. This includes a RuleSetDeploymentDriver component that manages deployment of rules via the SQL Server repository.

The BTS-specific RuleSetDeploymentDriver has a dependency on WMI (Windows Management Instrumentation). In a full BTS installation, BTS creates an instance of a CIM class called MSBTS_GroupSetting and populates various property values from the BizTalk management database. This includes the assembly and class name of a RuleSetDeploymentDriver. If you install only the rule processing components, there is no BizTalk management database, and no instance of this class is created. Unfortunately, this means that, whenever you try to deploy a rule set from the Rules Composer, you get a rude message saying:

The database "<server>:<database>" associated with the deployment driver does not match the database ":" specified during product configuration

The message is entirely correct. Microsoft's BTS-specific RuleSetDeploymentDriver component performs this check presumably to ensure that registry settings for the rule repository database name and server name are identical to those configured in the BizTalk management database. This ensures that the Rule Engine Update Service is using the same BTS-specific RuleSetDeploymentDriver component.

When you install only the rule processing components, the registry is unfortunately configured as if a full BizTalk installation had been done. The Rule Composer tries to use the BTS-specific RuleSetDeploymentDriver component to deploy rule sets and fails because no instance of MSBTS_GroupSetting has been created in the CIM store.

Fortunately, this is a simple problem to fix. Microsoft provides a non BTS-specific RuleSetDeploymentDriver component for the rule repository database. All you need to do is change the registry settings to use this instead.

Open the Registry Editor (regedit) and locate the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BusinessRules\3.0

If you have installed the rule processing components on a 64-bit version of Windows, they key will be at:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\BusinessRules\3.0

You should find the DeploymentDriverAssembly and DeploymentDriverClass values under the key. These should be changed to the following values, respectively:

Microsoft.RuleEngine, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
Microsoft.RuleEngine.RuleSetDeploymentDriver

That's it. The Rule Composer should now be able to deploy rule sets.

MS BRE: Clearing Working Memory

Charles Young — Wed, 29 Apr 2009 03:11:22 GMT

My colleague, the ‘Arch Hacker’, forwarded an email to me this evening from Kenton Price. Kenton had noticed some peculiar behaviour using the Microsoft Business Rules Engine. Here are the pertinent extracts from Kenton’s report:

“It appears that if you assert a fact in a rule, it hangs around for subsequent instantiations of the rule engine, behaving like a long-term fact.... I solved it by retracting each asserted fact on every exit path (I had a jump-out-early that halts and stops all other rules, so I had to retract the asserted facts here too)....Facts provided in the object[] passed to the BRE call are all retracted automatically. It appears that any others you assert within the rules must be manually retracted.”

Kenton is quite correct. The issue is actually to do with the Policy class, and there are good reasons why the engine behaves this way. Read more at http://geekswithblogs.net/cyoung/archive/2009/04/28/131548.aspx.

Constraint Satisfaction and Rete

Charles Young — Tue, 24 Feb 2009 20:47:36 GMT

A few days ago, Daniel Selman of ILOG (now owned by IBM) published a solution to the Einstein puzzle. See http://blogs.ilog.com/brms/2009/02/16/einsteins-puzzle/. He did this in response to a challenge from James Owen who is one of the organisers of the October Rules Fest conference. James invited the various vendors who have involvement in the conference to provide a solution using whatever approach they deemed best. See http://orf2009.blogspot.com/2009/02/puzzle-1-for-conference.html.

Daniel suggests that, if ILOG had used a Rete rules engine, they would have had to implement 'convoluted rules' to solve the problem. Daniel is correct, but I thought it would be interesting to look a little deeper at why this is the case.

Microsoft BRE Survey

Charles Young — Tue, 21 Oct 2008 21:09:13 GMT

I'm delighted to report that Microsoft is currently asking for responses to an on-line survey on the use of Microsoft BRE - delighted because it indicates that serious thought is being given to the evolution of this technology. If your organisation uses MS BRE, do please take a few minutes to provide feedback.

The survey is at: https://live.datstat.com/MSCSD-Collector/Survey.ashx?Name=BRE_Usage_Survey_Blog

The only issue I would highlight is that the survey deals mainly with present and past use of MS BRE, and not about how its use could be extended in the future.

MS BRE: Using Compensation handlers

Charles Young — Wed, 23 Jan 2008 06:48:52 GMT

Being known for my interest in rules processing, I quite often get asked to help with problems with MS BRE. A couple of days ago, I was asked to help investigate an issue occurring in production for a BizTalk Server application. Occasionally, in a fairly high throughput system, BizTalk logs an error stating that a problem has been encountered while executing a rule set. That is the only information provided, with no hint of what the problem might be, and because the issue only occurs intermittently under real-world conditions in the production environment, it was not obvious how to obtain further insight without disrupting live operations.

This article investigates one way of handling this deilemma through the use of the compensation handling feature of Microsoft's Business Rules Engine. It goes on to discuss the broader use of compensation handling in rule processing.

http://geekswithblogs.net/cyoung/archive/2008/01/23/118804.aspx

MS BRE: The Rules Engine Update (REU) Service and Policy Execution

Charles Young — Mon, 14 Jan 2008 04:13:24 GMT

A question came up tonight on BizTalkGurus on my favourite subject of rule engines. I don’t blog enough these days, so this gives me an excuse. Essentially, the question concerned an incorrect, but understandable, suspicion that MS BRE may be using remoting to execute rule sets out-of-process. This is not the case. You can find an article describing what actually happens at:

http://geekswithblogs.net/cyoung/archive/2008/01/13/118506.aspx

MS BRE: State Transition Pattern

Charles Young — Sun, 16 Sep 2007 18:06:37 GMT

My fellow BizTalk MVP, Leonid Ganeline, asked if I would comment further on mechanisms to govern sequential flow in rules in MS BRE. He was picking up on some comments I made in my article comparing WF and MS BRE rule performance (see http://geekswithblogs.net/cyoung/archive/2007/08/12/114597.aspx#143628).

What I had in mind was the use of state transition patterns within rule sets. These can be used to layer a degree of sequential control over the set-based pattern matching approach taken by engines like MS BRE. The basic pattern is simplicity itself, and very common. What I generally do is assert an additional 'context' fact to the engine (typically some custom .NET object) in which I maintain a state specifier (e.g., a simple string property). I can then group rules together to match specific states, and use a low-priority rule in each group to change the state. The 'sequential' flow is then governed by the state transitions. Of course, any single group of rules that match the same state do not operate in a sequential fashion amongst themselves. However, you can always just have one main rule per state if you wish. Here is a very, very simple example of the kind of pattern I have in mind.

/*********************************************
* Group 1 - 'Started' state
********************************************/

Rule 1
IF
AND
    Context.CurrentState == "started"
    MyFactA.Property1 > 5
    MyFactB.Property1 < MyFactA.Property
THEN
MyFactB.Property1 = MyFactA.Property1
assert MyFactB

Rule 2 (priority -1)
IF
Context.CurrentState == "started"
THEN
Context.CurrentState = "initialised"
assert Context

/*********************************************
* Group 2 - 'Initialised ' state
********************************************/

Rule 3
IF
AND
    Context.CurrentState == "initialised"
    MyFactA.Property2 == "USA"
THEN
MyFactA.SetCountryCode("01")

Rule 4
IF
AND
    Context.CurrentState == "initialised"
    MyFactA.Property2 == "UK"
THEN
MyFactA.SetCountryCode("44")

Rule 5 (priority -1)
IF
Context.CurrentState == "initialised"
THEN
Context.CurrentState = "completed"
assert Context
assert MyFactA // convenient place to re-assert MyFactA
                        // to avoid loops if, for example,
                        // MyFactA.SetCountryCode() changes the
                        // state of MyFactA.

/*********************************************
* Group 3 - 'Completed' state
********************************************/

Rule 6
IF
AND
    Context.CurrentState == " completed "
THEN
    MyFactA.Property1 = 0
    MyFactB.Property1 = 0

/********************************************/

The low-priority ‘state transition’ rules are rules 2 and 5. Group 2 contains two main rules, whereas the other groups have just one main rule.

Personally, I think MS BRL (and the Rules Composer) should provide a built-in abstraction for this design pattern - i.e., provide a way of grouping rules by state, and declaring how to transition to a new state when a group has completed its work. If this was supported, it would not be necessary to explicitly define an additional low-priority rule in each group.

This design pattern can be a little difficult to maintain in MS BRE currently because the rule composer displays rules in alphabetic order in the UI, regardless of the order in which you created them, and so you cannot see the groupings and state transitions. The answer to this, of course, is to adopt a rule naming convention which makes the pattern more explicit in the UI.

I used this design pattern recently when creating a rule set for applying Bayes Theorem. See http://geekswithblogs.net/cyoung/archive/2007/08/27/114988.aspx. The rule set was written for other rule engines (Jess and CLIPS), but uses exactly the same principle. I have ported the rule set to MS BRE, but just need to clear a potential commercial hurdle before publishing the code.

You can download a slide set for a presentation I gave earlier this year at an architect's conference from http://download.microsoft.com/documents/uk/msdn/architecture/architectinsight/2007/collaboration/COL01-Rules-Processing-in-Business-Processes.ppt. There is a slide in the set which illustrates how a declarative rule set might map onto a process (I've used a BizTalk orchestration to represent the process).

WF Rules and MS BRE - Comparing Performance

Charles Young — Tue, 14 Aug 2007 23:27:29 GMT

I’ve been asked a few times how the performance of WF (Windows Workflow Foundation) Rules compares with that of the Microsoft Business Rules Engine (MS BRE). Having done no testing, I could only guess at the answer.

I’ve now undertaken some initial performance testing to compare WF and MS BRE, and decided to publish the results. You can read my write-up of the results here.

http://geekswithblogs.net/cyoung/archive/2007/08/12/114597.aspx

BizTalk Server or WF for rules and tracking?

Charles Young — Fri, 20 Jul 2007 01:13:27 GMT

I got an email today requesting help in deciding the appropriate selection of rule processing technology for a workflow application. I’ve got requests like this before, so I’ve decided to post a reply publically.

http://geekswithblogs.net/cyoung/archive/2007/07/19/114061.aspx.

MS BRE: Update to side-effects article

Charles Young — Tue, 10 Apr 2007 21:56:00 GMT

I posted an article on MS BRE side effects yesterday. I had immediately to withdraw it for a few hours because I realised it was incomplete (and actually a little wrong) in one part. Then I noticed I had swapped the legend text on the graph making it appear that caching made things slower, rather than faster! I then discovered today that for the last three years I have been completely ignorant of the fact that you can drag and drop object constructors onto the 'assert' argument in the Rules Composer in order to expolit the built-in CreateObject function! Big red face. I have changed the offending paragraph where I moaned at Microsoft for not providing access to this functionality! Given the number of times I have complained about the lack of comprehensive documentation for BizTalk and related technologies, it is ironic that Microsoft has documented this particular feature very cleary indeed, and even given a brief description of what happens behind the scenes! I am suitably chastened.

The updated article remains at http://geekswithblogs.net/cyoung/articles/111169.aspx. If anyone spots any other artefacts of my ignorance or inattention, do please let me know!