I have the pleasure recently, after working with BizTalk since 2001, of actually implementing a solution using the business rules engine aka BRE as hosted by a BizTalk Orchestration. While the "insight" is fresh, I though I'd jot down my observations. This may be of interest to you if you are evaluating this for use within your solution/organization.
- BRE uses a different paradigm than typical coding. Now if you are considering BizTalk, then you are probably aware of this already. But even so, although Messaging and Orchestration are two new paradigms for many of us, BRE represents a third way to think about executing program logic. This means there is a significant learning curve for expressing even the most trivial of ideas.
- Source Control: The Business Rules Composer does not integrate with source control. You need to enforce a manual process of export and check-in. (This cannot be scripted, see below).
- Deployment: There is a Business Rules Deployment Wizard. First problem -- this has no command line/ scripting interface. Get used to click-click-clicking your way through deployments. Second problem -- if your policy is dependant upon a certain version of a vocabulary which is not yet deployed, it fails to deploy.
- Vocabulary: In terms of developer experience, each change of a vocabulary requires you to copy-paste, save and publish a new version before you can use the terms. Second problem -- after you create and use a new version, the existing rules will refer to the old version and the updated rules will refer to the new version. This means you need to deploy both vocabulary versions to production. The Acumen tool (below) can automatically update *most* of your references which mitigates this issue. Third problem -- (I may be incorrect here) the vocabulary hard-codes things such as paths to XSD files and these paths need to be manually updated before deploy to production.
- Versioning: In development in order to test out a policy or use a vocabulary, you need to publish (and deploy). This makes the artifact immutable, so to enact further changes you must copy-paste to create a new version. After significant development, you can have many versions. This is analogous to "build" numbers. The problem occurs when you want to use a "release" number. This is an intense manual process to a) keep track of the "release" numbers and b) update the XML files before deployment.
- Debugging: There is no way to debug. You can only perform unit tests.
- Testing: I have big issues with testing. You have 3 options.
- First you can test within the Business Rules Composer. Problem one: If you use .NET facts with configuration strings this won't work. For some reason the Composer is NOT a .NET application and you cannot feed it any .NET config files. (Hint: abstract your configuration and create default values, be sure to log any use of default values in case you forget to set your config in production). Problem two: I get different results from within the Composer versus the same policy and messages when hosted by an Orchestration!!! (This occured when I was playing with Naf and the "exists" predicate. Looks like an optimization on empty nodes may occur within BizTalk.) As the test executes, you can view a trace of the activity. This trace isn't very helpful, but is better than nothing.
- Second you can create a test harness orchestration. This is a good idea. But you don't get much information.
- Third you can write a .NET application which hosts the rules engine, feeds in your test data, applies custom tracing, and even checks the results. But my problem with this approach is that you cannot guarantee the same behaviour as within BizTalk unless you test within BizTalk (see point 1).
- NaF: Negative assertion as Failure. Ok, this is a big term, google it. Basically the BRE *does not* perform any rule where the fact has not been asserted. That means if you have a rule such as "IF A == "1234", THEN B" and the fact A is missing/empty/blank then that rule will simply not fire. You *cannot* use the BRE to validate messages such as "IF C is missing THEN D". And finally if you have a rule "IF E/F is true then G" (an XML fact) and the slot F is missing, then the rule will throw an exception (BizTalk will report XLANG/s in event log). Also if you have a rule with multiple conditions of which a single fact is missing, then the entire rule will not fire.
- Parameters: What is the interface for my policy? You may ask yourself, "Hey, I just took this existing vocabulary and dragged in some terms and made my rules. I wonder what my parameters are?" This is a good question. You have to be very aware of which data structures/databases your rules (via the vocabulary) are using and then be sure to supply one (or more) instances of each at runtime. Second point: Although the documentation seems to indicate you can send in variables or messages, AFAIK, you can *only* send in messages from an orchestration. If you send in two instances for a given Type, by default, the rules will execute twice, one for each copy. Third point: If you forget to pass in an expected parameter at runtime, then you will not get a warning or error. There is no concept of a required parameter.
- Messages in Orchestration: The "Call Rules" shape breaks a fundamental design principle in orchestration: The message is immutable. The BRE modifies messages in-memory and returns them to you. So in the orchestration, you pass in msgA, the BRE sets the approved flag to true and returns to you msgA. But actually it is a new message msgA' that has been assigned to the same variable. If you need your original message context, you should pass the BRE a copy of the original message.
- Documentation: There is *no* ability to annotate the conditions or actions within rules. You can use the rule and policy name as a basic handle on what is happening. The Acumen tool produced a cool PDF report which documents a given policy and does so in a way that other people can understand it.
- Prefix: The rule conditions are expressed as prefix notation. This is a different paradigm from the "normal" infix style coders and business people use (think Excel). Only a math junkie can love this. Personally, I find it very hard to sight-read the rule.
- Short circuit: Most code languages (and also conditions in infix notation) use short circuit logic. This mean that if the first part of the AND statement evaluates to FALSE, then the second part is skipped. We typically use this as follows "IF A exists AND A==1234 THEN action B". But in this case both sides will be evaluated causing the equivalent of a pointer exception when the value of A is attempted to be accessed. Actually, if you view the traces after "Test Policy" you may notice that all your conditions are evaluated and only then are the rules asserted.
- IF-THEN-ELSE? Again, I am biased as a coder, but where is the "else" statement? I chalk this up to "different paradigm". Each rule is expressed as CONDITIONS-ACTION, basically an IF-THEN logic. To get the else, you would have to copy paste the rule, apply a "NOT" to the begining of the conditions and update the action. Even this may not yield the expected results because neither rule may actually fire (see NaF above).
Use BRE IFF you can really spend the time to learn it and absorb the different paradigm. You should basically have an ongoing requirement to create and maintain business rules continuously.
Do not expect a non-technical business analyst to change the rules. This is the job of a developer.
Do not expect a developer who does not have either lots of experience in this paradigm OR higher education in math/logic/computer science to correctly analyse/design/implement business rules.
- Acumen Rules Manager. If you are going to do BRE development, I highly recommend buying this tool.
- Rule Name. I always prefix the rule name with the priority, i.e. -20. If you use negative numbers, then your rules will be listed in execution order.
- Vocabulary: I highly recommend using a vocabulary. Organize them by type, so have one vocabulary for each message type. When a change is made, rev the entire vocabulary and then update your rules using Acumen tool.
- Develop consistent, documented, repeatable procedures to document, version control, regression test and deploy the business rules.
- In your orchestration, place the "Call Rules" shape in a retry loop. Exit the loop if the rules succeeded, (i.e. check a message property to ensure it has been updated), but Suspend the orchestration if the rules have failed. You then can update the rules and resume the suspended orchestrations.