So far we have only dealt with the default execution plan which runs the rules from top to bottom without any other interaction. In a previous tutorial I mentioned that you can perform pre and post processing in the execution plan. It may not be clear why you would want to do this so I will show you a quick example.

In our previous tutorials we were dealing with a demo ClaimEditsSample project that would pass a single medical claim object into the rules engine. Suppose our underlying program was really dealing with an array of medical claims and instead of passing them individually to the rules engine we wanted to pass in the entire array. However, we don’t want to have to iterate through the entire array for every rule that we create. This is where the power of the execution template comes into play.

First we will open our original ClaimEditsSample project.

Then we will create an array that contains two test medical claims. For this demo we will only change the Rules Engine portion to expect an array. The rest of the client application that expects a single claim object will be hardcoded to the first claim in the array.

Then we will change the interface to pass in a variable called “Claims” and the value will be our new array.

That’s everything that needs to be changed in the client program. But our rule repository is still expecting a single argument called “Claim”.

So, next, we will open the repository in the Rule Editor.

Click the execution plan.

Go to the “Arguments” tab.

Change the variable name the “Claims”. Then change the argument type to an Array of, and select the Claim object for the array type.

Now the arguments in the program and the repository match up but all of our existing rules are still expecting to receive a single variable called “Claim”. To handle this we want the execution plan to iterate through the array for us and pass each medical claim to the rules.

First, delete the “RulesContainer” activity.

Then drag a ForEach activity into the execution plan.

The array that we are going to iterate through contains claim objects, so change the TypeArgument property to “Claim”.

In the “Values” property, type “Claims” because that is the name of the array that we will iterate through.

We want the name of the iteration variable to be “Claim” so we will put that in the iteration field.

Finally, we will simply drop the RulesContainer activity into the center of the ForEach activity and save the execution plan.

Now, all of our rules will have access to the Claim variable. The rules also have access to the higher level Claims array variable. In this example there is little purpose for that but if the Claims array variable weren’t just a simple array, but an object with other meta-data related to the claims then the rules would have access to that metadata as well.