Windows Form tool for analyzing RuleSets, including rule-rule and rule-field dependencies
Author of the original sample: Jurgen Willis
This document is for informational purposes only. Microsoft makes no warranties, either express or implied, as to the information in this document. The entire risk of the use or the results from the use of this document remains with the user.
© 2006 Microsoft Corporation. All rights reserved.
When authoring complex Windows Workflow Foundation (WF) RuleSets, particularly those involving forward chaining, it can be a challenge to understand the implicit rule-rule dependencies that exist. It can also be a challenge to understand the relationships between fields/properties on the workflow and the rules that use and update those fields/properties. This tool is designed to help understand these relationships and understand how changes may impact ruleset evaluation.
This tool that provides the ability to:
This tool assumes that the user is already familiar with core WF Rules concepts such as forward chaining, priority-based execution, and method attributing.
The various windows and capabilities of the tool are described below.
A screenshot of the main tool window is shown in the Readme.mht file that is included in the sample folder.
From the File menu item, you Open a file that contains the ruleset to be analyzed. You must select a .rules file, e.g. one developed in the WF Visual Studio environment. After making changes you can write these changes back to a file using File-Save or File-Save As. If the .rules file contains more than one ruleset, you will be prompted to pick a specific ruleset for analysis.
When a ruleset is loaded, the target Type (this will typically be the workflow that the ruleset will execute against, but could be any .NET type) must be available to gather the rule side effect and dependency information. The tool will attempt to automatically load the associated type from the bin\Debug folder under the .rules file (if it exists). If it cannot find a matching type or finds multiple matching types, the user will be prompted to pick an assembly file and a type from that assembly, using the Activity Selector form.
At the top of the window are fields for the ruleset name and chaining behavior property on the ruleset. Below that, the Rules tree view provides a
list of all rules in the ruleset. Rules
are sorted by priority in descending order.
Expanding a node in the tree view for a rule will show Then and/or Else
nodes. Expanding the Then/Else nodes
will show the rules that are impacted by the Then/Else actions of the subject
rule. For example, in the screenshot
above, Rule01 has a Then action that updates the value of “this.flight.Price”;
expanding the Then node under Rule01 shows that Rule06, Rule07 and Rule08 all
have dependencies on Rule01’s Then action (i.e. they all read from the “this.flight.Price” value in their condition). Then/Else nodes are only shown under a given rule if these actions impact other rules. The level of nesting is not explicitly bounded.
The definition of a rule – its condition and actions – is shown on the right side of the window for the selected rule in the tree view. These fields are read-only; if changes need to be made to the rule’s condition or actions, this should be done in the authoring environment (e.g. Microsoft Visual Studio 2005) and then re-loaded in the Analyzer tool.
The rule properties, however, may be edited; these include the Priority, Active and Reevaluate properties (the Reevaluation Behavior property on a rule is an enum, but since there are currently only two valid values, it is presented as a Boolean on the UI).
Below the tree view is a “Filter” section with check boxes for Active, Priority and Reevaluation behavior. These checkboxes indicate whether the values of these properties should be considered when displaying the impacted rules in the tree view and Rule Relationships section.
For example, the Active check box should be checked if you do not want inactive rules to be shown in the tree view. Inactive rules will always be shown at the first level of the tree view (so that you can select them and change their Active value), but if the Filter-Active box is checked, then inactive rules will not be shown as nested rules. In other words since they are inactive, the firing of one rule will never cause them to be reevaluated. Inactive rules are always shown in a grey font to differentiate them from active rules.
If the Reevaluation behavior box is checked, then rules with a Reevaluate value of false will not be shown as dependent rules, since, generally, these rules are not reevaluated due to execution of another rule. The exception to this is that rules that executed no action when previously evaluated (e.g. they have no Then and/or Else actions) will be reevaluated. For simplicity in the tool, however, rules with a Reevaluate value of false are not shown as nested if this box is checked.
Finally, if you check the Priority box in the Filter section, then rules with a lower priority than the subject
rule will not be shown as being dependent on the subject rule (e.g. will not be
nested below the subject rule in the tree view). The reason is that firing of the subject rule
does not necessarily cause reevaluation of the impacted rule, since a lower
priority rule may already be scheduled for evaluation (e.g. it has not yet been
evaluated). The result is that only impacted rules with a higher priority are shown nested below the subject rule, since these will be reevaluated by virtue of execution of the subject rule. Note that this is purely for user convenience and does not necessarily map to actual execution behavior.
The default for the Filter section is that only the Active box is checked, since this represents actual execution behavior. Experimenting with the values for these check boxes should help you understand how they influence the relationships shown in the tree and determine which values are most helpful to your analysis. However, the default
configuration must be used to launch the Analysis Report and Execution Plan dialogs discussed below.
Below the Relect section is a Rule Relationships section. This shows
information similar to that shown in the tree view, but with a slightly
different focus. For a selected rule in
the tree view, the Rules Impacted box shows all rules that have a dependency on
the selected rule. In the default case,
this shows the same rules that are nested below the selected rule in the tree
view. However, you have more options in
this view. You can select whether you
want rules impacted by the Then and/or Else actions to be shown. In addition in the Action Side Effects combo
box you can select specific fields. Selecting a specific field, e.g. “this/flight/price”, will only show the
rules that have a dependency on that field. Only fields used in the actions of the selected rule are shown; they are
shown in the “path” syntax used by the engine (which allows for wildcards, etc.).
In addition, you can see the rules that the selected rule is dependent upon (i.e. those rules whose Then or Else actions write to a field/property used in the condition of the selected rule). As with the actions, you can select specific fields in the Condition Dependencies combo box to analyze the dependencies of specific fields/properties used in the rule’s condition.
The combo boxes in this section will show all fields/properties used in the rule’s conditions and actions,
irrespective of the value of chaining, active and priority fields. However, the Rules Dependent Upon and Rules
Impacted lists will reflect the values of the chaining, active and priority
fields if so dictated by the value of the Filter flags. In other words, the Filter check boxes will
impact these lists in the same way that the Rules tree view is
From the Tools menu item, you can select View Condition Relationships, which will launch a new window (screenshot included in the Readme.mht file that is included in the sample folder).
In the list on the left, you select
a field or property. These are fields on
the target activity that the ruleset is executed against, e.g. the
workflow. Nested references (e.g. access
of a property on an instance of a complex type that is a field on the workflow) are included, as are indirect field/property accesses via method calls. When a field/property is selected, the rules that use the field/property in their condition are shown on the right, as are the rules that update the field/property in either their Then or Else actions.
Note that this dialog is not impacted by the active, priority and chaining fields; it is focused purely on field-rule relationships.
From the Tools menu item, the View Execution Plan item launches a new window (screenshot included in the Readme.mht file that is included in the sample folder).
This window allows you to simulate the execution of a ruleset. When you first open the window, you will see the first rule in the ruleset that will be evaluated – e.g. the rule with the highest priority value. The check box on the rule node indicates if the rule should be assumed to evaluate to true or false. Expanding this node will show the next rule that would be evaluated.
In the example above, a result of True for Rule01 will result in Rule02 being the next rule evaluated. You can continue to check/uncheck nodes and expand nodes to simulate the full execution of the ruleset, including chaining behavior that will cause rule reevaluation. Note that the ruleset is not actually executed and there is no data being evaluated. This tool is simply allowing you to simulate the evaluation by specifying the true/false results of a rule evaluation.
From the Tools menu item, the View Analysis Plan item launches a new window (screenshot included in the Readme.mht file that is included in the sample folder).
The window is the output of two kinds of analysis that are performed – both intended to identify potential looping issues. The first section shows rules that chain on themselves, in other words, rules that update a field/property in their actions and use that same field/property in their condition. This scenario could cause the rules to be continually reevaluated. Of course, this is not necessarily the case depending on the data values during execution and how the condition/actions are authored. This report is simply intended to identify potential problems for the user to investigate.
The second part of the report identifies chains of rule evaluations that could cause an infinite loop. For example, in the first item in the screenshot above, Rule01 can cause the evaluation of Rule06, which can in turn cause the evaluation of Rule07, which may finally cause the reevaluation of Rule01. Again, this does not mean that an infinite loop will result, since the nature of the conditions/actions themselves may prevent this. This simply identifies some relationships for investigation or to help diagnose problems.
This analysis is very rudimentary in nature and is simply intended to provide information in support of a couple common looping issues, as well as to demonstrate the capability. The user is invited to extend this report analysis to provide more sophisticated and scenario-specific analysis capabilities.
No special setup is required to use this tool. Simply compile and run the solution. From the main menu of the tool, select File-Open, point to a .rules file and view the analysis information.