[ Update: PowerShell Rules Engine: How-To Technical Details ]
Workflow Foundation gives us another “gem in a rough” – Rules Evaluation Engine. It is like a product within a product. [It is "rough" in a sense as in "buried within".]
As you know that in a lot of cases a simple if-else-then rule is either “too dumb” or it takes a lot of code (a set of rules) to express your requirement. In this case the Workflow Rules Engine comes handy. Among other great features, it allows you to define rules priorities, status and chaining policy. This can easily control the order in which these rules are evaluated (and even reevaluated). These rules can be executed against any managed object. The Rules Editor, that you’re getting with the Workflow Foundation, does the type reflection behind the scenes and provides you with a reach editing interface, which includes intellisense as well as syntax evaluation.
To make my case easier to explain, let’s take an extremely simple and exaggerated example: “let’s delete all the files that are more than 10 bytes”.
This is how the RuleSet will look like:
This is what will happen:
- The first rule “IsFile” checks if the “current” item is a directory. If it is – the evaluation will “halt” for the current item and the system will move to the next item. If it’s a file the, rules will continue to evaluate.
- The second rule “IsBig” will execute the “Then” script only if the file size (“Length”) is more than 10 bytes.
There are a lot of interesting things you can do with the rules, but first you have to understand how they work.
Note the order of the rules execution (crash guide for dummies, since it’s a huge topic and I can’t put everything in one post):
- Only the active rules will be executed
- The rules with the higher priority will be executed earlier (0 is is lowest priority)
- The rules within the same priority will be executed in the ALPHABETICAL order
- If you have the FullChaining turned on – the rules will be reevaluated until either nothing to reevaluate or “Halt” command was called
- for more info see great article by Scott Allen “Windows Workflow: Rules and Conditions” and, of cause, MSDN.
If you want to start playing with this technology go ahead and download my code. You’ll find there 3 CmdLets. Here is a short intro:
- New-Rules file-name - will open a new Rule Set Editor and will allow you to create your own rule-set.
- Edit-Rules file-name – will allow you to edit already existing Rule-Set
- Run-Rules file-name item-pipe – will execute the rules against each and every item in the pipeline
This is how you can execute the Rule Set against a PowerShell command pipe:
dir c:\logs | Run-Rules rules.xml | % { "copy $_ c:\temp" }
All the items, after the rules were applied, will continue traveling the command pipe. If you’d like to stop an item to go through add an action:
this.StopProcessing = true
The code is operational as it is, so, what are you waiting for? Go ahead and unleash your imagination!
But first, don’t forget to take the code from the usual place 
on my web site.
Note: the code is provided only as a sample and a good starting point for your projects. If you’ll decide to make any changes and to share them with the community – send the code to me and I’ll upload it.
For more info:
MSDN article: Introduction to the Windows Workflow Foundation Rules Engine
Talk by Michael Stiefel: Using the WF Rules Engine Outside of a Workflow (and the attached presentation with a code sample)
Subscribe now
. Unfortunately, in the startup world that I operate most of the time, it’s not very recognizable achievement, but it’s nice to put these logos on my presentation slide decks and, especially now, I have a very powerful bragging rights – I have ALL of the Microsoft developers certifications !!!
![ms-cert-path-mcpd_4[1]](http://igorshare.files.wordpress.com/2009/09/mscertpathmcpd_41.png?w=640&h=428 "ms-cert-path-mcpd_4[1]")
.gif)
]
– this becomes a habit and, at this rate, I can become an alcoholic too 
