How to: Create a Branching Workflow

發行項
07/28/2014

Applies to: Office 2010 | Project 2010 | Project Server 2010 | SharePoint Server 2010

Governance workflows in Microsoft Project Server 2010 are used to help manage project proposals and portfolio analyses. The example in this article is a basic governance workflow that integrates with three stages in the Create phase of demand management and a fourth stage in the Manage phase. The BranchingWorkflow example uses the default stages installed with Project Server 2010. (This article is adapted from content by Sam Chung, Microsoft Corporation.)

Note

This article is based on the use of Microsoft Visual Studio 2010. Before you start to develop a workflow for Project Server 2010, see the information in How to: Configure Visual Studio 2010 for a Project Server Workflow.

This article includes the following sections:

Creating a Branching Workflow for Multiple Stages
- Planning a Multi-Stage Workflow
- Creating a Project Server Workflow
Adding Project Server Workflow Activities
- Binding a Workflow Activity to a Stage
- Updating the Stage Status
- Creating a Comparison Activity
- Creating an If – Else Branch
- Binding the IfTrue Branch to Proposal Details
- Binding the IfFalse Branch to Automated Rejection
- Binding to the Final Execution Stage
Complete Code Example

Important

Workflows developed for pre-release versions of Project Server 2010 must be modified to dispose of the workflow context and workflow properties (as in Procedure 1b), and then recompiled and redeployed for the released version.

To deploy a workflow on a production Project Server computer, or to update a workflow if you make a code change, see How to: Deploy a Project Server Workflow for information about how to create a SharePoint solution package and update the workflow.

If you are using Visual Studio 2010 to install a workflow on a test installation of Project Server, see How to: Install and Test a Project Server Workflow.

For an introduction to workflow concepts in Project Server 2010, see Workflow and Demand Management.

Creating a Branching Workflow for Multiple Stages

Project Server workflows for demand management are sequential workflows. Although a state machine workflow can have options to save and return to previous states, the demand management processes and related project details pages require sequential workflows.

Following are the general steps for creating a multistage branching workflow development project.

Plan the workflow project and design the sequential flow of logic with workflow activities.

Tip

Microsoft Visio 2010 can help you diagram workflow activities and logic before you create the activities with the SharePoint workflow designer in Visual Studio.
In Visual Studio, create a SharePoint 2010 workflow project and add the Project Server workflow framework.
Develop the workflow with Project Server activities and SharePoint activities. Link the activities to stages in the demand management process.
Compile and deploy the workflow. For more information, see How to: Install and Test a Project Server Workflow.

Planning a Multi-Stage Workflow

A Project Server workflow can integrate with multiple stages and phases in a demand management process. Because workflows and stages can be complex, it is necessary to thoroughly understand the business requirements and plan a workflow carefully before starting the development project.

To see the workflow phases installed with Project Server 2010, start Project Web App, click Server Settings in Quick Launch, and then click Workflow Phases in the Workflow and Project Detail Pages section. The default workflow phases are Create, Select, Plan, Manage, and Finished. To see the workflow stages in each phase and the related custom fields, click Workflow Stages on the Server Settings page. For example, the Create phase includes Initial Proposal Details, Proposal Details, Automated Rejection, and other stages; the Manage phase includes the Execution stage.

Figure 1. Phases and stages in Project Web App

Phases and stages in Project Web Access

Figure 2 shows the basic design of the simple branching workflow example in this article, using the Workflow Diagram template in Visio. The workflow starts with the Initial Proposal Details stage. A workflow activity gets the cost of the proposed project from a custom field set by the Initial Proposal Details stage. In this example, if the cost exceeds $25,000 USD, the workflow goes to the Automated Rejection stage; otherwise, the workflow proceeds to the Proposal Details stage, waits for completion of the associated project detail pages (PDPs), and then moves to the Execution stage where the user can begin managing the project.

Figure 2. Designing a workflow with the Visio Workflow Diagram template

Designing a workflow with Visio

Creating a Project Server Workflow

