The Business Rule Engine.
If you are a BizTalk enthusiasts, hobbyist, developer, architect, or implementer, the BRE is definitely something that you are going to come across. I’m not going to explain what the BRE is, there are many resources on the web, just google away for this topic. However, if you claim to know about the BRE, how does one test this knowledge?
Naturally, one could sit down at a developer configured system, and you can say, “Build me a BizTalk app that uses the BRE, you have an hour to do so.” This would test knowledge of implementation. If the candidate performs the task, then we exclaim, they know BRE.
But how do you put the literal simulation into words without writing a book? Then how does one give an answer without the same?
Well one thought pattern was to build a quick scenario such as:
Company X is currently running version 1.0 of a policy. A new rule is implemented and saved to version 1.1 of the policy. You need to implement an orchestration that can call version 1.1 of the policy while version 1.0 of a policy must continue to be supported by other orchestrations.
The next thing would be to compare the answer. A question of this nature places many things into the mix. This was a scenario that really occurred, I was put to the test to see if I really understood the BRE.
At first thought, I took the scripted answer from Scott Woodgate’s book and said, orchestrations use the call rules shape to call into the BRE. The Call rules shape can only call into deployed business rules. So the answer to this question is it can’t be done. As I was getting ready to say this, I remember Kunta Kente from roots where he said the in his native language, “Can’t” does not exist, which led me back to being a developer for a second instead of just an ordinary trainer or consultant.
I envisioned, I’m a developer I can do anything with enough thought and a little design. After all, isn’t that OOP, reusability, software design at its best???
Do I really know the BRE? The BRE can be called from any host, not just BizTalk. Why not use the same method of thought to call into the BRE that another engine such as a Windows desktop app? BINGO!!!!
The answer became simple, use an orchestration to manually call into the BRE using RuleEngineComponentConfiguration class, a factretriever. Next, use the PolicyTester class to tell the RuleEngine which version of the policy to call into. I created a proof of concept, and it was done.
Here’s some sample code detailing the Proof of Concept:
using msre=Microsoft.RuleEngine;
using Microsoft.BizTalk;
using Microsoft.BizTalk.RuleEngineExtensions;
…
try
{
msre.RuleSetInfo rsi = new msre.RuleSetInfo(msg.policyTesterName, msg.policyVersionMajor, msg.policyVersionMinor);
RuleSetDeploymentDriver dd = new RuleSetDeploymentDriver();
msre.RuleStore sqlrs = dd.GetRuleStore();
msre.RuleSet rfpRules = sqlrs.GetRuleSet(rsi);
msre.RuleSetExecutionConfiguration exConfig = new msre.RuleSetExecutionConfiguration();
msre.RuleEngineComponentConfiguration dbConfig = new msre.RuleEngineComponentConfiguration(msg.policyFactDisplayName, msg.policyFactRetrieverFQN);
exConfig.FactRetriever = dbConfig;
rfpRules.ExecutionConfiguration = exConfig;
XmlDocument doc = new XmlDocument();
doc.Load(xmlFile);
msre.TypedXmlDocument rfpDoc = new msre.TypedXmlDocument(msg.documentTypeName, doc);
msre.PolicyTester host = new msre.PolicyTester(rfpRules);
//Create thread to run engine
host.Execute(rfpDoc);
…..
The above may seem like a lot of code, however, there are less coding efforts possible using these classes.
When showing knowledge on a particular topic, don’t just give the scripted answer, know the essentials, and use them.