Business Rules and Windows Workflow Foundation

The business rules framework in Windows Workflow Foundation offers a great deal of functionality and flexibility. Everything from the simplest single rule to more complex sets of rules with involved execution logic is provided in the workflow API.

The classes that support rules in Windows Workflow Foundation exist in System.Workflow.Activities.Rules and System.Workflow.Activities.Rules.Design, and are discussed in this chapter. In addition, there are other rule-related entities throughout the API. For example, several activities are heavily tied to rules. This chapter also discusses these activities and how they are related to rules.

Before the chapter dives too deep into the world of rules, the next section covers code conditions - a simpler form of programmatic logic.

Code Conditions

When you think of rules, generally the most common trait that comes to mind is a Boolean condition. For example, comparing a number to a variable to see whether the number is larger than the variable produces a Boolean output. For simple Boolean checks, the code condition provides a programmatic way to define these expressions. Code conditions are represented by the CodeCondition class and are executed when its Evaluate method is called.

A few activities give you the option of using code conditions or rules when a condition is required. For example, the IfElseBranch activity has a property called Condition that requires you to choose the type of condition to use. The following code checks a variable to see whether it is greater than 200, and if so, it sets the Result property to true on the ConditionalEventArgs object that is passed to the method. All activities that allow the use of code conditions require the following method signature:

  private void IsLargeOrder(object sender, ConditionalEventArgs e) {     e.Result = this.orderTotal > 200; } 

Although code conditions provide a simple way to specify Boolean values, there are some advantages to using rules over code conditions. First, rules allow dynamic updates, meaning that the conditions and subsequent actions can be updated during runtime if warranted. In addition, rules offer a rich authoring environment and a more customizable infrastructure, allowing them to be stored in a multitude of mediums. This includes XML out of the box, but the infrastructure could be extended to include stores such as SQL Server.

The Anatomy of Rules

In Windows Workflow Foundation, there are two different types of rules: declarative rules and rule sets.

Declarative Rule Conditions

Declarative rules are expressions that evaluate to true or false. This simpler form of rules is used in activities that require a Boolean expression to function, such as an IfElseBranch or While activity. Other activities that rely on rules are discussed a little later in the chapter.

There are no limitations on how rules are used in Windows Workflow Foundation because the platform is so extensible. You can develop custom activities to use rules, and, as you will see later, rules can be used programmatically and do not have to be used with activities at all.

Because declarative rule conditions are simply Boolean expressions, they are easy to read and create. The following is an example of a declarative rule condition that checks to see whether a customer is old enough to rent a car:

  this.customer.Age >= 25 

This rule could be referenced by an IfElseBranch activity to conditionally execute its child activities. If the condition is not met, the next branch is evaluated until a condition is eventually met or an else branch is reached.

Rule Sets

Rule sets are where the power of rules becomes evident. They are considerably more flexible than declarative rule conditions and provide quite a few more options for rule execution, also called evaluation. Rule sets are quite different from declarative rules; however, at the heart of things, they both provide a flexible architecture of maintainable rules.

The first and most obvious difference between declarative rules and rule sets is that as the name implies, rule sets can contain many rules. A set provides a container for rules that are presumably related to the same business problem domain. The rule set exposes an option applied to the set as a whole that specifies the behavior to be used during evaluation. This option, referred to as chaining, is discussed in detail later in this chapter. Briefly, chaining describes how rules are evaluated and reevaluated when properties on which the rules depend are changed.

The rules contained within rule sets are also different from individual declarative rule conditions. Instead of simply having a Boolean expression, rule set rules also have actions associated with them. Actions are analogous to the code within a C# if or else block. These actions are referred to as THEN and ELSE statements. However, you can develop custom actions.

Individual rules also have a few properties associated with them that are not applicable to declarative rule conditions. The first such property is a rule’s priority. This value is coupled with the chaining option mentioned previously and states the order in which a rule should be evaluated related to other rules in the set. In the rule priority scheme, higher numbers are evaluated first.