The framework for a Project Server sequential workflow includes a ProjectSequence activity that contains all of the other workflow activities. Each activity must be set to the same WorkflowContext property.

Procedure 1. To create the workflow project

Run Visual Studio as an administrator. Create a project that uses the SharePoint 2010 Sequential Workflow template. To create the project, see How to: Configure Visual Studio 2010 for a Project Server Workflow. For example, name the project BranchingWorkflow in the New Project dialog box. Ensure that the target framework is Microsoft .NET Framework 3.5.
On the Specify the workflow name for debugging page of the SharePoint Customization Wizard, name the workflow BranchingWorkflow – BranchingWorkflow.

Click Site Workflow, and then click Next in the wizard. Accept the remaining default settings to finish the wizard.

Note

If you create a new sequential workflow project, ensure that you click Site Workflow in the SharePoint Customization Wizard.
The default workflow file is named Workflow1.cs. Open both the design view and the code view. The Workflow1 class derives from SequentialWorkflowActivity, which enables the workflow design view pane to be named Sequential Workflow. The design view should include the onWorkflowActivated1 activity.

Note

The following steps (a) through (c) are optional. The workflow that you see in Project Web App gets its name from the Visual Studio project name. The steps and figures in this article show the workflow class name as BranchingWorkflow. If you choose to keep the class name as Workflow1, proceed to step 4.

Renaming the default Workflow1 class does not correctly rename all of the related strings in the Workflow1.Designer.cs file. If you want to rename the workflow class, do steps (a) through (c).
1. In Solution Explorer, right-click the Workflow1 node, and then click Rename. Type a new name; for example, type BranchingWorkflow. Expand the BranchingWorkflow node, and also rename the Workflow1.cs file.
2. Expand the BranchingWorkflow.cs node, and open the BranchingWorkflow.Designer.cs file.
3. Open the Find and Replace dialog box (press Ctrl+H), and replace the old name Workflow1 with the new name BranchingWorkflow. Search for and replace instances of Workflow1 in the entire solution.
Open the design view of BranchingWorkflow.cs, click the onWorkflowActivated1 activity, open the Properties pane, and then expand the CorrelationToken node and the WorkflowProperties node (Figure 3).

Figure 3. Viewing the CorrelationToken and WorkflowProperties properties for onWorkflowActivated1

If you renamed the class BranchingWorkflow, the property values of CorrelationToken and WorkflowProperties should appear as shown in Figure 3. If there is an error in one of the properties, the onWorkflowActivated1 item in the design view would include a red alert icon (the red icon below onWorkflowActivated1 in Figure 3 is not an alert; it indicates the end of the workflow).

Important

The next activity to add in the workflow must be the ProjectSequence activity, which initializes the activated workflow for the current project proposal in Project Server. All additional activities for the Project Server workflow must be placed within the ProjectSequence activity.

Project Server 2010 includes the InitiationData property in the ProjectSequence activity. You must set this property to the WorkflowProperties.InitiationData property in the onWorkflowActivated1 object.
In the Toolbox, expand the Project Server - Workflow tab. (If that tab does not exist, see Creating Toolbox Tabs for Workflow Projects in How to: Configure Visual Studio 2010 for a Project Server Workflow.) Click the ProjectSequence activity in the Toolbox and drag it to the workflow diagram, just below the onWorkflowActivated1 activity.
Set the InitiationData property as follows:
1. Click the projectSequence1 activity
2. In the Properties pane, click ... for the InitiationData property.
3. In the Bind to an existing member tab of the Bind 'InitiationData' to an activity's property dialog box, expand the onWorkflowActivated1 node, and then expand the WorkflowProperties node.
4. Click InitiationData, and then click OK.
Verify that the InitiationData property of the projectSequence1 activity has the following value: Activity=onWorkflowActivated1, Path=WorkflowProperties.InitiationData
On the Project Server - Workflow tab in the Toolbox, click the SetProjectStage activity and drag it inside the projectSequence1 activity. The red alert icon indicates that there is an issue with the SetProjectStage activity: SetProjectStage is missing some required properties.
For every project activity that you add in projectSequence1, you must set the WorkflowContext property.
1. On the Sequential Workflow design view, right-click setProjectStage1, and then click Properties.
2. For the WorkflowContext property, click … to bring up the Bind ‘Workflowcontext’ to an activity’s property dialog box.
3. On the Bind to an existing member tab, expand the projectSequence1 activity (Figure 4).
4. Click the WorkflowContext property, and then click OK.
  
  Figure 4. Setting the WorkflowContext property
