Search

Search:

Namespace:

Search Result
.
        • RuleConditionReference
.
.

Windows Workflow Foundation offers two condition types: CodeCondition and RuleConditionReference.

.

CodeConditionVersusRuleConditionReference

.
Summary
.

Why would you use a CodeCondition or a RuleConditionReference.

.

Advantages of a RuleConditionReference is that the actual rule is stored in a separate XML file with the extension .rules. This means that rules can be manipulated by other tools, for example made visible to business analysts, and even be changed at runtime.

.

The main advantage of a CodeCondition is that developers are more familiar with code so it may feel more natural for them. Another advantage is that complex logic may be harder to build using the rule editor than using the code editor. One confusing thing of the CodeCondition is that the result is not returned from the function but is set as the Result property on the ConditionalEventArgs property.

.
Summary
.

Programming Windows Workflow Foundation by Scott Allen If you enjoyed this article, you'll enjoy the book even more! Order now from Packt Publishing and save 10%! The base activity library in Windows Workflow contains general-purpose activities for constructing workflows. There are activities for control flow, transaction management, local communication, web services, and more. These activities appear on the toolbox window of the workflow designer. Some of these activities, like the CodeActivity, are simple. The job of the CodeActivity is to execute a block of code. Other activities, like the PolicyActivity, are more complex. The PolicyActivity can evaluate prioritized rules with forward chaining. We can build powerful workflows using just the activities inside the base activity library.

.

The Condition property of a branch can be either a declarative rule (which the designer persists to an external .rules file in XML format), or a code condition (an event handler). If we set the condition equal to Declarative Rule Condition, then we can launch the rule condition editor from the properties window and enter an expression. For instance, if the workflow has an integer property named Sales, we could enter an expression like the following.

.

Like the IfElse activity, the While activity has a Condition property which can be either a declarative rule or a code condition. The WhileActivity will continue to run as long as the condition returns true. This activity will evaluate the condition before each iteration (see Figure 3).

.

The InitialChildData property will hold the list of data objects for the Replicator to process. The Replicator will create a clone of its child activity to process each item. The Replicator will not finish execution until all the children have finished, however, there is an UntilCondition property that the Replicator will evaluate before starting, and after completion of each child. If the UntilCondition returns true, the Replicator will finish execution, even if it leaves children unprocessed. Like other conditions in WF, the UntilCondition can be a rule condition or a code condition.

.

Conditions and Rules

.

Two activities in Windows Workflow thrive on conditions and rules. These activities are the Policy Activity and the Conditioned Activity Group (CAG). Although we could have listed the CAG as a control flow element, the CAG doesn't control the flow of execution as much as it is controlled by conditions and rules.

.

The CAG is a powerful activity that can use a combination of rules and code to reach a goal. The CAG conditionally executes activities until a condition evaluates to true. Inside of the CAG is a storyboard where we can drop activities for execution (see figure 11). The CAG associates a WhenCondition with each activity, and the CAG will only execute an activity if the activity's WhenCondition evaluates to true. The CAG continues to re-evaluate the WhenCondition and re-execute the storyboard activities until its own UntilCondition evaluates to true.

.

The WhenCondition and UntilCondition properties can use either declarative rules or code conditions. If we do not specify a WhenCondition for an activity, the activity will execute only once. If we do not specify an UntilCondition for the CAG, the CAG will continue to execute until all its activity's WhenCondition conditions return false.

.

The Policy activity is a rules engine that allows us to separate business logic from the workflow and declaratively define a business policy. Rules are everywhere in the business world - from calculating loan approvals to admitting patients into a hospital. A Rule Set is a collection of rules for the Policy activity to execute, and each rule has conditions and actions. We can edit the rules using the WF Rule Set editor, shown in figure 12.

.

Notice each rule has a priority assigned. Rules with a higher priority will execute before rules with a lower priority. Each rule has an If-Then-Else format, and we can assign actions to both the Then and Else results. A rule's actions can modify the fields and properties of a workflow, or the fields and properties of an object inside the workflow. Actions can also invoke methods.

