WF are not only for business (part 3): Marrying Workflows into PowerShell (Part 1 of 2), PowerShell Rules Engine
Posted by Igor Moochnick on 02/15/2008
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:
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:
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.