Insert XML Elements with the BizTalk Rules Engine

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.

http://arnulfowing.blogspot.com/2007/09/microsoftruleenginexmlhelper.html

This MSDN blog had a very good sample BRE Policy that I used to see a concrete example. Download the .exe and extract it.

http://blogs.msdn.com/b/biztalkbre/archive/2006/08/31/734291.aspx

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.

http://msdn.microsoft.com/en-us/library/aa950269.aspx

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.

Good times!

BizTalk Rules Engine – Rete Algorithm

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.

1. Facts are asserted
2. Rules are executed
3. Actions are added to an Agenda
4. Agenda is executed

The Rete algorithm is used in artificial intelligence processing. That’s just cool!

Handling “OR” Operators in the BizTalk Rules Engine

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.

http://geekswithblogs.net/cyoung/archive/2006/05/24/79500.aspx

Cliff Notes:

• 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).

Retrieve Suspended Messages from BizTalk Server

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:

http://winterdom.com/2006/09/btssuspendedmessaginginstanceswithpowershell

Enjoy!

BizTalk Rules Engine – Christmas Come Early!!!

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

http://blogs.msdn.com/b/bizrules/archive/2010/12/01/9582393.aspx

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!

Updating multiple nodes with different parents and hierarchical levels using the BizTalk BRE

More tricks on handling hierarchical XML in the BRE…these techniques need to be better documented on MSDN!

BizTalk Messages

Oops, this must be the longest and worst blog post title you have ever seen. Let’s quickly make clear what I mean:

Recently I needed to update multiple elements using a single rule in the Business Rule Engine (BRE). To most BizTalkers this is nothing special. The thing that complicated this particular scenario was that the elements to update where in different hierarchical levels within the xml instance and thus had different parent nodes.

See the following XML and corresponding XSD instance for an example of this scenario:

<ns0:Customer xmlns:ns0=“http://Samples.BRE.Customer“>

      <Name>John</Name>

      <Discount>10</Discount>

      <Accounts>

            <Account>

                  <ID>12</ID>

                  <Discount>10</Discount>

            </Account>

            <SubAccounts>

                  <SubAccount>

View original post 1,068 more words

BizTalk Business Rules and complex XML structures

This approach to handling hierarchical XML documents in the BizTalk Rules Engine saved me a bunch of work. It took me a while to find this blog post, so I am re-blogging it!

Adventures inside the Message Box

The BizTalk business rules engine is a very powerful asset in an integration specialist’s toolbox, but it can be tricky when you are trying to operate with complex schemas as you try to get your head around how it works.  The problem I will try to illustrate here is that the default schema vocabulary definitions will not allow you to spread your conditions and actions across different records in an XML schema if they are both contained within a single instance of a repeating reccord.

For this example, lets say that we want to evaluate a batch of customers, and for those that are Infinity years old (ok, not the best example) we are going to set their AwardsLevel to Gold.  We are going to deal with the below XML schema (note that RegularCustomer is unbounded and that Age is optional) and XML input file.

Of course Chuck Norris is Infinity!

Let’s add…

View original post 758 more words