Working with Flow of Control Activities
Now that the workflow can validate a customer, you can add a conditional statement to the workflow diagram to check the result of the validation and choose an appropriate course of action.
|Figure 20. Conditional Activities: The IfElse activity is a composite activity containing child activities that run when their conditions evaluate to true.|
To add the conditional statement, from the Solution Explorer, double-click ProcessOrderWorkflow
. Go to the Visual Studio Toolbox and under the Windows Workflow tab drag the IfElse
activity and drop it on the diagram directly below the validateCustomerActivity
as shown in Figure 20
. The IfElse
activity is a composite activity that contains other activities that are run conditionally. The activity executes the first branch with a true
condition (evaluated from left to right).
Notice the red error icon on the activity. If you click the icon's smart tag, it says Property "Condition" is not set
. The error tells you the Condition
property of the IfElse
activity must be set so it can perform an evaluation. To set it, select the left branch of the IfElse
activity, go to the Properties window, and then select the Condition
property. If you expand the Condition
property's drop-down, you'll find two types of conditions available: Code Condition and Declarative Rule Condition (see Figure 21
|Figure 21. Declarative Rule: You can specify either a Code Condition or a Declarative Rule Condition on conditional activities such as IfElse. |
Code conditions are custom code-containing methods that return either true
. You can perform any kind of elaborate checking you want in this method. However, the downside of using code conditions is that you can't modify the condition without recompiling.
|Figure 22. Creating Declarative Rules: You must set the Condition Name and Condition Expression when defining a declarative rule condition.|
In contrast, declarative rule conditions are stored as XML in the workflow's associated .rules
file. Therefore, you can potentially modify the declarative rule without recompiling the workflow.
In this case it makes the most sense to use a declarative rule condition. To do this, select "Declarative Rule Condition" from the Condition
property's drop-down. Click the plus (+
) sign next to the Condition
property to expand it. You'll see the ConditionName
properties as shown in Figure 22
. Set the ConditionName
. Next, select the Expression
property and click its associated ellipsis button, which displays the Rule Condition Editor.
If you are a C# developer, enter the following in the Condition edit box as shown in Figure 23
, and then click OK:
|Figure 23. Rule Syntax: You can use either C# or Visual Basic syntax when defining declarative rule conditions in the Rule Condition Editor.|
Or for Visual Basic developers:
Notice after you typed this
, IntelliSense popped up, allowing you to select any activity on the workflow diagram, or any property, event, or method of the diagram—another nice feature. Now that you have set the Condition
property, note that the IfElse
error icon is gone.
Next, change the name of the IfElse
branches so they are more descriptive of what's happening in the workflow. Select the left branch of the IfElse
in the designer, and in the Properties window set its Name
property to ifCustomerValid
. Next, select the right branch of the IfElse
, and set its Name
property to ifCustomerInvalid
. This makes it obvious to anyone looking at the workflow diagram what causes the different branches to execute.
You could go into much greater detail with this workflow, but for this article, just add two new activities that will act as placeholders; one for each branch of the IfElse
Now, go to the Solution Explorer, right-click the SequentialWorkflowConsole
project, and select Add → New Item from the shortcut menu. In the Templates pane, select Activity, and then in the Name text box, change the name of the activity to ProcessOrderActivity.cs
and click Add. Go to the Properties window and change the Base Class of the new activity to Activity as you did earlier in this article. Now add a second new activity, name it EmailOrderRejectionActivity
, and again change its base class to Activity.
|Figure 24. Conditional Workflow: The completed workflow runs activities depending on the result of the ValidateCustomer activity.|
Rebuild the solution and then go to the Solution Explorer and double-click the ProcessOrderWorkflow
to display the workflow designer. From the Visual Studio Toolbox SequentialWorkflowConsole
Components tab, drag ProcessOrderActivity
and drop it on the left branch of the IfElse
activity. Then go back to the Toolbox and drag EmailOrderRejectionActivity
and drop it on the right branch of the IfElse
activity. When you're finished, your diagram should look like Figure 24
Testing the Flow of Control
Now you're ready to test the flow of control in the workflow. Press F5 to begin executing the workflow, and press F10 to step through the workflow again. This time, the yellow trace indicator should go down the left branch of the IfElse
because the customer is hard-coded to be valid, proving that the flow of control works.
The key points to take away from this article are, first, that WF provides a visual representation of your business processes, making them easier to understand and configure. It pulls your business logic "out of the weeds" and into a diagram that provides much greater accessibility. Also, as mentioned earlier, unlike UML diagrams, WF diagrams do not become outdated when business processes change, because they are
the application's business processes.
WF also helps separate business logic as defined in activities from flow of control as specified in a workflow diagram. You can reuse your custom activities in multiple workflows and wire them together as needed in workflow diagrams using standard flow-of-control activities.
Even though this article covered a lot of ground, there are still many great features of Windows Workflow that remain to be explored. You should spend some time learning more about creating custom activities, how to take advantage of the dozens of built-in WF activities (including event-driven activities), persisting workflows to a database, and much more.