Breakout Session: Rules Driven Development

My last session of the day was the “Rules Driven Workflow in WWF”. The presentation was given by Jurgen Willis.

Check out their website for more information on WWF.

First off he went over some the basics in case people missed the Intro to WWF session. He then got a little more in depth.

Rules revolve around conditions. Conditions are simply providers that return a boolean to indicate if a rule passed or not. Conditions can be either Code based (i.e., typed code directly into the designer or class and called Code Conditions), or more dynamic (stored outside the code in some manner and loaded at run time, which is referred to as Rule Conditions).

If you have used Enterprise Library Security Authorization then you may liken the Rule Conditions to the conditional rules you type into the Rule Provider Engine window. They are simply statements that will be boiled down to a true or false based on context, data or state. They can be stored outside of the code and changed dynamically at runtime.

He showed several demonstrations on dynamically changing out the rules as workflow items were being processed. It was nice to see. I spoke with one of the WWF team members after the session and it sounded just as easy to provide a mechanism to ensure that workflow items that enter the workflow before a change to the rule sets are made could still be processed with the original rule set if necessary.

They also introduced the Conditional Activity Group or CAG. This is a container of activities that allow you to create series of activities that may be interwoven, sequential, etc. that all occur repeatedly until a specific condition, or combination of conditions, is met. For example, in a document review process you don’t want to continue with the work flow until 3 out of the 5 managers approve it. The CAG for this would contain 5 activities, one for each of the managers to approve the item. Once any one of the activities is completed then the CAG evaluates to see if all the required conditions are met. Once they are met then the workflow continues. So as each manager signs off the CAG waits until it gets the required number of approvals, then continues with the next activity in the workflow.

The speaker introduced the idea of Policy as a way to drive rule driven processing. A policy separates business logic from application sequencing. For example, if a set of rules is being applied to an object and one of the rules or activities happens to cause the object to change, the business logic that has already applied to object can be applied again if it makes sense to do so. The example he gave was if the first rule that is checked determines a discount based on the total being a specific amount, and then a later activity may increase the total amount, then the discount may now need to apply. The policy enforces the discount is applied. Of course, you can set priorities on rules and control this behavior.

A policy is not an actual activity, but a base class upon which to create your own activities.

You also have the ability to serialize a rule set for a policy out and dynamically load it.