For nearly 20 years, desktop applications of the Microsoft Office applications-such as Microsoft Office Word, Microsoft Office Excel, and Microsoft Office PowerPoint-have grown in popularity to the point that they are now ubiquitous in business environments. These applications have built a reputation in the software industry as reliable tools for creating, editing, and reviewing the documents that are critical to running a business. The introduction of Microsoft Windows SharePoint Services 2.0 into the Microsoft Office 2003 System extended the capabilities of applications even further by enabling the creation, editing, and reviewing of documents across teams in a collaborative environment.
Though tools such as Office Word and Office Excel that were designed to create, edit, and review documents are important to a business, these applications clearly do not offer the capabilities to manage the entire document life cycle. Many documents in a business environment must go through one or more approval processes. Other documents need to be published or archived. Some companies must follow regulations that mandate their documents be kept on record for a certain length of time before disposal.
When the Microsoft Office team members first began to consider what features they wanted to include with WSS 3.0 and MOSS, they knew they could improve their support for managing the full document life cyle. In particular, they began to consider how to add automation support for the tasks required later in the document life cycle such as approval, publishing, archiving, and disposition. It became evident that they needed to add support for developing reactive programs and integrating them into WSS and MOSS to automate workflow-style tasks on documents and list items.
The timing was fortuitous between the development schedules of the team at Microsoft building the WF and the teams within the Microsoft Office group building WSS 3.0 and MOSS. The design and development of the WF was far enough along that the Microsoft Office team was able to use it as the underlying platform to build workflow support into WSS 3.0.
The teams building WSS 3.0 and MOSS benefited from having a platform supplying much of the necessary infrastructure for developing and managing WF programs. The WF team benefited from having a large number of developers from the Microsoft Office team kicking the tires of the WF runtime and development tools long before the WF was released to the outside world. This enabled them to find bugs and design flaws and fix them very early in the product life cycle so that the WF could be adapted to the needs of large-scale, Web-based applications running in a Web-farm environment.
When the Microsoft Office team began to integrate WF support into WSS and MOSS, their primary design goal was to attach business logic to documents and list items using WF programs. The WF and its ability to create reactive programs that run in episodes is exactly what is needed for capturing business processes to automate tasks throughout the entire document life cycle.
Another critical design goal was to add a human dimension of responsibility and accountability because, after all, many business processes are reliant on humans and their actions. Humans are required, for example, to provide input in the form of an approval, a signature, or feedback. The Microsoft Office team felt that it was important to add support so that WF programs could assign tasks to users who were responsible for driving (or holding up) the business processes being automated.
In addition to assigning tasks, the Microsoft Office team felt it was important for users and their organizations to have access to information about the status of a business process that was being automated by a workflow instance. They came up with the idea that each workflow instance should be able to log entries into a workflow history list that would keep users up to date on workflow status. For example, a user should be able to navigate to a special page within a WSS site that displays the status of a workflow instance, including the steps it has gone through and the tasks (if any) that have been assigned to it.
When the Microsoft Office team began integrating WF support into WSS, they knew that it was important for site owners and users to be able to administrate and run WF programs without involvement from the IT department. WSS had made many other aspects of administration within a site collection accessible to users, and it was essential for the Microsoft Office team to make the administration of WF programs equally accessible.
While the Microsoft Office team spent a good deal of energy making their workflow story accessible to users and information workers, they did not want to forget about developers and their need to build custom WF programs. It was important to the Microsoft Office team that they extend the WF in such a way that SharePoint developers could create SharePoint-targeted workflows by using Visual Studio and the WF workflow designer with the same levels of convenience and productivity as developers experience when building WF programs for standard WF components and applications.
The final design goal might have been the biggest one. The Microsoft Office team wanted to provide several valuable out-of-the-box WF programs to automate common business processes, such as document approval and signature collection. This design goal was aimed at providing value to customers who either could not or did not want to spend money on custom development. However, the vast majority of out-of-the-box workflows created by the Microsoft Office team are included with MOSS but not with WSS.
WSS extends the WF by introducing the concept of a workflow template. At the heart of each workflow template is a single WF program that you create in Visual Studio by using the standard WF workflow designer. The main purpose of the workflow template is to integrate WF programs into WSS so that they can be installed, configured, and parameterized for use.
A workflow template is created by adding a Workflow element to a feature that is scoped to the level of the site collection. The definition for a Workflow element must point to a specific
WF program and can optionally contain references to one or more input forms that solicit additional information from users. The types of input forms that can be included as part of a workflow template will be discussed in the next section, titled “Workflow Input Forms.”
When it’s time to deploy a workflow template, you must first install the assembly DLL containing the WF program in the Global Assembly Cache (GAC). Next, you must install the feature that defines the workflow template as you would install any other feature with WSS. Finally, you activate the feature within any site collection in which you want to use the workflow template.
WSS does not let you run workflow templates directly on documents or list items. Instead, you must create an intermediate layer known as a workflow association. A workflow association is a named set of parameterization data that is used to bind a workflow template to a specific list or document library.
Once the feature with a workflow template is activated within the current site collection, a privileged user, such as the site or list owner, creates a new workflow association on any list or document library. This can be done by clicking the Workflow settings link on the List Settings page to navigate to a standard application page named AddWrkfl.aspx that’s used to create a workflow association, as shown in Figure 8-4. Although the page title says “Add a Workflow,” you now know that it really means to add a workflow association.
Figure 8-4: WSS provides a standard application page named AddWrkfl.aspx to assist users with the creation of workflow associations.
A primary function of the workflow association is to hold parameterization data for the workflow template that is used to initialize workflow instances. Keep in mind that for one particular list or document library in a WSS site, you can create two different workflow associations from the same workflow template and parameterize them in different ways.
For example, imagine that you have a workflow template that automates an approval process. You could create one workflow association to automate approvals that go through the Litware art department and another workflow association to automate approvals that go through the Litware legal department. Each of two different workflow associations would then be parameterized to use an approver from their respective departments.
As discussed in the previous section, WSS extends the WF with a human dimension by providing every workflow instance with access to a workflow task list and workflow history list. The workflow task list allows workflow instances to assign tasks to users involved in various business processes. The workflow history list allows workflow instances to log their actions so that users can keep apprised of their status. Yet, how does WSS know which task list and which history list should be associated with a particular workflow instance? That’s a job for the workflow association.
When a user creates a new workflow association through the standard WSS user interface, that user is given a choice of selecting an existing task list or creating a new task list. The user is also given a choice of selecting an existing history list or creating a new history list. The key point is that any valid workflow association must have a task list and a history list that are accessible to WF programs and visible to users.
While workflow associations are often created directly on lists and document libraries, WSS provides even more flexibility. A workflow association can also be created on a content type that exists within the Content Type Gallery for the current site. For example, you could create a workflow association on the built-in Document content type within the Content Type Gallery of a top-level site, thus making it possible to create and configure a single workflow association that is available to run on any document within any document library throughout the entire site collection.
You already learned that it is possible to create a workflow association on a list, document library, or content type within the Content Type Gallery for a site. However, a third and final option exists for creating a new workflow association. Instead of creating the workflow association for a content type within the site, you can also create a workflow association for one of the content types defined within a list.
For example, if you navigate from the List Settings page to the Advanced Settings page for a list or document library, you can enable the option to allow management of content types. Once you do this, you can add additional content types to the list as well as drill down into the settings for a content type that has been added to the list and create a new workflow association. Therefore, you can configure a list so that different items within it have different available workflow associations depending on their content type. In summary, there are three different levels at which you can create a workflow summary:
At the level of a list (or document library)
At the level of a content type defined at site scope
At the level of a content type defined at list scope
Once you create one or more workflow associations, you can then begin to create a workflow instance that represents a running instance of a WF program. Within WSS, each workflow instance must be associated with one specific list item or document. Because a workflow instance is started from a specific workflow association, it is also associated with one specific workflow template.
When a privileged user creates a workflow association, this user configures how workflow instances should be started. For example, you can create a workflow association that automatically starts a workflow instance anytime a new item or document is created. You can alternatively create a workflow association that gives users the ability to create workflow instances on demand through the standard WSS user interface.
WSS provides standard elements within the user interface to give users the ability to initiate and manage workflow instances as well as to see their status. The workflow menu item shown in Figure 8-5 appears in the standard ECB menu for list items and documents. The workflow menu item provides users with the ability to navigate to an application page named workflow.aspx that allows a user to see, initiate, and manage workflow instances for a specific list item or document.
Figure 8-5: A workflow association can be configured to allow users to launch workflow instances manually.
A typical view of workflow.aspx is shown in Figure 8-6. As you can see, this page provides a builtin facility in WSS that displays the workflow associations available to initiate new workflow instances. This page lists an aggregation of the workflow associations that are created on the list (or document library) as well as on the content type associations with that current item (or document). In addition to available workflow associations, the page also displays a list of workflow instances that are still running as well as those that have completed. Both lists of workflow instances let the user click on links to drill down the history of a particular workflow instance.
Figure 8-6: The standard application page named workflow.aspx provides workflow management over items and documents.
WSS displays the Workflow Status page named WrkStat.aspx when users want to drill down and examine the history of a particular workflow instance. This page (shown in Figure 8-7) displays standard information about the workflow instance, as well as a list of tasks created by the workflow instance and a history list showing activity that occurred on the workflow since it was initiated.
Figure 8-7: The Workflow Status page provides information on the status of one specific workflow instance.
Now that we have covered the high-level concepts involved with workflow templates, workflow associations, and workflow instances, we can revisit the topic of workflow input forms. These forms make it possible for a developer to design and implement a custom workflow template that interacts with users to solicit data to parameterize workflow associations and workflow instances.
When you design a workflow template, you can create four different types of input forms including an association form, an initiation form, a modification form, and a task edit form. Note that these forms are optional when you create a workflow template. You can add any one of these form types to a workflow template and omit the other three. You can also supply all four types of workflow input forms if you have a scenario that calls for it.
A custom workflow association form allows the developer to prompt the user for parameterization data when a new workflow association is created. A workflow association form is presented to the user as a final step when creating a workflow association. Note that the workflow association form can also be used by those who want to make modifications to parameterization data within an existing workflow association.
A custom workflow initiation form allows the developer to prompt the user for parameterization data when a new workflow instance is created from a workflow association. Note that workflow initiation forms can be used only when the workflow association allows users to start the workflow instance manually. When a workflow association is configured to start workflows automatically, it is not possible to prompt the user with a workflow initiation form.
Once a workflow instance has been started, there might be a need for the user to change some of its properties on the fly, such as who should approve the item or document in question. The workflow modification form is intended for this purpose. A developer can add a link to the Workflow Status page, making it possible for the user to navigate to the modification form for a particular workflow instance. Using the modification form, the developer can allow the user to perform whatever types of modifications make sense.
As you know, each workflow association is configured with a task list that makes it possible for workflow instances to create tasks and assign them to the users. WSS supplies a special content type named WorkflowTask with an ID of 0x010801. When you design a WF program to create tasks, you can choose the standard WorkflowTask content type or create your own custom content type. If you create your own custom content type, you must create it so that it inherits from the standard WorkflowTask content type.
One advantage to creating a custom content type for workflow tasks is that you can add extra fields beyond those defined in the standard WorkflowTask content type. A second advantage is that you can create a custom Task Edit Form. This allows you to take over the user experience when a user needs to edit a task. For example, you can supply a task edit form containing only the necessary controls, such as an Approve and Reject button.
Two different approaches can be used to develop custom input forms for a WSS workflow template. You can create your forms by using custom application pages, which are standard .aspx pages deployed to run out of the _layouts directory. We will discuss these workflow input forms in this chapter. If you can assume that your custom workflow templates will always run in an environment in which MOSS is installed, you also have the option of creating custom workflow forms using Microsoft Office InfoPath 2007.
There are many benefits to using Office InfoPath 2007 to create the forms for a custom workflow template. First, the integration of InfoPath Forms into a WSS workflow template significantly reduces the amount of code that you need to supply. Secondly, InfoPath forms provide a level of integration with the 2007 Microsoft Office suite client applications such as Word, Excel, Office PowerPoint, and Microsoft Office Outlook. While InfoPath forms can be presented to the user through the browser, they can also be hosted directly from within the 2007 Microsoft Office suite application, providing a more seamless user experience.
The obvious drawback to creating a workflow template that uses InfoPath forms is that it picks up a dependency on MOSS and cannot be used within environments running on WSS. For this reason, this chapter focuses on creating workflow input forms using .aspx files so that they can be deployed within any WSS 3.0 environment regardless of whether MOSS is also installed.