Windows Workflow Foundation (WF) is a platform component of the Microsoft .NET Framework 3.5. WF provides a workflow run-time engine, an extensible programming model, and tools that help build and execute workflow-enabled applications. WF allows asynchronous programming to help define persistent workflow applications. That is, you can define long-running workflows that preserve state and wait indefinitely until a user or application executes the next activity. Additionally, WF allows you to build applications that consist of one or more workflows. The workflow run-time engine executes individual activities that compose workflows one at a time and hosts the execution inside any Windows process, including console applications, Windows forms applications, Windows Services, ASP.NET Web sites, and Web services. For more information about the WF programming model, visit http://msdn2.microsoft.com/en-us/library/ms734702.aspx.

You can use Visual Studio 2008 to create workflow solutions using a graphic workflow designer or you can create entire workflow solutions programmatically. Since workflows are based on activities, WF provides a Base Activity Library (BAL) that includes a set of general purpose activities that are common to workflow solutions. They include Code, Sequence, While, IFElse, and other activities that help model primitive operations that exist in different programming languages. Additionally, you can define custom activities and create custom activity libraries (CAL).

There are three main namespaces you can use to create workflows programmatically using WF:

Figure 7-2 shows the WF components: activities, workflows, custom activity libraries, the WF runtime engine, the WF services, and the WF BAL. They are all hosted in a process that executes a workflow-enabled application.

Figure 7-2. A workflow-enabled application running on the Windows Workflow Foundation platform

Workflow Authoring Styles

The WF supports two main authoring styles of workflow programs:

• Sequential workflow. Executes activities in a predefined pattern and represents a workflow as a procession of steps that must be executed in order until the last activity is completed. This type of workflow can be modeled as a flowchart. Therefore, to design a graphical representation of a workflow, you can use flowchart structures such as start, activity, repetition, loops, and finish. A good example to explain a sequential workflow is a simple notification system. Imagine that you need to build a vacation leave notification system for your company. In this solution, the workflow starts when Valeria, an employee, opens the vacation leave notification form to define the days she plans to be away for the holidays. Once the form is complete, the employee submits the form and the system sends a notification to her manager, Monica, who reviews the summary document, assessing the number of days the employee is planning on being away. If the manager approves the document, the document is moved to an "approved document library" that backups all time-off summary documents. Next, the system will notify the rest of the team that Valeria plans to be on vacation for the holidays. However, if the manager rejects the document, the system will notify Valeria, and she will have to review the manager’s comments attached in the form. In either case, the workflow reaches an end and terminates the execution.

• State machine workflow. Responds to external events as they occur and represents a group of states, transitions, and events, which trigger transitions between these states. We will use a document publishing process to explain state machine workflow. Imagine that you work for an editorial company that publishes technical articles for software developers and you are asked to build an article publishing workflow application. In this solution, the workflow starts when Hubert, a well-known contributor, submits a technical article using a Web-based publishing system. Submitting an article triggers a OnDocumentCreated event. This event calls a Web service that stores the technical article in a Microsoft Office SharePoint 2007 document library and sends an e-mail to the corresponding subject-matter experts to ask for a technical review. The technical article will remain in a DocumentCreated state until all approvers review and approve the technical article. Once this step is completed, the system will trigger an OnDocumentApproved event. This event changes the status of the technical article to DocumentApproved and sends an e-mail to the publisher to notify him that this particular technical article is ready for publishing. Carlos, the publisher, fills out a form specifying that this document is ready for publishing and submits the form to the printer. This will trigger an OnDocumentPublished event that changes the status of the article to DocumentPublished, after which an e-mail is sent to the contributor notifying him that his technical article was sent to the printer. Finally, the printer logs on to the publishing system and marks the technical article as completed. This launches an OnDocumentCompleted event that changes the status of the document to DocumentCompleted and sends an e-mail notifying all the participants in the workflow that the technical article was printed. The workflow reaches an end and terminates the execution.

Figure 7-3 shows a sequential workflow and a state machine workflow diagram.