5. Set the StageOrder property to 1.

The framework for a Project Server workflow always includes a ProjectSequence activity (to contain other workflow activities) and the initial SetProjectStage activity where the workflow begins. Procedure 2 shows how to bind the setProjectStage1 activity to a specified stage.

Note

When you add a Project Server workflow activity in the Workflow Designer pane, Visual Studio 2010 adds references to indirect assemblies for Project Server 2010. Some of those references can be removed.

Procedure 1a. To set references for a Project Server workflow

Remove the following references that Visual Studio 2010 adds when you add a Project Server workflow activity:
- Microsoft.Office.Project.Schema Required only for custom workflow activities or Project Server event handlers that use DataSet event arguments.
- Microsoft.Office.Project.Server
- Microsoft.Office.Project.Server.Administration
- Microsoft.Office.Project.Server.Communications
- Microsoft.Office.Project.Shared
Keep the following references, which are in the [Program Files]\Microsoft Office Servers\14.0\Bin directory:
- Microsoft.Office.Project.Server.Library
- Microsoft.Office.Project.Server.Workflow

Important

The default implementation of the BranchingWorkflow class constructor does not enable disposing of the workflow context and workflow properties when the workflow is completed. As a result, running custom workflows can cause memory leaks. To avoid memory leaks, use Procedure 1b to do the following:

Modify the class constructor to initialize the workflow context.
Override the Dispose method to dispose the workflow context and workflow properties.
Add an Invoked event handler for the OnWorkflowActivated activity that initializes the workflow properties.

The default Workflow1.cs file (or the BranchingWorkflow.cs file, if you renamed it) includes the workflowId and workFlowProperties variable definitions, as follows:

namespace BranchingWorkflow.Workflow1
{
    public sealed partial class Workflow1 : SequentialWorkflowActivity
    {
        public Workflow1()
        {
            InitializeComponent();
        }

        public Guid workflowId = default(System.Guid);
        public SPWorkflowActivationProperties workflowProperties = new SPWorkflowActivationProperties();
    }
}

Procedure 1b shows how to modify the class constructor, dispose of the workflow context and workflow properties, and add an Invoked event handler.

Procedure 1b. To initialize and dispose the workflow context and workflow properties

Delete the workflowProperties definition, and then add a workflowProperties class property and a workflow context class property named wfContext, as follows:

public SPWorkflowActivationProperties workflowProperties
{ get; set; }

public Microsoft.SharePoint.WorkflowActions.WorkflowContext wfContext
{ get; set; }

Create the wfContext object in the class constructor:

public Workflow1()
{
    wfContext = new Microsoft.SharePoint.WorkflowActions.WorkflowContext();
    InitializeComponent();
}

Override the Dispose method of the SequentialWorkflowActivity base class, and then dispose the variables for workflow context and workflow properties:

protected override void Dispose(bool disposing)
{
    base.Dispose(disposing);
    if (disposing)
    {
        wfContext.Dispose(); 
        workflowProperties.Dispose();
    }
}

Create the onWorkflowActivated1_Invoked event handler to initialize the wfContext object when the workflow is invoked:

private void onWorkflowActivated1_Invoked(object sender, ExternalDataEventArgs e)
{
    wfContext.Initialize(workflowProperties);
}

In the Sequential Workflow design view, click the onWorkflowActivated1 activity. In the Properties pane, click the Events icon, and then in the drop-down list for the Invoked event, select onWorkflowActivated1_Invoked.

