Microsoft Business Rule Framework

MS BRE: Using Compensation handlers

Charles Young — Wed, 23 Jan 2008 00: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 — Sun, 13 Jan 2008 22: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 12: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 17: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 — Thu, 19 Jul 2007 19: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 15: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!

MS BRE: Controlling rule side effects

Charles Young — Mon, 09 Apr 2007 09:03:00 GMT

For almost two years now, I've been intending to write an article about the mysterious 'side effects' flag used in Microsoft Business Rule Engine policies. Microsoft documents this feature (see http://msdn2.microsoft.com/en-us/library/aa559124.aspx), and describes very briefly how to control it. The mystery that surrounds this flag arises because it is represented by an attribute named 'sideeffects' in Microsoft's BRL (Business Rule Language) although it actually controls a caching mechanism, and because Microsoft has not provided access to the flag in their Rules Composer, thereby giving the impression that it is not a 'first-class' feature of rule definitions. In reality, this flag is an important aspect of the functional approach adopted in Microsoft's Business Rule Language (BRL), and can have a significant effect on both behaviour and performance of your policies. Understanding the flag also requires a greater understanding of the way in which BRL binds functions to custom code, providing a clean mechanism for implementing domain-specific extensions to the rule language.

Incidently I apologise that, for a few hours after my initial posting, I had to withdraw the article. No sooner had I posted than I realised that I had not adequately investigated one aspect of MS BRE functionality. I have now corrected and extended the original version. I'm sorry if anyone found their aggregator reporting a page that wasn't there.

The article is located at http://geekswithblogs.net/cyoung/articles/111169.aspx

Microsoft BRE: Fact Identity in the Microsoft Rules Engine, or how the author chased a non-existant bug

Charles Young — Wed, 04 Apr 2007 21:26:00 GMT

I recently had reason to revisit the exact mechanisms Microsoft use when you assert facts to the Microsoft Rules Engine. I was discussing stuff on-line with a fellow rules enthusiast when a terrible thought occurred to me. Can the MS BRE always uniquely identify each different fact, or is there a chance that sometimes it might confuse two facts with each other?

For a couple of days, I was convinced that I had stumbled on a significant bug. Indeed, at one point, I thought there was such a serious problem that I would have to recommend to my company that we desist from any further use of Microsoft’s rules engine. Melodramatic, huh! Fortunately, after a bit more research, I discovered that I was quite wrong. The MS BRE does not suffer from a terminal flaw and can be trusted to always distinguish correctly between all your facts. It’s worth recording my suspicions, mistakes and eventual enlightenment. There is something useful to learn, here, about the inner workings of the engine, and also about Microsoft’s implementation of the Hashtable class in .NET.

BizTalk Server 2006: Using .NET Classes for Orchestration Message Types

Charles Young — Wed, 29 Nov 2006 17:34:00 GMT

I had some discussion today with Christof Claessens about the merits of using .NET classes as orchestration message types in BizTalk Server 2006. Here are some of the reasons I came up with, and also some of the issues.

http://geekswithblogs.net/cyoung/articles/99464.aspx

MS BRE: Further Issues with XPath Selectors in the Microsoft Business Rules Engine

Charles Young — Thu, 14 Sep 2006 15:06:00 GMT

This article supplements an earlier article, posted a couple of weeks ago (http://geekswithblogs.net/cyoung/articles/90102.aspx), on issues concerning the use of XPaths to map between the hierarchical data structure of an XML document and the relational view of 'facts' in the Microsoft Business Rules Engine. As I suggested in the introduction to that article, I have repeatedly been asked to troubleshoot MS BRE issues which turn out to be related to the use of XPaths. Earlier this week, I received another request for help. The symptoms and solution to the problem are worth recording because they provide greater insight into this topic.

http://geekswithblogs.net/cyoung/articles/91183.aspx