As we explained earlier, the WF provides a workflow run-time engine, an extensible programming model, and tools that help build and execute workflow-enabled applications. However, if you want to build custom workflow solutions that integrate seamlessly with the 2007 Microsoft Office system, you can consider using the workflow services provided by Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007.

Figure 7-3. Sequential and state machine workflow diagrams

Windows SharePoint Services 3.0 provides enhanced support to create document-oriented features and helps integrate a human dimension to custom workflow solutions. Windows SharePoint Services workflows can assign tasks to users and allow users to see status on any workflow instance. Windows SharePoint Services workflows can be added to documents, list items, or content types and are made available to users at the document library or list level.

We explained earlier that the WF run-time engine executes individual activities that compose workflows one at a time and hosts the execution inside any Windows process. In the same way, Windows SharePoint Services can also act as a host for the WF runtime engine. Windows SharePoint Services supports the WF run-time engine and WF services. However, it provides a different programming model. The Microsoft.SharePoint.Workflow namespace inherits many of the classes from the System.Workflow namespace and provides a new set of classes, interfaces, and enumerations that represent the workflow functionality contained in Windows SharePoint Services. For more information, visit http://msdn2.microsoft.com/en-us/library/microsoft.sharepoint.workflow.aspx.

An important item to consider while designing workflow OBAs is the tools you can use to create them. You can create custom workflow OBA solutions using Microsoft SharePoint Designer 2007 or the workflow designer in Visual Studio 2008. The last section of this chapter explains how to create custom workflow OBAs using these tools.

In Windows SharePoint Services, a workflow running on a specific item is a workflow instance, and workflow templates are workflow programs that are available on a site, list, or content type. Association is the process of binding a workflow template to a site, list, or content type. Workflows can be associated to servers or Web forms running Windows SharePoint Services.

Figure 7-4 shows the workflow architecture in Windows SharePoint Services 3.0.

Workflow templates may or may not have workflow input forms. These forms allow end users to interact with workflows and can be of four different kinds.

Windows SharePoint Services defines the previous forms as ASP.NET 2.0 pages. While designing OBAs, you have the option to create custom ASP.NET 2.0 Web forms to define the behavior you need for association, initiation, task, and modification forms. Additionally, you can use custom forms to control the Web design of the forms. For example, you can configure a set of forms using your company logo and Web site stylesheets. You can use master pages in custom association, initiation, task, and modification forms to display the same user interface you use for your internal Web sites.

Windows SharePoint Services provides a set of definition and configuration files that contain the information necessary to create a workflow template and instantiate workflows. These files can be represented by different combinations of files, including an XML markup file that includes the declarative metadata of the workflow, in combination with a code-behind file that contains custom code representing the properties and behavior of the workflow.

The workflow definition schema allows you to define multiple settings such as the name, GUID, description, and URLS for custom forms, the name of the workflow assembly and class, and custom metadata of the workflow. Example 7-1 shows a sample XML markup file for an Expense reporting solution. Note how the AssociationURL, InititiationURL, and ModificationURL attributes of the workflow element define the custom forms that this workflow solution uses for association, instantiation, and modification, respectively.

[XML]
<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
   <Workflow
      Name="ExpenseReportWorkflow"
      Description="Use this workflow to track expense report status."
      Id="C6964BFF-BG8D-41ac-AC5E-B61EC111731C"
      CodeBesideClass="OBAExpenseReport.Workflow1"
      CodeBesideAssembly="OBAExpenseReport, Version=12.0.0.0, Culture=neutral,
      PublicKeyToken=71e3bce121e9429c"
      TaskListContentTypeId="0x01080100C9C9515DE4E24001905074F980F93160"
      AssociationUrl="_layouts/expenseReportAssociationPage.aspx"
      InstantiationUrl="_layouts/expenseReportInitiationPage.aspx"
      ModificationUrl="_layouts/expenseReportModificationPage.aspx">
   <Categories/>
   <AssociationData>
   ...
   </AssociationData>
   <MetaData>
   ...
   </MetaData>
   </Workflow>
</Elements>

Note

This sample has been edited for clarity.