Following is the updated Workflow1 class implementation (if you renamed the class BranchingWorkflow, see the Complete Code Example section):

namespace BranchingWorkflow.Workflow1
{
    public sealed partial class Workflow1 : SequentialWorkflowActivity
    {
        public Guid workflowId = default(System.Guid);

        public Workflow1()
        {
            wfContext = new Microsoft.SharePoint.WorkflowActions.WorkflowContext();
            InitializeComponent();
        }

        // Class property for the workflow properties.
        public SPWorkflowActivationProperties workflowProperties
        { get; set; }

        // Class property for the workflow context.
        public Microsoft.SharePoint.WorkflowActions.WorkflowContext wfContext
        { get; set; }

        // Dispose the workflow properties and workflow context when disposing the workflow.
        protected override void Dispose(bool disposing)
        {
            base.Dispose(disposing);
            if (disposing)
            {
                wfContext.Dispose();
                workflowProperties.Dispose();
            }
        }

        // Event handler for the OnWorkflowActivated activity; initializes the workflow context.
        private void onWorkflowActivated1_Invoked(object sender, ExternalDataEventArgs e)
        {
            wfContext.Initialize(workflowProperties);
        }
    }
}

Adding Project Server Workflow Activities

The following Project Server workflow activities require the GUID of a stage, custom field, lookup table value, or security group:

CompareProjectProperty
ReadProjectProperty
ReadProjectSecurityGroupMembers
SetProjectStage
UpdateProjectProperty
UpdateProjectStageStatus

Binding a Workflow Activity to a Stage

In Procedure 2, you bind the SetProjectStage activity to the Initial Proposal Details stage in the project proposal.

Procedure 2. To bind an activity to the Initial Proposal Details stage

Find the GUID of the Initial Proposals Details stage:
1. Log on to Project Web App as an administrator, and then click Server Settings in Quick Launch.
2. In the Workflow and Project Detail Pages section, click Workflow Stages.
3. Click the Initial Proposal Details stage.
4. Scroll to the bottom of the Initial Proposal Details page, expand the System Identification Data section, and then copy the GUID.
Configure the setProjectStage1 activity to use the GUID of the Initial Proposals Details stage:
1. In Solution Explorer, right-click the BranchingWorkflow.cs file, and then click View Code.
2. Add code to the BranchingWorkflow class to create the stage1Guid class variable. Use the GUID value of the Initial Proposals Details stage from step 1.
```
public Guid stage1Guid = new Guid("4fd56302-cb51-4a81-958c-47d499456a61");
```
3. In the Sequential Workflow design view, click the setProjectStage1 activity, click the StageUid field in the Properties pane, and then click the browse button (…) to open the dialog box.
4. In the Bind 'StageUid' to an activity's property dialog box, on the Bind to an existing member tab (Figure 5), click stage1Guid, and then click OK.
  
  Figure 5. Setting the stage GUID for an activity

You can change the stage by simply changing the stage1Guid value in the BranchingWorkflow.cs code.

Updating the Stage Status

The UpdateProjectStageStatus activity uses the StageUid property and the WorkflowContext property to update the status of the correct stage.

Procedure 3. To update the workflow stage status

In the Toolbox, click the UpdateProjectStageStatus activity and drag it below the setProjectStage1 activity in the design view. Ensure that updateProjectStateStatus1 is inside the projectSequence1 bounding box.
Set the WorkflowContext property as shown in Figure 4.
Set the StageUid property as shown in Figure 5.
In the drop-down list for the UpdateProjectStageStatusField property (Figure 6), click Waiting for Input.

Figure 6. Setting properties for UpdateProjectStageStatus

The workflow sequence for the Initial Proposal Details stage is complete. The workflow displays all of the project detail pages (PDPs) that exist within the stage, waits for the user to fill in the required fields in Project Web App, submits the stage, and then allows the user to continue to the next stage.

Creating a Comparison Activity

