Custom Workflow with Visual Studio 2005 for SharePoint 2007, Part 1

The following series of posts are a compilation of different resources (blogs, MSDN, TechEd...etc).

Software Requirements:
1- Windows Server 2003 R2
2- Microsoft .NET framework 3.0
3- Microsoft Office InfoPath 2007
4- Microsoft Windows Sharepoint Services 3.0
5- Office SharePoint Server 2007 basic installation
6- Visual Studio 2005 with SP1
7- Visual Studio 2005 Extensions for Windows Workflow Foundation
8- Office Sharepoint Server 2007 SDK + ECM starter Kit

Note: The Office SharePoint Server 2007–specific workflow activities require that Microsoft Windows SharePoint Services 3.0 and Office SharePoint Server 2007 be installed on the computer you use to develop the workflows



Workflow and Windows SharePoint Services 3.0:
The WF runtime engine can be hosted in any Windows process. Windows SharePoint Services 3.0 takes advantage of this, acting as a host for this engine. One or more workflow templates, each containing the code that defines a particular workflow, can be installed on a server. Once this is done, an association can be created between a specific template and a document library, list, or content type. This template can then be loaded and executed by the Windows SharePoint Services-hosted WF runtime engine, creating a workflow instance. The figure below shows how this looks

Sharepoint Server vs Sharepoint Services:
Windows SharePoint Services 3.0 offers a general foundation for human workflow applications. Office SharePoint Server 2007 provides extra capabilities built on this foundation. When is the workflow support in Windows SharePoint Services sufficient, and when is Office SharePoint Server also required? Here’s a short summary of the major factors in making this decision.
Windows SharePoint Services alone is appropriate for:
· Adding application logic to Windows SharePoint Services sites that works with documents and list items.
· Building workflow applications where user interaction via ASPX forms in a Web browser is sufficient.
Office SharePoint Server is required for:
· Using most of the pre-defined workflows that Microsoft provides. (The exception is Issue Tracking, which ships with Windows SharePoint Services and uses only ASPX forms.)
· Building workflow applications where user interaction via Office 2007 client applications is required. This option also allows using InfoPath workflow forms, which are simpler to create and provide more functionality than ASPX forms.

The roles played by different people in a workflow life cycle:
1- Workflow author: the developer or information worker who creates a workflow template.
2- Windows SharePoint Services administrator: the person who installs a workflow template and associates it with a document library or list.
3- Workflow initiator: the person who starts a running workflow, causing a workflow instance to be created from a particular workflow template.
4- Workflow participants: the people who interact with a workflow instance to carry out the business process it supports.

Both installation and association are done automatically for workflows created using Office SharePoint Designer. For those created using WF Workflow Designer and Visual Studio, however, a Windows SharePoint Services server administrator must explicitly install the workflow template. Once this is done, the template must be associated with a library, list, or content type, something that can be performed by someone with lesser permissions than a server administrator. Whoever creates this association also assigns it a unique name, allowing it to be referenced by users. Optionally, the workflow’s author can let the person who creates the association set options for the workflow’s behavior, such as specifying a default list of people who should always participate in the process. The same template can be associated with multiple libraries, lists, or content types, with each association customized as required. After the association has been created and any options set, a workflow initiator can create a workflow instance from this association, as described next.

There are plenty of moving parts in a Windows SharePoint Services workflow. The figure below gives an overall view of how the process works.


Visual Studio 2005 vs SharePoint Designer 2007:
ref. SharePoint 2007 Workflow Jumpstart



Forms in a workflow lifecycle:
Windows SharePoint Services workflow consists of two things: the forms a workflow uses to interact with its users and the logic that defines the workflow’s behavior.
A Windows SharePoint Services workflow can potentially display its own forms at four points in its lifecycle:
1- Association: When a Windows SharePoint Services administrator associates a workflow template with a particular document library or list, he might be able to set options that will apply to every workflow instance created from this association. If a workflow author chooses to allow this, she must provide a form that lets the administrator specify this information.
2- Initiation: The initiator of a workflow might be allowed to specify options when he starts a running instance. In the approval scenario just described, for instance, the options included specifying the list of workflow participants and defining how long each one had to complete his or her task. If a workflow allows this, its author must provide a form to allow the initiator to set these options, as shown in step 3 of the previous diagram.
3- Task Completion: The running workflow instance must display a form to the participants in the workflow to let them complete their task. Shown in step 6 in the previous diagram, this form is what allowed the approvers in the earlier scenario to make comments on the document and indicate their approval or rejection.
4- Modification: Although it wasn’t shown in the scenario above, the creator of a workflow can allow it to be modified while it’s running. For example, a workflow might allow adding new participants after it has begun executing or extending the due date for completing tasks. If this option is used, the workflow must display a form at this point to let a participant specify what changes should be made.

Workflows built solely on Windows SharePoint Services define their forms as ASPX pages, while those using Office SharePoint Server can also use forms created with InfoPath.

The most important Activities available for designing a workflow are:
· OnWorkflowActivated: every Windows SharePoint Services workflow must begin with this activity. Among other things, this activity can accept information supplied by the administrator via the Association form when the workflow is associated with a document library or list. It can also accept information supplied via the Initiation form when the workflow is started.
· CreateTask: creates a task assigned to a particular user in a task list.
· OnTaskChanged: accepts information from the Task Completion form.
· CompleteTask: marks a task as completed.
· DeleteTask: removes a task from a task list.
· OnWorkflowModified: accepts information from the Modification form, which can then be used to change how this instance of the workflow behaves. If the workflow’s creator chooses not to include any instances of this activity in the workflow, that workflow cannot be modified while it’s running.
· SendEmail: sends email to a specified person or group of people.
· LogToHistoryList: writes information about the workflow’s execution to a history list. The information in this list is used to let users see where a workflow is in its execution, look at the workflow’s history after it’s completed, and more. To allow this kind of monitoring, the workflow’s author must write information to a History list at appropriate points in the workflow’s execution. Because it provides its own mechanism for tracking workflows, Windows SharePoint Services doesn’t support WF’s standard tracking service.

A typical pattern for a simple Windows SharePoint Services workflow begins with an OnWorkflowActivated activity, and then uses a CreateTask activity to assign a task to a participant in the workflow. The BAL’s standard while activity might then be used to wait until the user completes the task. To learn when this has happened (perhaps the user makes multiple changes to the task, then checks a box on the Task Completion form when she’s done), an OnTaskChanged activity executes within the while, extracting whatever information the user has entered on that form. When the user has completed the task, a CompleteTask activity might execute, followed by a DeleteTask. The workflow can then go on to the next participant, using CreateTask to assign a task to him, and so on. And of course, other things can occur, such as sending email, logging information to the history list, or even including the BAL’s Code activity, which allows running arbitrary code.