.

By default, the Policy activity will execute the rule set using full forward chaining. If a rule changes the value of a field that some previous rule depended upon, the Policy activity will re-evaluate the previous rule. The Policy activity supports different forward chaining strategies, and each rule has a re-evaluation setting to control the number of times it can be re-evaluated.

.
Redirect
.

This page was automatically generated when this topic (DecimalRuleConditionCompileError) was renamed to DecimalRuleConditionError on 7-12-2006 at 19:12 by MauriceDeBeijer-83.68.25.26.

.

RuleConditions can have problems when using decimal types and comparing them to constant values.

.

Programming Windows Workflow Foundation by Scott Allen If you enjoyed this article, you'll enjoy the book even more! Order now from Packt Publishing and save 10%! The base activity library in Windows Workflow contains general-purpose activities for constructing workflows. There are activities for control flow, transaction management, local communication, web services, and more. These activities appear on the toolbox window of the workflow designer. Some of these activities, like the CodeActivity, are simple. The job of the CodeActivity is to execute a block of code. Other activities, like the PolicyActivity, are more complex. The PolicyActivity can evaluate prioritized rules with forward chaining. We can build powerful workflows using just the activities inside the base activity library.

.

The Condition property of a branch can be either a declarative rule (which the designer persists to an external .rules file in XML format), or a code condition (an event handler). If we set the condition equal to Declarative Rule Condition, then we can launch the rule condition editor from the properties window and enter an expression. For instance, if the workflow has an integer property named Sales, we could enter an expression like the following.

.

Like the IfElse activity, the While activity has a Condition property which can be either a declarative rule or a code condition. The WhileActivity will continue to run as long as the condition returns true. This activity will evaluate the condition before each iteration (see Figure 3).

.

The InitialChildData property will hold the list of data objects for the Replicator to process. The Replicator will create a clone of its child activity to process each item. The Replicator will not finish execution until all the children have finished, however, there is an UntilCondition property that the Replicator will evaluate before starting, and after completion of each child. If the UntilCondition returns true, the Replicator will finish execution, even if it leaves children unprocessed. Like other conditions in WF, the UntilCondition can be a rule condition or a code condition.

.

Conditions and Rules

.

Two activities in Windows Workflow thrive on conditions and rules. These activities are the Policy Activity and the Conditioned Activity Group (CAG). Although we could have listed the CAG as a control flow element, the CAG doesn't control the flow of execution as much as it is controlled by conditions and rules.

.

The CAG is a powerful activity that can use a combination of rules and code to reach a goal. The CAG conditionally executes activities until a condition evaluates to true. Inside of the CAG is a storyboard where we can drop activities for execution (see figure 11). The CAG associates a WhenCondition with each activity, and the CAG will only execute an activity if the activity's WhenCondition evaluates to true. The CAG continues to re-evaluate the WhenCondition and re-execute the storyboard activities until its own UntilCondition evaluates to true.

.

The WhenCondition and UntilCondition properties can use either declarative rules or code conditions. If we do not specify a WhenCondition for an activity, the activity will execute only once. If we do not specify an UntilCondition for the CAG, the CAG will continue to execute until all its activity's WhenCondition conditions return false.

.

The Policy activity is a rules engine that allows us to separate business logic from the workflow and declaratively define a business policy. Rules are everywhere in the business world - from calculating loan approvals to admitting patients into a hospital. A Rule Set is a collection of rules for the Policy activity to execute, and each rule has conditions and actions. We can edit the rules using the WF Rule Set editor, shown in figure 12.

.

Notice each rule has a priority assigned. Rules with a higher priority will execute before rules with a lower priority. Each rule has an If-Then-Else format, and we can assign actions to both the Then and Else results. A rule's actions can modify the fields and properties of a workflow, or the fields and properties of an object inside the workflow. Actions can also invoke methods.

.