You can use the CompareProjectProperty activity to evaluate a specified property in the project proposal stage with another property or value.

Procedure 4. To create a comparison activity

In the Toolbox, click CompareProjectProperty, and then drag it below the updateProjectStageStatus1 activity.
Change the following properties of compareProjectProperty1:
- Set CompareOperator to Less Than or Equal To.
- Set NumericPropertyValue to 25000.
- Update the WorkflowContext property as previously described.
Set the ConditionValid property on compareProjectProperty1 as follows:
1. In the code view of BranchingWorkflow.cs, add the following code below the variable declarations. The code creates a Boolean property in the BranchingWorkflow class named CompareBudgetCostResult.
```
public bool CompareBudgetCostResult
{ get; set; }
```
2. In the design view, double-click the yellow cylinder (in the red circle in Figure 7) next to the ConditionalValid property name.
  
  Figure 7. Binding ConditionValid to the CompareBudgetCostResult property
3. In the Bind 'ConditionValid' to an activity's property dialog box, click CompareBudgetCostResult, and then click OK. The False value of ConditionValid changes to Activity=BranchingWorkflow, Path=CompareBudgetCostResult.
Set the custom field that compareProjectProperty1 uses. To use the custom field named Sample Proposal Cost in the Initial Proposal Details stage, you need the GUID of the custom field:
1. Log on to Project Web App as an administrator, and then click Server Settings in Quick Launch.
2. Click Enterprise Custom Fields and Lookup Tables, and then click Sample Proposal Cost in the Enterprise Custom Fields list.
3. Scroll to the bottom of the Edit Custom field: Sample Proposal Cost page, expand the System Identification Data section, and then copy the GUID.
4. In the code view of BranchingWorkflow.cs, declare a new Guid variable as follows. The GUID you use may be different.
```
public Guid proposedCostUid = new Guid("dc68b96a-965e-4b25-ac8a-15a5df729831");
```
5. In the Properties pane of the compareProjectProperty1 activity, click MdPropUid, click the browse button (…) to open the Bind 'MdPropUid to an activity's property dialog box (Figure 8), click proposedCostUid, and then click OK.
  
  Figure 8. Binding proposedCostUid to the MdPropUid property
  
  Figure 9 shows the completed properties for compareProjectProperty1.
  
  Figure 9. Completed properties for the compareProjectProperty1 activity

Creating an If – Else Branch

The IfElse activity in the basic Windows Workflow activities enables a logical branch in the workflow. Each branch binds the workflow to a different stage, where other workflow activities can evaluate options and take different actions. In the BranchingWorkflow example, the IfTrue branch allows the workflow to proceed to the Proposal Details stage and the IfFalse branch goes to the Automated Rejection stage and cancels the workflow.

Procedure 5. To create an If – Else branch

In the Toolbox, expand the Windows Workflow v3.0 tab.
Click the IfElse activity and drag it below the compareProjectProperty1 activity.

In the code view, add the following CompareBudgetCost method below the CompareBudgetCostResult property declaration.

internal void CompareBudgetCost(object sender, ConditionalEventArgs args)
{
    args.Result = CompareBudgetCostResult;
}

In the design view, click ifElseBranchActivity1 (Figure 10).

Figure 10. Selecting the IfTrue branch of an IfElse activity
In the Properties pane, set the Condition property to Code Condition, and then expand the Condition node.
In the drop-down menu of the Condition subnode, select the CompareBudgetCost method.

By setting the Condition property, the left branch of ifElseActivity1 becomes the IfTrue branch. The right branch automatically becomes the Else branch. In procedures 6 and 7, you add the SetProjectStage activity and the UpdateProjectStage activity to each branch.

Binding the IfTrue Branch to Proposal Details

The left branch of ifElseActivity1 is the IfTrue branch. It uses the SetProjectStage activity and the UpdateProjectStage activity to bind to the Proposal Details stage in Project Server. The steps in procedure 6 are similar to previous procedures where you configured SetProjectStage and UpdateProjectStage activities.