Another rule property related to chaining is the reevaluation property. Possible values include always and never, which specify whether a rule is to be reevaluated if and when properties on which the rule is dependent are modified. Again, chaining with a reevaluation property is discussed in greater detail a little later.

The final rule-specific property is the active property. This value is represented by a check box in Visual Studio and specifies whether a rule should be evaluated at all. If the value is set to false or unchecked, the rule is ignored during runtime and has no impact on the outcome of the set’s evaluation.

To give you an idea of how you can use rule sets, consider a set that specifies certain business rules related to an organization’s new hire process. You could establish a rule that checks a candidate’s years of experience against a job opening’s requirements, as shown in the following example:

IF:

  candidate.YearsOfExperience >= job.MinimumYearsOfExperience 

THEN:

  isValidCandidate = true 

ELSE:

  isValidCandidate = false 

The rule set could also contain other rules that check for things such as whether the candidate has been convicted of a felony, all technical requirements are met, or the candidate is willing to relocate if the job’s city is different from the candidate’s current city of residence.

Windows Workflow Rules Language

You define rules in Windows Workflow Foundation using a syntax that isn’t quite C# or Visual Basic .NET but is close to both. Because rules aren’t much more than simplistic IF-THEN-ELSE statements, the syntax doesn’t need to be that complex.

You can access fields, properties, and methods using the standard dotted notation, as with C# and Visual Basic .NET. The following is a simple IF statement that checks to see whether the customer placing an order is a Platinum customer:

  this.customer.CustomerType == CustomerType.Platinum 

Next is what could be a corresponding THEN statement:

  this.order.Discounts.Add(new Discount(.15)) 

And the following is a possible ELSE statement:

  this.order.Discounts.Add(new Discount(.05)) 

As you can easily ascertain, Platinum customers receive a 15 percent discount in this example, and other customer types receive only a 5 percent discount. In addition, the THEN and ELSE statements can access the order object’s Discounts collection by calling order.Discounts. The rule could have just as easily referenced a method off the order object - perhaps one called SetDiscount.

A rule can reference any object that can be accessed in a workflow’s code file. In the preceding example, there is a class field called order, which is why it is referenced with the this qualifier. The same goes for methods in the workflow code file. You can place more complex logic in an actual C# or Visual Basic .NET code file and then reference it as a method call from within a rule.

The following three tables list the expressions that you use in the rules language. Table 9-1 lists the relational expression operators that allow values, objects, and such to be compared with the output of true or false. The same types of expression operators exist in C# and Visual Basic .NET. If you use the Visual Basic .NET style of equality operators (= and <>), they are automatically changed to the C# style (== and !=).

Table 9-1: Rule Expressions
Open table as spreadsheet

Expression	Expression Symbols
Equal	==, =
Not Equal	!=, <>
Greater Than	>
Greater Than or Equal	>=
Less Than	<
Less Than or Equal	<=

Table 9-2 lists the arithmetic-related operators available in rule expressions. You can use these operators in the IF portion of a rule or in the THEN or ELSE portion. For example, you could use them in the IF statement to compare a value with another value plus or minus a number you specify. Or you could use these operators in the THEN or ELSE statement to modify a value based on the outcome of the rule.

Table 9-2: Arithmetic Operators
Open table as spreadsheet

Arithmetic Operation	Operator Symbols
Addition	+
Subtraction	-
Multiplication	*
Division	/
Modulus	MOD

Table 9-3 shows the operators that join Boolean expressions into larger, more complex Boolean expressions. As with the comparison expressions, workflow rules allow either C# or Visual Basic .NET flavors of expression joiners. However, when you use the Visual Basic .NET style operators, they are automatically translated to the C# style.

Table 9-3: Expression Joiners
Open table as spreadsheet

Expression	Operator Symbols
And	&&, AND
Or	||, OR
Not	!, NOT
Bitwise And	&
Bitwise Or	|