Developing Project Server Workflows

  • Article

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

Demand management processes in Microsoft Project Server 2010 include workflows that help you manage project proposals and portfolio analyses. This section includes articles that show how to create workflows for Project Server.

For an introduction to the processes of demand management, see Hitchhiker’s Guide to Demand Management (white paper). For a sample project that corresponds to the white paper, see Project 2010 Demand Management Sample Project Workflow Solution in the MSDN Code Gallery.

Important

Because it is designed to develop workflows for Microsoft SharePoint Server 2010, we support only Microsoft Visual Studio 2010 with the Microsoft .NET Framework 3.5 for developing Project Server workflows.

Workflows developed for pre-release versions of Project Server 2010 must be recompiled and redeployed for the released version.

Use a test installation of Project Server, not a production installation, to develop and test workflows.

Development of Project Server workflows with Microsoft SharePoint Designer 2010 is not supported, for the following reasons:

  • Project Web App sites cannot be opened or modified in SharePoint Designer 2010, because many components on Project Web App pages require programmatic access to project context data and the Project Server Interface (PSI).

  • All activities in Project Server workflows are wrapped inside the Project Sequence activity, which contains the project context data needed for PSI calls.

  • SharePoint Designer 2010 does not support string arrays and GUIDs as properties that some Project Server workflow activities require.

Using Visual Studio 2010 to develop and debug Project Server workflows and other solutions for Project Web App requires development on a Project Server computer. Although it is possible to copy the required Project Server assemblies and SharePoint assemblies to another development computer, remote development is not supported. The Visual Studio 2010 SharePoint Developer Tools connect to a SharePoint instance in many phases of the development process, for example:

  • Some of the wizards used for creating projects and items access SharePoint configuration information, such as site and list definitions and the Project Server workflow history list.

  • SharePoint nodes show in the Server explorer, which requires access to SharePoint.

  • By default, Visual Studio deploys a SharePoint solution package (.wsp file) on a local SharePoint site and activates features for testing.

  • After activation, Visual Studio attaches to the process for debugging. Activation can be turned off, but testing and debugging require local development.

Note

In the Project 2010 SDK download, the Samples\Workflow subdirectory includes the Visual Studio solution for the BranchingWorkflow example and also for the SampleProposal2 solution, which is the source code for the Sample Proposal workflow that is installed with Project Server 2010. The Samples\Workflow\SampleProposal2 subdirectory also includes a flowchart diagram of the workflow stages, phases, and associated project detail pages (PDPs).

The Solution Starters for Project 2010 downloads in MSDN Code Gallery include tools with source code for creating and managing workflows, visualizing workflows, export and import of enterprise project types and associated entities, and using an InfoPath form in a project details page. The Dynamic Workflow tool (and source code) can easily create non-branching workflows that are based on stages defined in Project Web App.

Changing a Workflow Definition

When you need to change a workflow definition, there are two options:

  • Case 1:  updated information impacts in-progress workflows. You do not need to change the workflow DLL version. Deploy the new workflow and restart all of the instances of the existing workflow. If the workflow is properly coded, it skips stages until it stops at the change.

  • Case 2:  updated information affects only new projects. When you build the updated workflow in Visual Studio, increase the version number of the DLL. When you deploy the new workflow version, both DLLs are installed in the global assembly cache. Old workflow instances use the old DLL and new workflow instances use the new DLL.

    Note

    Whenever you change a workflow definition, you must restart the related services (SharePoint Timer, Project Server Queue, and Internet Information Service).

    For more information, see How to use the "Skip to Stage" Feature in Project Server 2010 Workflows.

Accessing the PSI from a Project Server Workflow

The built-in Project Server workflow activities, such as Microsoft.Office.Project.Server.Workflow.ReadProjectProperty, internally access the PSI through classes in the Microsoft.Office.Project.Server.WebServiceProxy namespace. To directly use the PSI from a custom workflow, you must create a custom workflow activity.

For information about creating a custom workflow activity, and a complete code sample, see the \Samples\Workflow\CustomActivityWorkflow subdirectory in the Project 2010 SDK download. For a link to the download, see Project 2010 SDK Documentation.

In This Section

How to: Configure Visual Studio 2010 for a Project Server Workflow

How to: Create a Branching Workflow

How to: Install and Test a Project Server Workflow

How to: Deploy a Project Server Workflow

See Also

Concepts

Workflow and Demand Management

Other Resources

Hitchhiker’s Guide to Demand Management (white paper)

Project 2010 Demand Management Sample Project Workflow Solution

Walkthrough: Create a Custom Site Workflow Activity

A Developer's Introduction to Windows Workflow Foundation (WF4) in .NET 4

Solution Starters for Project 2010

How to use the "Skip to Stage" Feature in Project Server 2010 Workflows