Procedure 6. To bind the IfTrue branch to the Proposal Details stage

Drag a SetProjectStage activity from the Toolbox to the left branch (ifElseBranchActivity1).
Create a Guid variable named stage2Guid.
Copy the GUID from the Proposal Details stage in Project Web App into the stage2Guid value.
In the Properties pane for setProjectStage2, bind the StageUid property to stage2Guid.
Set the StageOrder property to 2.
Set the WorkflowContext property to be the same as for previous activities.
Drag an UpdateProjectStageStatus activity below setProjectStage2.
Set the StageUid property and the WorkflowContext property to be the same as in setProjectStage2.
Set the UpdateProjectStageStatusField to Waiting for Input.

Binding the IfFalse Branch to Automated Rejection

The right branch of ifElseActivity1 is ifElseBranchActivity2, which becomes the IfFalse branch when the Condition property is set to (None) in the drop-down list. The IfFalse branch uses the SetProjectStage activity and the UpdateProjectStage activity to bind to the Automated Rejection stage.

Procedure 7. To bind the IfFalse branch to the Automated Rejection stage

Drag a SetProjectStage activity from the Toolbox to the right branch (ifElseBranchActivity2).
Create a Guid variable named stage3Guid.
Copy the GUID from the Automated Rejection stage in Project Web App into the stage3Guid value.
In the Properties pane for setProjectStage3, bind the StageUid property to stage3Guid.
Set the StageOrder property to 3.
Set the WorkflowContext property to be the same as for previous activities.
Drag an UpdateProjectStageStatus activity below setProjectStage3.
Set the StageUid property and the WorkflowContext property to be the same as in setProjectStage3.
Set the UpdateProjectStageStatusField to None.
Drag a Terminate activity from the Windows Workflow v3.0 tab in the Toolbox and drop it below the updateProjectStageStatus3 activity.

If a project proposal costs more than $25,000, the workflow goes through the right (IfFalse) branch to the Automated Rejection stage and then terminates.

Binding to the Final Execution Stage

When the workflow proceeds through the IfTrue branch, the example BranchingWorkflow ends when it binds to the Execution stage. The Execution stage includes a project detail page that contains the Project Schedule Web Part, where a user can begin to plan the project.

Procedure 8. To bind the last activity to the Final Execution stage

Drag a SetProjectStage activity from the Toolbox and drop it below the ifElseActivity1 box.
Create a Guid variable named stage4Guid.
Copy the GUID from the Execution stage in pwa into the stage4Guid value.
In the Properties pane for setProjectStage4, bind the StageUid property to stage4Guid.
Set the StageOrder property to 4.
Set the WorkflowContext property to be the same as for previous activities.
Drag an UpdateProjectStageStatus activity below setProjectStage4.
Set the StageUid property and the WorkflowContext property of updateProjectStageStatus4 to be the same as in setProjectStage4.
Set UpdateProjectStageStatusField to Waiting for Input.

Figure 11 shows the complete design view of BranchingWorkflow.cs. The final stage contains a PDP that includes the Project Schedule Web Part. When the workflow is completed, a user can proceed through the Execution stage and plan the project.

Figure 11. The complete BranchingWorkflow in design view

The complete workflow in design view

When the BranchingWorkflow solution is deployed to Project Server, it does the following jobs:

The workflow gathers initial project proposal details.
The workflow determines whether a project proposal costs more than $25,000.
If the proposal is too expensive, the workflow rejects the project and terminates.
If the proposal costs less than or equal to $25,000, the workflow proceeds to the Proposal Details stage where the user can add information in the associated PDPs.
When the PDPs in the Proposal Details stage are complete, the workflow enters the Execution stage and then ends.

For information about testing the workflow on the local Project Server computer, see How to: Install and Test a Project Server Workflow. For information about creating a SharePoint solution package for deployment to another Project Server computer or Project Web App instance, see How to: Deploy a Project Server Workflow.

Complete Code Example

