WF from Getting started to proficient (12th chapter): Policies and Rules

1. Know how to deal with policies and rules during workflow process

2. Understand the forward link and how it affects the rule-based workflow process

3. Create a rule for a workflow process

4. Use of rules in conjunction with policy activities

I'm sure most of us write process-oriented codes (imperative code) at ease. Code refers to C # code that programmatically implements the business process, such as reading a database table, increasing the values of some columns in the table, and then writing them all to a table in another database.

But in this chapter, we'll drill down to rules, a mechanism that controls the execution of a workflow, but it's considered declarative (declarative). Typically, declarative code is not compiled into an assembly, but is interpreted when the application executes. Many of the new features in ASP.net 2.0 are declarative, including data binding and improved template controls. They enable you to perform data binding or other complex control rendering tasks while writing asp.net applications without using C # code.

Windows Workflow Foundation (WF) also has declarative capabilities, but it binds rules and policies rather than data. You cannot use HTML or asp.net constructs to declare your rules, and of course the concepts involved are similar.

But what is the rule and what is the strategy?

Policies and Rules

When I write a program that involves data or business processes, I understand the data or business process and translate it into code that the computer executes. For example, consider a processing logic that examines the accounts: "If the value in the Availablebalance column is less than the required value, a Overdraftexception exception is thrown." "It seems very simple ... Here are some pseudocode for expressing this behavior:

IF (requestedValue > AvailableBalance) THEN
　　　　throw new OverdraftException("Insufficient funds.")

But what if a bank customer has an overdraft facility and can access the secondary account if the main account is underfunded? What if the customer does not have the overdraft function but can automatically set the overdraft range of the credit business? If customers have both ... Which one should we use?

As you can see, the code becomes both complex and confusing in order to examine the various situations. Worse, it is not easily ported to other business processes, and it can be difficult to maintain.

Further, we see that these are not just for data processing but also for the relationship between the numbers. In code, we use procedural processing to process relationships, which are often translated into many nested IF statements, swith statements, and loops. If you've used a lot of if statements in the process to check all possible conditions, you might want to ask yourself if there is no better way.

There's a better way to do it at least in WF. We can create declarative rules and then use the rule engine (Rules engine) to process them. Declarative rules describe relationships, and they are also appropriate for applications where the potential for judgment is to be applied.

WF hosts a rule engine (rules engine). The rules engine can use the rules encoded in XML format and can apply these rules to the methods and fields of your workflow. In WF, you can combine process-oriented code with declarative rules to form a general solution.

There are two main places in WF that use rule processing: Conditional processing and policy. You will find that conditional processing is part of the activities of IfElse, while, replicator, and ConditionedActivityGroup. If you look back at the 9th Chapter "Logical Flow Activities" and chapter 11th "Parallel Activities", in the activities of those local introductions and demonstrations, in each case I use a code condition to judge the processing process. Of course, the implementation of code conditions is an event handler in your workflow processing class (it is bound by a codecondition class provided by WF). However, in this chapter you will begin to use rule conditions for substitution. The strategy has not been used in this book until now, but it will be demonstrated in this chapter when I introduce the policy activity.

Note: For WF and rule-based processing you can write a complete book or even a series of books. It is impossible for me to cover all aspects of this chapter. But what you can do is introduce a couple of key concepts that are new to you and also provide you with WF based applications that demonstrate a specific aspect of the rule-based process. If you are interested in these topics, I strongly recommend that you spend some valuable time on Google (http://www.google.com/), and that a large number of websites have papers and materials on how to implement business processes in a workflow based system.

In WF, rules (rule) are represented by conditions that return a Boolean value and are accompanied by one or more operations. The regular style layout in WF follows the If-then-else style. The rule engine evaluates the condition, and then directs the workflow to execute according to the result of the conditional processing. To some extent, the rules are similar to scripting code and act as a script execution environment with the rule engine. The advantage of using rules on top of process-oriented code is that rules can be easily modified to make your part of the business process easier to adapt to volatile environments.

The policy in WF terminology refers to a collection of rules that are included in a rule set (RuleSet). This makes some things that are called forward links (forward chaining) more convenient, and this hypothetical term refers to the ability to redefine a rule after a change in the current processing rule results in a state change.