19.2. Exploring Workflow Technologies

While the theoretical concepts around Microsoft Workflow technologies have already been discussed in this chapter, this section familiarizes you with some of its practical aspects.

WF is available free with .NET Framework 3.5 and can be downloaded from the Microsoft Web site at http://msdn.microsoft.com/en-us/netframework/aa663328.aspx. It's one of the prerequisites for installing WSS v3 and MOSS 2007. SharePoint has its own implementation of many of the important runtime services provided with WF, such as persistence, tracking, notification, messaging, and roles.

However, it still relies on the WF runtime engine to execute the workflows and call the runtime services when and as required. Also, SharePoint Designer requires that you install WF to be able to use its workflow features. SharePoint Designer uses ASP.NET 2.0 Web services, which SharePoint implements to create, compile, and deploy workflows on SharePoint sites.

19.2.1. Understanding the workflow implementation in Windows SharePoint Services

WSS is one of the most popular implementations of workflow infrastructure provided by WF. Because the primary goal of a SharePoint deployment is to introduce enterprise-level collaboration and process management, workflows provide an important role in completing the SharePoint end-to-end offering in people, document, and information management. MOSS 2007 builds on this infrastructure provided by WSS and offers a number of out-of-the-box workflows for many common scenarios, such as document approval, feedback collection, etc.

WSS provides the hosting infrastructure for the workflow runtime in the IIS 6.0 worker process (w3wp.exe). As discussed earlier, the workflow runtime includes a base set of workflow activities and default implementation for runtime services. WSS builds on these base functionalities and extends them with activities and services specific to SharePoint. By default, the WF runtime engine includes the services for scheduling, persistence, etc., and supports the infrastructure for creating custom runtime services. WSS uses this ability to provide its own version of the default runtime services, such as persistence and tracking, and adds new services for notifications, messaging, transactions, and roles. Figure 19.4 shows an example of a SharePoint workflow architecture.

Workflows created for SharePoint use not only the default workflow activities provided by WF but also make use of the custom activities that SharePoint makes available for interaction with SharePoint lists and libraries. These custom activities can also be used in SharePoint Designer to declaratively create workflows. SharePoint also exposes a workflow object model that developers can use to programmatically design custom workflows.

MOSS builds on the workflow infrastructure provided by WSS and extends the workflow implementation. While WSS only has one out-of-the-box workflow (called Three-States workflow), MOSS provides the following workflows for common scenarios that SharePoint site users can use to create instances of and associate with lists and libraries:

• Approval

• Collect Feedback

• Collect Signatures

• Disposition Approval

• Translation Management

Figure 19.4. The diagrammatical representation of a SharePoint workflow architecture

All these workflows are based on WF, but the implementation is obfuscated for the SharePoint users through Web pages that can be used to configure them. SharePoint provides Web pages that can be used to associate these workflows with lists, libraries, or content types, start workflow instances, and interact with the workflows. These workflows are installed on the SharePoint server as features that can be activated on a site basis. Developers can use Visual Studio to create similar workflows and then deploy them to SharePoint servers.

To establish a SharePoint workflow creation life cycle, you must first install the workflow feature (or solution) to a SharePoint Web server and then activate it for a particular site collection in a SharePoint Web application. After deploying the workflow, you can associate the workflow with required lists or libraries. Then, you can create workflow instances that perform the workflow logic on the respective item in the list or library.

While the workflow instance runs, depending on the workflow implementation, it can access a number of SharePoint resources, such as other lists or libraries, task lists, workflow history lists, etc. It's important that the user under whose context the workflow instance begins has appropriate SharePoint permissions for these resources.