Following is the complete BranchingWorkflow.cs code. To compile the code, you must do all the steps in the previous procedures.

using System;
using System.ComponentModel;
using System.ComponentModel.Design;
using System.Collections;
using System.Drawing;
using System.Linq;
using System.Workflow.ComponentModel.Compiler;
using System.Workflow.ComponentModel.Serialization;
using System.Workflow.ComponentModel;
using System.Workflow.ComponentModel.Design;
using System.Workflow.Runtime;
using System.Workflow.Activities;
using System.Workflow.Activities.Rules;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Workflow;
using Microsoft.SharePoint.WorkflowActions;

namespace BranchingWorkflow.BranchingWorkflow
{
    public sealed partial class BranchingWorkflow : SequentialWorkflowActivity
    {
        public Guid workflowId = default(System.Guid);
 
        // Stage 1: Initial Proposal Details stage. Replace GUIDs with your values.
        public Guid stage1Guid = new Guid("4fd56302-cb51-4a81-958c-47d499456a61");

        // Stage 2: Proposal Details stage.
        public Guid stage2Guid = new Guid("400060e9-5f2b-4e60-82f6-451b83165190");

        // Stage 3: Automated Rejection stage.
        public Guid stage3Guid = new Guid("c39007f5-9338-4a0f-af99-761dc7a2e97c");

        // Stage 4: Execution stage.
        public Guid stage4Guid = new Guid("43a1eb7b-562d-42e8-9a96-88817ef74295");

        // Custom field: Sample Proposal Cost.
        public Guid proposedCostUid = new Guid("dc68b96a-965e-4b25-ac8a-15a5df729831");

        public BranchingWorkflow()
        {
            wfContext = new Microsoft.SharePoint.WorkflowActions.WorkflowContext();
            InitializeComponent();
        }

        // Class property for the workflow properties.
        public SPWorkflowActivationProperties workflowProperties
        { get; set; }

        // Class property for the workflow context.
        public Microsoft.SharePoint.WorkflowActions.WorkflowContext wfContext
        { get; set; }

        // Dispose the workflow properties and workflow context when disposing the workflow.
        protected override void Dispose(bool disposing)
        {
            base.Dispose(disposing);
            if (disposing)
            {
                wfContext.Dispose();
                workflowProperties.Dispose();
            }
        }

        // Event handler for the OnWorkflowActivated activity; initializes the workflow context.
        private void onWorkflowActivated1_Invoked(object sender, ExternalDataEventArgs e)
        {
            wfContext.Initialize(workflowProperties);
        }

        // Property for comparing the budget cost result.
        public bool CompareBudgetCostResult
        { get; set; }

        // Method to compare the budget cost.
        internal void CompareBudgetCost(object sender, ConditionalEventArgs args)
        {
            args.Result = CompareBudgetCostResult;
        }
    }
}

Errors: If you receive the following error when you try to build the project, check the values of the GUIDs for the stages, custom fields, and other entities.

Error  1  Could not create activity of type 'BranchingWorkflow.BranchingWorkflow'. 
System.FormatException: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
   at System.Guid..ctor(String g)
   at BranchingWorkflow.BranchingWorkflow..ctor()
E:\Project\ Workflow\BranchingWorkflow  1  1

For other errors, check that the references are set correctly, as in Procedure 1a.

Robust Programming

The BranchingWorkflow.cs example does not include cancel or fault handler activities. A production-quality workflow should include event handler activities for canceling the workflow and for exceptions. For example, if the Proposal Details stage is deleted in Project Web App, the workflow should handle the exception.

When you select any of the following activities in the BranchingWorkflow design view, click the down arrow at the top of the activity (Figure 12) to see a menu for the main view and the View Cancel Handler and View Fault Handlers options:

Top SequentialWorkflow activity (the arrow in the green circle at the top of the design view)
ProjectSequence activity
IfElse activity
EfElseBranch activity (either the left branch or the right branch)

Figure 12. Using the option menu for the ProjectSequence activity in the design view

Using the option menu for the design view

共用方式為