- Describing Workflow and Workflow Systems
- .NET Framework 3.0 and 3.5
- Overview of WF
- Standard Modeling Activities
- Multiple Workflow Styles
- Hosting
- Tracking
- Rule Capabilities
- Custom Activities
- XAML Workflows and Serialization
- Dynamic Update
- WF and WCF
- SharePoint Workflow
- Designer Rehosting and External Modeling
- Summary
- Installation Instructions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Standard Modeling Activities
Activities are the unit of design and execution in WF. WF comes with a set of modeling constructs that it calls activities and a workflow designer (see Figure 1.3). The activities are dragged and dropped from the toolbox onto the workflow designer. The properties of the activities are then set. A workflow is the composition of the activities placed on the workflow designer.
)
Figure 1.3 Workflow designer and activities.
WF ships with approximately 30 activities. It calls these activities the Base Activity Library (BAL). The activities are largely segmented as follows: control flow activities, activities that facilitate data exchange between the workflow and the application running the workflow (a Windows Forms application, for example), one that permits arbitrary code to be written, and another group that supplies exception handling.
The control flow activities include a Sequence activity that is a shell for other activities. It is equivalent to {} in C#. It is a block where activities may be added. A Sequence activity can hold a tree of activities, as you will see in Figure 1.10 when its sequential workflow cousin is discussed. Figure 1.4 shows a Sequence activity that contains two other activities.
){kind=link}
)
Figure 1.4 The Sequence activity.
The While (Figure 1.5) activity loops while the condition associated with it remains true. There is a condition not seen in the figure. Conditions are discussed in the "Rule Capabilities" section of this hour.
)
Figure 1.5 The While activity.
The IfElse (Figure 1.6) activity holds one or more branches that are each governed by a condition. The first branch to return true is executed; no other branches are executed.
)
Figure 1.6 The IfElse activity.
Another control flow activity is the Listen (Figure 1.7) activity that allows two or more branches to be added that each wait for an external event. The left branch, for instance, may wait for approval and the right branch for rejection. A timer may also be placed in a Listen activity branch. The branch that receives the first event executes unless the timer goes off first, in which case the timer branch executes. The Listen activity supports a prototypical workflow pattern to wait one or more responses and then timeout if response is not received within a specified duration.
)
Figure 1.7 The Listen activity.
A Parallel activity executes two or more branches concurrently. (Branches are actually executed in an interleaved fashion as described in Hour 8, "Working with Parallel Activities and Correlation.") The Parallel (Figure 1.8) activity will wait for all branches to complete before completing.
)
Figure 1.8 The Parallel activity.
Advanced control flow activities include the Replicator activity, which can process a number of elements specified at runtime and can do so in serial or parallel. It is similar to the C# foreach statement with the additional capability to process in parallel as well as sequentially. This activity is critical to document approval and other scenarios that have different numbers of approvers on different instances and therefore require the number of approvers to be specified at runtime. The EventHandlingScope activity is similar to a Listen activity but it allows the events to be received multiple times. The combination of the Replicator and EventHandlingScope activities power much of the OOB SharePoint workflows that require the number of participants (approvers) to be specifiable at runtime and must be changeable throughout the workflow life cycle.
The data exchange activities include CallExternalMethod and HandleExternalEvent. The first is used to send data from the workflow to the application running the workflow (the host). The latter allows data to be sent from the host to the workflow. There is also a set of activities to expose a workflow as a web service (WebServiceOutput and WebServiceInput) and call a web service from a workflow (InvokeWebService). Finally, Send and Receive WCF activities exist that can be used only with .NET 3.5. The Send activity is used to connect to a WCF endpoint (or any compatible endpoint) from a workflow. The Receive activity is used to expose a workflow as a WCF Service.
The Code (Figure 1.9) activity points to a handler with standard .NET code. It can be used to add custom functionality to a workflow, although in many cases it is better to use a custom activity, as discussed in the upcoming Custom Activities section.
)
Figure 1.9 The Code activity and handler code.