Windows workflow activity tutorial

In Visual Studio Installer, select the Individual components tab. Then, under the Development activities category, select the Windows Workflow Foundation component.

Choose Modify to install the component. Select the Activity Library project template. Right-click Activity1. Click OK to confirm. Select Code Activity from the Workflow list. Type ReadInt into the Name box and then click Add. Building the project enables the ReadInt activity in this project to be used to build the custom activity from this step.

Select Activity from the Workflow list. Double-click Prompt. Activities move through various stages in the life cycle of the workflow. Windows Workflow Foundation includes a set of out-of-the-box activities. These are available in the Visual Studio toolbox and ready to be configured to be used.

Following is a listing of some of the commonly used activities. Composite Activities. Conditional Activites. Conditions can be expressed in one of the following ways. Policy activities are a collection of simple rules and enable forward chaining. Forward chaining is the ability of the actions of one rule to cause other dependent rules to be re-evaluated.

State Workflow Activities. The following activities are used for creating State Machine workflows. Event Driven Activites.

External Operations. Custom Activities. The workflow foundation provides a number of activities out of the box. Windows Workflow Foundation can implement business logic as either rules or conditions. Conditions can be expressed as declarative, or defined in code. Rules include a condition statement and collections of actions that are performed based on the result of the condition.

Rules are collected into rule sets, which support both simple sequential execution of rules, and sophisticated forward-chaining of rules. Rule sets are executed by the PolicyActivity activity. A key advantage of defining your logic with rules and declarative conditions is that they can be modified at run time by doing dynamic updates using workflow changes.

In addition, rules let you separate your business logic from a workflow in order to share those rules with other workflows.

Finally, defining business logic in rules allows for advanced tools, such as dependency visualization and impact analysis tools, to be built on top of the object model. Exceptions that occur in activities are handled asynchronously by the workflow runtime engine in a process called fault handling.

Exceptions are scheduled in a queue to be handled later. If the exception type matches the one that is handled by a particular FaultHandlerActivity activity, that activity will handle the exception. If the exception cannot be handled, it is bubbled up through parent activities until it ultimately causes the termination of the workflow instance. Workflow markup, which is based on Extensible Application Markup Language XAML , enables developers and designers to model business logic declaratively and separate it from lower-level implementation details that are modeled by code-beside files.

Because workflows can be modeled declaratively, it is possible to activate a workflow by directly loading a workflow markup file into the workflow runtime engine at run time. Correlation is the mechanism for relating workflow service messages to each other or to the application instance state, such as a reply to an initial request, or a particular order ID to the persisted state of an order-processing workflow.

Correlation can be protocol-based or content-based. Protocol-based correlations use data provided by the message delivery infrastructure to provide the mapping between messages. Messages that are correlated using protocol-based correlation are related to each other using an object in memory, such as a RequestContext , or by a token provided by the transport protocol.

Content-based correlations relate messages to each other using application-specified data. Messages that are correlated using content-based correlation are related to each other by some application-defined data in the message, such as a customer number.

Activities that participate in correlation use a CorrelationHandle to tie the messaging activities together. For example, a Send that is used to call a service and a subsequent Receive that is used to receive a callback from the service, share the same CorrelationHandle. This basic pattern is used whether the correlation is content based or protocol based. The correlation handle can be explicitly set on each activity or the activities can be contained in a CorrelationScope activity.

Activities contained in a CorrelationScope have their correlation handles managed by the CorrelationScope and do not require the CorrelationHandle to be explicitly set. The first topic in the tutorial leads you through the steps to create the custom activities required for the workflow. In the second topic, these activities are assembled along with built-in workflow activities into a flowchart workflow.

In the third topic, the host application is configured to run the workflow, and in the final topic persistence is introduced. Each step in this process depends on the previous steps, so we recommend that you complete them in order. How to: Create a Workflow Describes how to create flowchart, sequential, and state machine workflows by using built-in activities and the custom activities from the preceding tutorial.