I have a case where I need to validate an incoming XML message and generate an aggregated XML message containing all validation failures. The base functionality of the BRE does not allow this kind of message manipulation – adding new elements (nodes) to messages and then setting the value.
My good friend Bing to the rescue!
This blog post gives a good walkthrough of doing exactly what I needed to do using the Microsoft.RuleEngine.XMLHelper class. Pay close attention to the Windows Registry setting at the end of the post.
This MSDN blog had a very good sample BRE Policy that I used to see a concrete example. Download the .exe and extract it.
This MSDN document details the Windows Registry setting that I mentioned previously. The function is to allow the BRE to use .NET helper methods as static objects, rather than requiring an instance.
These three sources combined gave me the complete solution. It works like a charm, and I did not have to write my own custom .NET helper class to do the XML element insertion.
Working with the BRE had me searching around and reading articles, when I came upon this great graphic from Wikipedia on how the Rete algorithm works.
- Facts are asserted
- Rules are executed
- Actions are added to an Agenda
- Agenda is executed
The Rete algorithm is used in artificial intelligence processing. That’s just cool!
Once again, here we are talking about the BRE!
I have a set of rules that utilize the OR operator. I found a very, very interesting article describing in detail how the BRE handles the OR operator.
- OR is not handled like procedural languages, such as C# – there is no short-circuiting. All elements of the OR condition are evaluated, and therefore each submits a separate match to the Agenda to be followed by the BRE
- In the BRE (or any Rete engine) OR is much more analogous to SQL. Since each member of an OR condition results in its own “record” per-se, it can be loosely understood as a SQL using the UNION ALL clause, having a separate SQL statement for each member of the OR condition
- BizTalk BRE performs a de-duplication after processing rules that keeps the multiple Rete results from rules using OR from being added to the processing Agenda. This mitigates some of the, “What the…” you felt when reading bullet one above!
- If you purposely want separate Agenda items to be processed, you can force the BRE to do this by creating a separate rule for each member of your OR condition (i.e. don’t use OR in your rules, create multiple rules instead).
A client was complaining that during an outage of a downstream system, they would experience dozens of suspended messages in BizTalk Server (or more). They asked if there was a way to retrieve all of the suspended messages, rather than having to go through the slow and tedious process of saving them out of the BTS Admin Console.
PowerShell to the rescue!
This blog post has the solution:
As my recent blogging indicates, I’ve been working with rules BRE policies over the last few days. I’ve had to do some interesting things with vocabularies, as you might have surmised from my last couple of posts. What this meant was I would have to make a vocabulary change, publish it, and test it to see if it works.
Well, I don’t want a slew of vocabulary versions hanging out there, and when my development is complete I want all of my rules policies to use my latest-and-greatest vocabulary version. Doing this manually, with even a handful of meaningful rules, is just plain painful! So, a quick Bing gave me the best gift a BRE developer in this situation could ever ask for!
Vocabulary Updater Tool
This handy little command-line tool will take whatever policy you point it at, make a new version of the policy, and update it to the latest version of the vocabularies it depends upon. It works quite well and saved me from trying to bribe my children into the sweatshop kind of labor it felt like doing this by hand!