By default, the Policy activity will execute the rule set using full forward chaining. If a rule changes the value of a field that some previous rule depended upon, the Policy activity will re-evaluate the previous rule. The Policy activity supports different forward chaining strategies, and each rule has a re-evaluation setting to control the number of times it can be re-evaluated.

.

Either a CodeCondition or a RuleConditionReference can be used for each branch.

.

Netfxlive is an intent to make a central activity repository. The purpose is provide a live workflow designer where anyone can build a workflow out of all activities uploaded to the repository. Workflow activities declarations, rules and binding capabilities are powerful enough to build complex business logic on top of world wide shared activities. Activities can also be service proxies, thus invoking remote WCF services. WF appears to be a nice interface for service discoverability.

.
Summary
Represents a collection of Rule class instances to be run as part of a workflow's execution as a single step/activity.
.

Represents a collection of Rule class instances contained in a RuleSet to be run as part of a workflow's execution as a single step/activity.

.

TracingRuleSet

.

And thinking about how WF/WCF conversations works this restriction makes sense. After all a ReceiveActivity is called without a context in order to create a new workflow, assuming the CanCreateInstance property equals true, and returns the workflow instanceId in the context as part of the response. This design kind of rules out one-way messages and thereby NetMsmqBinding.

.
Summary
.

A Rule is basically an If (condition) Then (action) else (action) construct used in PolicyActivity and a RuleSet.

.

Normally the RuleSet can automatically determine dependencies between rules based on the properties they set. However when functions are called the RuleSet no longer has this capability without help. Use the RuleReadAttribute, RuleWriteAttribute and the RuleInvokeAttribute to manually indicate dependencies on properties.

.
Summary
Represents a Rule Condition in the conditions collection and enables you to programmatically evaluate the condition.
.

CodeConditionVersusRuleConditionReference

.

See also: DecimalRuleConditionCompileError

.
Summary
A RuleSet is a collection of Rules to be executed.
.

A RuleSet is stored in an XML file with the same name as the workflow and the extension .rules. Basically they are stored as an XML representation of a CodeDom object. The same rules file also contains all the Declarative Rule Condition used in the Workflow.

.

A RuleSet executes Rules base on their order from high to low.

.

Depending on the RuleSetChaining setting:

.
  • FullChaining: If a Rule sets a property and an already executed rule depends on this it will be reevaluated. Do not confuse FullChaining with the kind of backtracking behavior found in some ArtificialIntelligence software.
.
  • ExplicitUpdateOnly: Chaining occurs only when the Update() function is used in a Rule.
.
  • Sequential: Each Rule will be evaluated only once.
.

First, let's fully understand the ActivityExecutionContext. This object is passed to all scheduled calls either as a specific parameter (Execute, Cancel, HandleFault) or as the sender (QueueItemAvailable handler, StatusChanged handler). The ActivityExecutionContext provides the activity writer with an interface for controling activity execution (hence the first two words in the name) while giving the runtime enough control to enforce the rules of the WF engine.

.

But what about the "Context" part of the name? A context in WF is a sphere of execution. There is a root activity for each context and only activities which exist in that context can be executed in that context. In short, a context is a mechanism used by the runtime to determine on which set of activities to enforce rules.

.
Summary
One of the problems with RuleSets is tracing what rules are firing, when and why.
.

The PolicyActivity is rather cool but with more than a few rules in the RuleSet and full chaining enabled it can become a bit hard to see what is going on. Now it would be nice if we could step through the rules with the debugger but if there is a way I haven't found it yet. Of course you could add Console.WriteLine statements to the actions, after all they can be multiple statements. There is however an easier way that will show exactly what the runtime engine is doing and that is tracing.

.
      <add name="System.Workflow.Activities.Rules" value="Verbose" />
.