Keep in mind that Windows SharePoint Services must use ASP.NET 2.0 to define input forms for workflow solutions. InfoPath Forms cannot be used for Windows SharePoint Services workflows. If you have an existing ASP.NET 2.0 application and want to take advantage of workflows in SharePoint, you can use Windows SharePoint Services workflows. On the other hand, Windows SharePoint Services workflow solutions can’t use Office client applications to interact with end users. That includes InfoPath forms. If you want seamless support for 2007 Microsoft Office system clients in custom OBA workflow solutions, Microsoft Office SharePoint Server 2007 is the better option.

Microsoft Office SharePoint Server 2007 provides a true enterprise portal platform and builds upon the Windows SharePoint Services 3.0 infrastructure. In the context of OBA workflow solutions, Office SharePoint Server 2007 provides the following capabilities:

Support for InfoPath Forms

Office SharePoint Server 2007 allows users to interact with workflows using InfoPath forms in the same way that users interact with ASP.NET 2.0 Web forms for Windows SharePoint Services workflows. Some developers prefer InfoPath forms over ASP.NET 2.0 forms for a couple of reasons:

• InfoPath forms can be displayed by the 2007 Microsoft Office system clients. For example, you can host an InfoPath form in Word 2007, Excel 2007, PowerPoint 2007, or Outlook 2007.

• InfoPath forms are easier to create. InfoPath 2007 provides a designer experience that helps you create forms faster and with less code. Also, InfoPath forms provide built-in validation and data proofing.

You can use a workflow definition schema file to define InfoPath forms for association, initiation, tasks, and modification that integrate with Office SharePoint Server 2007 workflows solutions. To define the custom forms you want to use in a workflow template definition, you must set the form URLs of each specific process (association, initiation, modification, edit task) to the appropriate ASP.NET 2.0 predefined page of an Office SharePoint Server 2007 instance as shown in Example 7-2. Next, you add an element that specifies the URN for the custom InfoPath form you built for each type of process. Example 7-2 shows a sample XML markup file for an expense reporting solution that uses InfoPath forms.

Example 7-2. Example of XML markup file for an expense report solution using InfoPath forms

[XML]
<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
   <Workflow
         Name="ExpenseReportWorkflow"
         Description="Use this workflow to track expense report status."
         Id="C6964BFF-BG8D-41ac-AC5E-B61EC111731C"
         CodeBesideClass="OBAExpenseReport.Workflow1"
         CodeBesideAssembly="OBAExpenseReport, Version=12.0.0.0, Culture=neutral,
                           PublicKeyToken=71e3bce121e9429c"
         TaskListContentTypeId="0x01080100C9C9515DE4E24001905074F980F93160"
         AssociationUrl="_layouts/CstWrkflIP.aspx"
         InstantiationUrl="_layouts/IniWrkflIP.aspx"
         ModificationUrl="_layouts/ModWrkflIP.aspx"
         StatusUrl="_layouts/WrkStat.aspx">
   <Categories/>
   <!-- Tags to specify InfoPath forms for the workflow; delete
   tags for forms that you do not have -->
   <MetaData>
      <Association_FormURN>
         urn:schemas-OBAExpenseReport-com:workflow:ReviewRouting-Assoc
      </Association_FormURN>
      <Instantiation_FormURN>
         urn:schemas-OBAExpenseReport-com:workflow:ReviewRouting-Init
      </Instantiation_FormURN>
       <Task0_FormURN>
           urn:schemas-OBAExpenseReport-com:workflow:ReviewRouting-Review
       </Task0_FormURN>
       <Task1_FormURN>
          urn:schemas-OBAExpenseReport-com:workflow:ReviewRouting-Review
       </Task1_FormURN>
       <AssociateOnActivation>false</AssociateOnActivation>
    </MetaData>
  </Workflow>
</Elements>

To design an InfoPath form for a workflow in Office SharePoint Server 2007, you use InfoPath 2007 and start designing a custom form the same way you would with any other InfoPath 2007 form. In general, to create InfoPath forms for workflow solutions, you start by adding controls on your form. Next, you data bind the controls so that the form can send and receive data to Office SharePoint Server 2007 and the workflow instance. Next, you add and customize a button that submits your form data to Office SharePoint Server 2007. Finally, you set the forms security level to Domain and publish the form. For more information about creating InfoPath forms, visit http://office.microsoft.com/en-us/infopath/HA012111841033.aspx.

Figure 7-5 shows an InfoPath form used as an initiation form for an expense reporting workflow solution.

Figure 7-5. Sample InfoPath form for expense reporting workflow solution

Integration into 2007 Microsoft Office System Client Applications

One of the most powerful features offered by Office SharePoint Server 2007 is the ability to connect custom workflow solutions with Office Client applications. This allows end users to interact in a natural way with OBA workflow solutions. End users can interact with workflows directly from Word 2007, Excel 2007, PowerPoint 2007, and Outlook 2007. As mentioned in the previous section of this chapter, Office client applications can host InfoPath forms.

Note

This option is available for users that installed InfoPath 2007.

For example, you can open, fill out, and submit InfoPath forms from Outlook 2007. InfoPath e-mail forms help streamline workflow processes that you use to collaborate and share data using well-known applications and, therefore, reduce the need for training. Figure 7-6 shows how you can open InfoPath forms in Outlook 2007.

Figure 7-6. Open InfoPath forms in Outlook 2007

Another powerful possibility offered by Office SharePoint Server 2007 is the ability for end users to initiate a workflow from Word 2007. You can open a Word 2007 document and create a running workflow instance using the Start New Workflow option. This greatly simplifies the process of starting workflows involving document approval. Earlier in this chapter, we explored a state machine workflow document publishing scenario in which you work for an editorial company that publishes technical articles for software developers and you are asked to build an article publishing workflow application. In this scenario, contributors can use Word 2007 to initiate a document approval workflow right after they finish writing an article. Figure 7-7 shows how a contributor can initiate a document approval workflow instance from Word 2007.

Another integration possibility includes reporting tools that provide an aggregate analysis of workflow history. You may be interested in analyzing workflow processes to identify problems, bottlenecks, and the performance of your organization. Office SharePoint Server 2007 includes several predefined Excel 2007 reports that provide aggregate analysis of workflow history. Additionally, you can use Visio 2007, Access 2007, or custom monitoring solutions to analyze workflow history information stored in SharePoint lists.

Figure 7-7. Initiate a document approval workflow from Word 2007

Out-of-the-Box Workflows

Office SharePoint Server provides a set of out-of-the-box (OOB) workflow solutions. Information workers (IWs) can use these workflow templates with no developer intervention. However, you can customize predefined workflows based on your business needs. The predefined workflows templates in Office SharePoint Server 2007 include the following:

• Approval. Provides business logic and predefined settings that help you route documents for approval. When the workflow is initiated, the end user defines a list of approvers.

• Collect feedback. Provides business logic and predefined settings that help you route documents for review. This workflow is similar to the previous one. However, this workflow allows end users to provide feedback.

• Collect signatures. Provides business logic and predefined settings that help you collect signatures for a document. This workflow works like the previous ones, but requires end users to provide a signature to complete a workflow. This workflow can be started only in Office client programs.

• Disposition approval. Provides business logic and predefined settings that help users decide whether to retain or delete expired documents.

• Three-state workflow. Provides business logic and predefined settings that help users track the status of a list item through three states. It can be used to manage business processes that require organizations to track a high volume of issues or items, such as customer support issues, sales leads, or project tasks.

• Translation management workflow. Provides business logic and predefined settings that help manage document translation. This workflow allows users to assign tasks and track the status of translated documents.

To create OOB workflow solutions, you start by opening a document library, list, or content type. Next, you select Settings, Document Library Settings, and then Workflow. This opens an Add Workflow page that allows you to configure an OOB workflow. Figure 7-8 shows how you can create an OOB workflow in a preexisting workflow document library in Office SharePoint Server 2007.

Figure 7-8. Creating out-of-the-box workflow solutions in Office SharePoint Server 2007

For more information, visit http://office.microsoft.com/en-us/sharepointserver/CH101782961033.aspx.