Home > Articles > Programming

  • Print
  • + Share This
This chapter is from the book

SharePoint Workflow

This section on SharePoint workflow and the next on designer rehosting and external modeling discuss topics not covered in later hours. They are discussed in this hour because they are important to the overall WF vision and understanding them will help you understand WF's goals. SharePoint workflow is not covered because it is not part of the base WF product. It is built on top of the base WF. Following the hands-on labs would also require that you install SharePoint, which is no small task. The reasons for not including designer rehosting and external modeling in a subsequent hour are described in the next section.

This section contains three subsections. The first provides a conceptual overview of SharePoint workflow, the next describes the Visual Studio version of SharePoint workflow, and the last the SharePoint Designer version.

SharePoint Workflow Overview

SharePoint is Microsoft's collaboration, document management, and general information environment. Many companies use SharePoint to implement departmental and event-specific sites for groups of people to share information and work together.

A common site may have document libraries, tasks, form libraries, a calendar, and other data specific to the site's purpose (Figure 1.23). SharePoint can also be described as a portal. SharePoint also features business intelligence and much more. For our purposes, SharePoint is an information hub where groups of people collaborate.

Figure 1.23

Figure 1.23 Sample SharePoint site home page.

Workflow is a common requirement for SharePoint because the vast information in it needs to be routed. Expense reports and documents stored in it, for example, need to be approved, rejected, and escalated. SharePoint tasks (which can be integrated with Outlook tasks) also provide a great destination for workflows to assign work. If Jane, for instance, must approve John's expense report, a task can be assigned to Jane. Jane can then access this task in her SharePoint or Outlook task list, or, depending on configuration, it may be emailed to her.

SharePoint can be customized by both technically savvy business users and developers. One of its selling points is that its sites and other items can be created and configured without the need for IT. There are three levels of customization performed in SharePoint. The first is performed via SharePoint configuration forms, the second is performed in the SharePoint Designer, and the third in code. For the most part, both users and developers can configure SharePoint via the forms. SharePoint Designer (FrontPage's replacement) configuration is generally performed by power users. Changes requiring code are performed by developers.

SharePoint workflow features both Visual Studio and SharePoint Designer workflow authoring options. Additional custom activities are targeted at the SharePoint host in both offerings. A tighter relationship exists between the workflow and the forms used to collect its data. The most common forms are task and initiation. The first is used to collection information for tasks that are assigned by the workflow. Remember that approval requests, for example, are assigned via tasks. The second is used when the workflow is started to collect information. SharePoint Workflow (in the Microsoft Office SharePoint Server offering) also includes a number of OOB workflows that support approval and other common scenarios. They are highly flexible and good to work with to get an idea of the types of workflows that can be created in SharePoint workflow.

SharePoint Workflow Visual Studio

In Visual Studio SharePoint workflow, developers use the same Visual Studio environment used in standard WF development. The main difference is a collection of additional activities tailored to the SharePoint host. A couple of project templates also reference SharePoint assemblies and simplify deployment to the SharePoint host. Figure 1.24 demonstrates the Visual Studio SharePoint workflow. The toolbox shown is specifically for SharePoint. It contains a number of task-centric and other activities specific to the SharePoint host.

Figure 1.24

Figure 1.24 SharePoint Visual Studio Project.

The capability to add a collection of custom activities specific to a domain, in this case the SharePoint domain, makes WF much more useful. It is also demonstrates how effectively you can extend WF by adding a collection of activities specific to your business and/or host. The SharePoint custom activities are used in addition to the BAL activities. WF's BAL activities provide the general control flow and other generic capabilities, and the SharePoint custom activities provide host-specific functionality.

SharePoint Workflow SharePoint Designer

The Visual Studio version of SharePoint workflow allows developers to create workflows to run in SharePoint. However, SharePoint allows technically savvy business users to customize many aspects of SharePoint. Consistent with this premise, workflows can also be designed in the SharePoint Designer. The SharePoint Designer includes a similar collection of activities to that found in Visual Studio SharePoint workflow and packages them in a different design environment. Figure 1.25 shows the SharePoint Designer workflow designer.

Figure 1.25

Figure 1.25 SharePoint Designer workflow.

It is rules driven because Microsoft thought it preferable to a graphical one, which is a controversial decision. However, the big picture is that it takes a similar set of base functionality and exposes it in a different designer targeted at a less technical user. Custom activities can be added to the SharePoint Designer as well. Adding a collection of domain-specific custom activities to this designer significantly increases the potential for technically savvy business people to create workflows by themselves. The SharePoint Designer saves the workflow in a XAML format, which is then loaded by WF and executed.

  • + Share This
  • 🔖 Save To Your Account