Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Windows Workflow Foundation Essentials : Page 7

Applications that contain business processes and rules can benefit immediately from Windows Workflow's diagrams, class libraries, runtime, rules engine, and customization capabilities.

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 or false. 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 and Expression properties as shown in Figure 22. Set the ConditionName to CheckIfCustomerValid. 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 or Me, 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 or .vb 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.

Kevin McNeish is president of Oak Leaf Enterprises, Inc, and chief architect of the MM .NET Application Framework. He is a Microsoft .NET MVP and a well-known INETA speaker and trainer who's worked throughout North America and Europe, including at VSLive!, DevTeach (where he serves as one of the .NET chairs), SDC Netherlands, and Advisor DevCon. He is coauthor of the book "Professional UML with Visual Studio .NET," author of the book ".NET for Visual FoxPro Developers," writes articles, and has been interviewed for .NET Rocks! He spends about half his time on the road training and mentoring companies to build well-designed, high-performance .NET applications.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date