And run the workflow again. This time the Immediate Window will contain a trace with all rules being loaded and their dependencies. After that the trace will contain all evaluations of conditions and results thereof. The following is an example of a small RuleSet I created:

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "+5%" Condition dependency: "this/amount/"

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "+5%" THEN side-effect: "this/rate/"

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "10%" Condition dependency: "this/age/"

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "10%" THEN side-effect: "this/rate/"

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "50%" Condition dependency: "this/age/"

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "50%" THEN side-effect: "this/rate/"

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "Calc" Condition dependency: "this/"

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "Calc" Condition dependency: "this/amount/"

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "Calc" Condition dependency: "this/rate/"

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "Calc" Condition dependency: "this/discount/"

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "Calc" THEN side-effect: "this/discount/"

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "+5%" THEN actions trigger rule "Calc"

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "10%" THEN actions trigger rule "Calc"

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "50%" THEN actions trigger rule "Calc"

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "Calc" THEN actions trigger rule "Calc"

.

System.Workflow.Activities.Rules Information: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Executing

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Evaluating condition on rule "+5%".

.

System.Workflow.Activities.Rules Information: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "+5%" condition evaluated to True.

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Evaluating THEN actions for rule "+5%".

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Evaluating condition on rule "10%".

.

System.Workflow.Activities.Rules Information: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "10%" condition evaluated to True.

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Evaluating THEN actions for rule "10%".

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Evaluating condition on rule "50%".

.

System.Workflow.Activities.Rules Information: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "50%" condition evaluated to True.

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Evaluating THEN actions for rule "50%".

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Evaluating condition on rule "Calc".

.

System.Workflow.Activities.Rules Information: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "Calc" condition evaluated to True.

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Evaluating THEN actions for rule "Calc".

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "Calc" side effects enable rule "Calc" reevaluation.

.

System.Workflow.Activities.Rules Verbose: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Evaluating condition on rule "Calc".

.

System.Workflow.Activities.Rules Information: 0 : Rule Set "Rule Set1": InstanceId 4c453688-cb02-41e9-a641-39921711d2a0: Rule "Calc" condition evaluated to False.

.

Rather nice as you can see exactly what is going on. Just make sure you name your rules well otherwise it will still be somewhat hard to follow.

.
      <add name="System.Workflow.Activities.Rules"    value="Verbose" />
.

The best way to look at a workflow is as a schematic description of a real world problem - alternatively the automation of a business process , during which ducuments or tasks are passed along agents for activities to take place according to pre-defined rules. For example: If an order is placed, check if we have enough inventory and if not create a purchase order and send it to the supplier, notify the account manager by email of the expected delivery date the supplier specified. These activities are modeled in a graphical way making the workflow much more understandable. The activities themselves, like sending an email, are done in traditional C# or Visual Basic .NET code in such a way that they are unaware of their context, all they know is that they have to send an email as told by the workflow.

.

WindowsWorkflowFoundation is basically a library consisting of an execution engine, a rules engine, a number of activities, a number of supporting runtime services and a designer allowing developers to design their workflows graphical in VisualStudio2005 (VS2005). In fact it even includes a graphical debugger allowing the developer to step through the workflow and even into the underlying .NET code. The engine is designed in such a way that the developer has a free choice between building the workflow as code constructs or in a declarative fashion using XAML. Either way he can use the graphical designer the same way, all that changes is the output. Because the runtime engine has the capability of parsing and executing the XAML itself we have tremendous flexibility in our workflows. There is no need to compile them at the same time as the rest of the application. This flexibility even goes further and the engine allows for the runtime alteration of the executing workflow, how about that for flexibility!

.

When creating a subclass overrule the abstract PerformLoad function to load the workflow. Use the GetService function to retreive a IDesignerHost reference and use its Container object to add all the workflow activities to the designer surface. See the WorkflowUtils GetAllActivities function for an easy way to get a reference to all nested activities.

.

XomlAndDeclarativeRules

.
Summary
.

When using code based workflows with DeclarativeRules you can use an expression like:

.

in the RuleConditionEditor and everything works just fine. When you create a XOML based workflow this does not work. The activities added have a private scope and are not visible by the rules engine. The expression above, even though the RuleConditionEditor claims it is perfectly valid, will produce an error with the following text:

.

Changing the DeclarativeRules expression to: