Export (0) Print
Expand All

Chapter 8: Creating Custom Workflows for Windows SharePoint Services and Office SharePoint Server

Windows SharePoint Services 3

This article is an excerpt from SharePoint 2007 and Office Development Expert Solutions by Randy Holloway, Andrej Kyselica, and Steve Caravajal from Wrox Press (ISBN 978-0-470-09740-3, copyright 2008 Wiley Publishing, all rights reserved). No part of these chapters may be reproduced, stored in a retrieval system, or transmitted in any form or by any means—electronic, electrostatic, mechanical, photocopying, recording, or otherwise—without the prior written permission of the publisher, except in the case of brief quotations embodied in critical articles or reviews.

Download the sample code that accompanies the book

Businesses are placing greater demands on their employees to make better decisions faster in order to remain competitive in the marketplace. When attempting to come to a decision, we typically follow a series of steps. The steps can be formal in terms of a standard operating procedure or informal in the sense of an implicitly understood way of operating, but collectively they represent a business process. Because these business processes fundamentally require human interaction, making better decisions faster may be limited by human interactions. Therefore, by increasing the effectiveness of human interactions, we can improve the overall efficiency and quality of the outcome. Business processes can be modeled using flow charts and represented using workflow terminology. Software that facilitates and manages this "human workflow" can provide a way of automating the interaction among the people participating in the process and thereby deliver improved effectiveness.

In previous chapters, you have seen how Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 provide a robust, customizable, and extensible collaboration environment that enables team members to share business information contained in SharePoint data repositories (for example, documents and lists).

Business processes such as document approval can be automated by associating a workflow with the SharePoint data, notifying the approver of work to be done and the submitter of the outcome of the approval process. Other workflow examples include coordinating the interaction of a group of individuals (such as preparing a Microsoft Office PowerPoint presentation for a conference or a new project proposal) or tracking a set of issues, including the tasks, the responsibilities, and the status, on an ongoing basis.

Windows SharePoint Services can execute workflow applications through the use of technology called Windows Workflow Foundation (WF). People interact with these workflows through the web browser and applications in the 2007 Microsoft Office system such as Microsoft Office Word 2007. Windows SharePoint Services provides the framework for utilizing WF, and Office SharePoint Server extends the capability by delivering several workflows that automate common business processes. Custom workflows can be created using tools such as Microsoft Office SharePoint Designer and Microsoft Visual Studio 2005, and then associated with SharePoint data.

Therefore, workflow is not only part of the collaboration process, but also represents and automates the collaboration process. Workflows expedite the decision-making process by helping to ensure that the right information is made available to the right people at the right time. Workflows also help ensure that individual workflow tasks are completed by the right people and in the appropriate sequence (or in parallel).

This chapter focuses on an introduction to WF and the tools for creating custom workflows: Office SharePoint Designer and Visual Studio Designer for Windows Workflow Foundation.

The main objectives for this chapter are as follows:

  • Understanding the architecture, concepts, and capability of Windows Workflow Foundation

  • Understanding the concept of a workflow and the role that Windows SharePoint Services and Office SharePoint Server play in workflow creation, deployment, and utilization

  • Creating custom workflows using SharePoint Designer and Visual Studio Designer for Windows Workflow Foundation

  • Comparing the capabilities of SharePoint Designer and Visual Studio Designer for Windows Workflow Foundation for creating custom workflows

Contents

Windows Workflow Foundation (WF) is a component of the Microsoft .NET Framework 3.0, which resides natively inside the Windows Vista operating system and is available as a download for Windows XP Service Pack 2 and Windows Server 2003. WF provides the capability to create an application that executes a multi-step sequence of work items logically formulated to model a business process. This application consists of one or more workflows, and each workflow is composed of one or more activities.

Workflow Activities

A workflow is composed of discrete work units that are organized into a predefined order or set of states. In the context of WF, each work unit is called an activity. Activities can be performed by the system (for example, computers and applications) or by individuals (users), and they represent the building blocks of any WF workflow. In WF, activities have the following possible characteristics:

  • Activities represent actions, such as approving or rejecting a document, sending an e-mail, creating a list item, deleting a list item, etc.

  • Activities can also control the logic and flow of execution in the workflow, such as looping, pausing, else-if branching, and so on.

  • Activities can be composed of methods, properties and events. Activities can also be composed of other activities. These activities are called composite activities.

  • WF provides a set of predefined activities that can be used during the workflow authoring process. Custom activities can be created using Visual Studio 2005 Designer for Windows Workflow Foundation.

  • Activities are executed in a predefined order by the WF runtime engine.

Workflow Markup

WF workflows utilize several different files to describe and document their functionality. The number and composition of these files varies depending on the actual workflow functionality, but it typically includes an XML file, or markup file, and one or more code files.

XML File

The XML file includes a declarative description of the workflow and is written in Extensible Application Markup Language (XAML). XAML files can be created with any text editor because the schema is publicly available. SharePoint Designer and Visual Studio 2005 Designer for Windows Workflow Foundation both provide a graphical interface to create workflows and automatically generate the XAML description. XAML files have the extension .xoml.

Code File(s)

One or more code files describe the functionality and business logic of the workflow. These files can contain C# or Microsoft Visual Basic code or declarative markup (rules).

The workflow markup can be precompiled into .NET assemblies or compiled directly at runtime depending on how the workflow was created and deployed. We'll revisit the details of the markup later in this chapter when we create a custom workflow. Regardless of how it was created, execution is accomplished by the WF runtime engine.

Workflow Execution

The WF runtime engine is not a service but a class that is instantiated within a .NET process that is hosted by another application (that is, WF is not an executable that is launched by double-clicking the code file). The WF runtime manages workflow execution, including the loading and unloading of workflows, and it allows workflows to remain active (persistence) for extended periods of time, including a reboot of the computer. Workflow execution depends on a set of "pluggable" services that provide support for persistence, transactions, scheduling, and tracking. These services are discussed briefly in the following list:

  • Persistence: The state of an executing workflow is temporarily stored to some medium and removed from memory. At some future point in time, the workflow state data is retrieved by the WF runtime, the workflow is brought back to life, and its execution continues until another point of suspension is necessary or termination. This capability is sometimes referred to as dehydration and hydration of workflows.

  • Transaction: This service provides the capability to combine completed workflow steps into atomic units (batch) so that consistency is maintained between the internal state of the workflow and the external data. For example, SharePoint workflow services provide methods that perform actions, and event handlers that dehydrate and hydrate the workflow. Batched actions are not committed until the workflow is dehydrated.

  • Scheduling: Workflow execution must be managed, just as it would be with any other application code. Specifically, this service controls and manages the number of threads, their availability, their priority, and the order of their execution.

  • Tracking: The tracking service monitors the flow and execution of currently running workflow instances. This information is made readily available to the host and is capable of being persisted.

A workflow is a model or representation of a real-world process. Recall that the workflow is composed of individual work units or items called activities. The workflow describes how these activities relate to one another, their order of execution, and how data flows into and out of the workflow.

WF provides a library of prebuilt activities. Additional activities can be created and made available for use by other workflows. WF provides two types of built-in workflows, sequential and state machine:

  • Sequential: This workflow executes as a series of steps in a predefined order until the last step is completed. Because the workflow can respond to external events, the actual execution order varies, including branching and multiple parallel paths.

  • State Machine: This type of workflow is represented by a set of predefined states, transitions, and actions. In response to some action or event, the workflow will execute a transition and move to another state. A beginning state is necessary to launch the workflow, and a final state defines the termination of the workflow; however, a final state is not required.

It's important to reinforce the concept that WF is not a complete workflow application. It is a foundation for software developers to create workflow-enabled applications. WF functionality runs inside a workflow host, which can be any Windows application process or service. The WF runtime can be customized to accommodate specific host requirements and different application requirements by replacing or extending the native runtime services discussed previously in the chapter.

Windows SharePoint Services serves as the host for the WF runtime feature. It has the capability to execute WF workflows and includes one out-of-the-box workflow called the three-state workflow. As part of being the host for the WF runtime, Windows SharePoint Services provides custom implementations of some of the key WF services. For example, the WF persistence service needs to be customized to accommodate SharePoint's requirements, as described in the following paragraph.

Human workflow interactions can extend into hours and even days. For example, in a document approval process, the approval or rejection of a document could encompass multiple approvers and include author revisions before the process is complete. Under practical conditions, the approval workflow cannot remain in memory over this extended time. Review by an approver introduces a natural delay whereby the runtime engine is waiting for input. At this point, the workflow can be dehydrated. Activities that have been successfully executed are batched into a single SQL Server transaction. If the transaction is successful, then Windows SharePoint Services unloads the workflow instance from memory. The workflow can be hydrated in response to external events. For example, when the reviewer changes the approval status to accepted or rejected, Windows SharePoint Services loads the persisted workflow data and recreates the workflow instance. The workflow instance receives the approver's input, and the workflow continues.

Persistence helps maintain a link between the state of the dehydrated workflow and the document or list item with which the workflow is associated. This link is critical to Windows SharePoint Services and illustrates a key SharePoint requirement that is satisfied by customizing the persistence service. Therefore, despite the fact that numerous workflows may be executing at any time, only a small subset of those workflows may be resident in memory and consuming critical resources. The ability to customize the native WF services is a feature of the WF pluggable environment and is at the discretion of Windows SharePoint Services as the WF host.

Workflow Templates

Workflow capability is delivered to Windows SharePoint Services through the concept of templates. Templates describe the workflow and govern its action, are the result of the workflow authoring process, and must be deployed to the Windows SharePoint Services web server. Workflows are enabled by creating an association between a specific template and a document library, list, or content type. This template is then loaded by the runtime to create an instance. Multiple workflows can be associated with any list or document library directly, or associated with a content type.

Workflow Instances

An instance of a workflow is created once a workflow is started. A single list or document may have several different workflows available, and instances of each of these workflows can execute concurrently. However, only one instance of any specific workflow may be active at any point in time for an individual list or document.

A workflow instance can be started using the web browser or an Office client. The workflow can be configured so that it starts whenever a new item is created, an existing item is changed, or a new major version has been published. Users that have been assigned tasks can be automatically notified once previous users have completed work on an item. Users can be assigned either in series or in parallel, and have the flexibility to assign tasks to someone else. While running, workflow instances can be tracked and their performance monitored. For example, the Activity Duration report describes the length of time each activity and workflow instance takes to complete. The Cancellation & Error Report shows you which workflows are being canceled or are encountering errors before completion.

There are several different phases to creating a custom workflow: authoring, deploying, associating, and instantiating. Within each of these phases, roles are played by different individuals who participate in the workflow: workflow author, approvers, users, and administrators.

Authoring and Deploying a Workflow

Each workflow consists of logic that defines the workflow and the user interaction with the workflow. For Windows SharePoint Services, users will interact with workflows via web forms. Therefore, Windows SharePoint Services relies on ASP.NET to display its forms, and aspx pages to represent those forms. The workflow logic is defined during the authoring of custom workflows by the tool being used.

SharePoint Designer and Visual Studio 2005 Designer for Windows Workflow Foundation (DWF) are two different tools for creating custom workflows. Each has different capabilities and advantages, which are discussed in detail later in the chapter. For now we will cover only some of the key differences:

  • SharePoint Designer workflows cannot include custom .NET code, are limited to a predefined list of activities, and are created specifically for a single list or document library. The result is a workflow template that is automatically deployed to the web server. Creating custom workflows using SharePoint Designer is designed for the nonprofessional developer, such as an information worker or web designer.

  • DWF produces a workflow template that can contain custom .NET code, can utilize custom activities, and can be utilized across sites, multiple lists, document libraries, and content types all at the same time. Custom activities can also be created without creating a custom workflow. Once the custom template or activity is created, it must be deployed to the web server by a server administrator. Custom activities, once deployed, are also available for use by SharePoint Designer.

Regardless of the tool, the outcome is a workflow template. SharePoint Designer simplifies deployment while DWF requires assistance from a server administrator or equivalent with the proper server permissions. Once workflows have been created and deployed, they must be associated with a list or content type before they can be used.

Associating a Workflow

A workflow template must be "attached" or associated with a SharePoint list or content type before an instance can be created (instantiated) and executed. As you've already seen, SharePoint Designer templates are associated with a list or document library during the design of the workflow (design time). For DWF, association occurs after deployment, and the scope of the association is not only broader but can also include Windows SharePoint Services content types. Template association is accomplished via the web browser. ASP.NET web pages can be used to represent data entry forms during the configuration of the association.

The same template can be associated with multiple lists, multiple document libraries, and multiple content types at the same time. Each different association can be configured specifically for the attached item depending on the requirements. Once association has been completed, a workflow instance can be created and executed.

Instantiating a Workflow

A workflow instance is an executing workflow. For each specific association, a single workflow instance can be created and started. A workflow can be started in one of three different ways:

  • The workflow can be started manually from the SharePoint list item or document and can be started from the Office client application.

  • The workflow can be configured to start automatically when an existing document or list item is changed.

  • The workflow can start automatically when a new document or list item is created.

Creating the workflow instance is the last step that launches an executing workflow. As part of creating an instance, the user who launches the workflow can interact with the workflow by providing customization or configuration data that will be passed to the workflow and used during execution. A user can also interact with an executing workflow and modify the executing instance if the workflow was designed to allow this capability. If these user interactions are necessary, the workflow author must provide workflow forms as part of the authoring process.

Workflow Forms

Workflow forms enable user interaction with the executing workflow and therefore make the workflows dynamic and more flexible. The form collects information from users at predefined times and enables users to interact with the workflow tasks. Workflow forms can be classified into three different types, each of which is briefly summarized in the following list: association and initiation forms, task forms, and modification forms.

  • Association forms enable default values to be entered by the user, or configuration information to be set by the administrator. Initiation forms provide the opportunity to enter starting values for forms that launch manually.

  • For workflows that require users to complete tasks, task forms can track actions, maintain status, and trigger events that influence the executing workflow.

  • Modification forms can be used to adjust the flow of the executing workflow without the need to restart the workflow.

Regardless of the form type, all workflow forms need to perform two functions:

  1. Collect data from the user.

  2. Call an object model (OM) function to perform the desired action, create an association, start the workflow, edit tasks, or modify the execution. User data is passed to the OM function as a parameter, and the function passes the data into the workflow.

For workflows in Windows SharePoint Services, ASP.NET web forms are used to represent workflow forms because the user interacts with the workflow via the web browser. Therefore, the workflow author would need to create the web forms and write the custom code that collects the data and calls the OM.

The primary responsibility of Windows SharePoint Services as the WF host is to provide the capability to execute workflows, but it also includes one out-of-the-box workflow. SharePoint Designer and DWF are two different authoring tools that can be used to create custom workflows. Both of these tools produce workflow templates. Workflow instances are created from these templates after the template is associated with the SharePoint list or content type.

Workflow forms can also be used as part of the custom workflow. Because Windows SharePoint Services relies on ASP.NET web forms for workflow forms, these forms must also be created and deployed to the web server, along with the workflow templates, prior to use. Additionally, custom code is necessary to move user data from the ASP.NET web form into the workflow. SharePoint Server provides an alternative to creating custom workflows because it provides several out-of-the-box workflows ready for use without writing any custom code. It enables Office clients to interact with workflows and simplifies web form creation and data processing.

SharePoint Server extends the workflow capabilities of Windows SharePoint Services in three different areas: support for the 2007 Office system clients to launch workflows, the ability of workflows to use Microsoft Office InfoPath 2007 forms, and a set of six predefined workflow templates. The SharePoint Server templates supplement the Three-State workflow template provided by Windows SharePoint Services.

Predefined Templates

The predefined workflow templates can be utilized directly without writing any custom code and can be configured through the web browser interface. The Windows SharePoint Services and SharePoint Server out-of-the-box workflows include the following:

  • Three-State: Used to track and move list items through a series of states. Can be configured to react differently at various stages.

  • Approval: Routes a document for approval. Approvers can approve or reject the document, reassign the approval task, or request changes to the document.

  • Collect Feedback: Routes a document for review. Reviewers can provide feedback, which is compiled and sent to the document owner when the workflow has completed.

  • Collect Signatures: Gathers signatures needed to complete an Office document. This workflow can be started only from within an Office client.

  • Disposition Approval: Manages document expiration and retention by allowing participants to decide whether to retain or delete expired documents.

  • Group Approval: Similar to the Approval workflow, but uses a designated document library and offers a personalized view of the approval process. It includes other features such as a hierarchical organization chart from which to select the approvers and allows the approvers to use a stamp control instead of a signature. This solution was designed specifically for East Asian markets.

  • Translation Management: Manages document translation by creating copies of the document to be translated and assigning translation tasks to translators.

The number of out-of-the-box workflow templates available varies depending on the site template selected to provision the site and the features that have been activated for the given site. Features represent a new SharePoint technology that enables the deployment and activation of SharePoint site components. The name can be misleading; it doesn't refer to the SharePoint feature set like Web Parts, lists, and so on. (Features are discussed in more detail in Chapter 5.)

SharePoint Server workflows are deployed as Features. A list of the available workflow templates is shown in the Site Collection Workflows gallery, accessed from the Site Settings web page. An example is shown in Figure 8-1.

Figure 8-1

Figure 8-1

As you can see from Figure 8-1, the Approval, Collect Feedback, Collect Signatures, Disposition Approval, and Translation Management workflows are active and ready for use. The Group Approval and Three-State workflows are not active. These two inactive workflows can be activated individually as Site Collection Features from the Site Collection Features web page, as shown in Figure 8-2.

Figure 8-2

Figure 8-2

You'll notice in Figure 8-2 that the Group Approval workflow feature (fifth from the top) and the Three-State Workflow feature can be activated by clicking the Activate button. Once these features are activated, the corresponding workflows are visible in the Site Collection Workflows gallery. The process just described for identifying the available workflow templates and activating them also applies to custom workflows that have been created and deployed using the Feature process.

Many of the SharePoint Server workflow templates use Office InfoPath 2007 forms to present data entry or configuration capability to the user. This enables workflow interaction for the Office clients, a feature not available for Windows SharePoint Services workflows.

InfoPath Workflow Form Advantages

There are several advantages to using InfoPath 2007 forms as workflow forms:

  • They can be used directly from client applications in the 2007 Office system (Word, Excel, PowerPoint, Outlook, InfoPath). Client applications and ASP.NET web forms can both host InfoPath forms for workflow. While using an Office client, the InfoPath task form will appear as a dialog directly in the application. This form is exactly the same form you would see in the browser, so a single InfoPath form can be utilized for both environments.

  • InfoPath forms are designed in a visual designer similar to SharePoint Designer and are created using a drag-and-drop user interface. A form designer does not need HTML or ASP.NET development experience.

  • InfoPath workflow forms don't require that custom code be written to process form data. SharePoint Server web form pages that host the InfoPath forms make the OM function calls that handle data processing. If the out-of-the-box form processing does not meet your needs, you can write your own custom code as part of the web form or you can write custom code as part of your InfoPath form.

SharePoint Server provides out-of-the-box workflows and enhances workflow functionality in general. The integration of InfoPath forms with the custom workflows enables both Office client and web browser interaction. A single InfoPath form can be utilized for both experiences. Unlike using ASP.NET web forms for user interaction, you have no need to write custom code to move data between the InfoPath form and the workflow. As discussed earlier, this is different from Windows SharePoint Services workflows, which can only utilize ASP.NET forms and therefore have no Office client capability and require custom code for forms processing

The InfoPath forms that are utilized for the out-of-the-box workflows can be viewed outside of their associated workflows. To view these forms, navigate to c:\Program Files\Common Files\ Microsoft Shared\web server extensions\12\Template\Features. Perform a search for *.xsn and you will see a list of InfoPath forms associated with deployed features. Before viewing, copy any of the forms you are interested in looking at to a separate folder.

If the out-of-the-box templates don't provide the necessary capability, custom workflow templates can be created using SharePoint Designer and Visual Studio Designer for Windows Workflow Foundation. That's the subject of the rest of this chapter.

It's time to look at an example to illustrate some of the concepts we've been discussing. One of the most common human workflow scenarios is related to content approval. Figure 8-3 shows a flowchart describing an approval and routing business process. This scenario can be represented by a custom workflow. Before we walk through creating the workflow, we'll discuss the overall process.

Figure 8-3

Figure 8-3

Content Approval Workflow Scenario

The approval process is initiated when a user or author creates a new document and saves the document to a SharePoint document library (or uploads a new document). Individuals responsible for approving the content are notified by e-mail that there is new content pending approval, and confirmation is also sent automatically to the author. At this point in the process, a delay is introduced into the workflow due to the time it takes for an approver to review the material and decide whether to accept or reject. The approver downloads and reviews the content. After review, the content is either accepted or rejected. Based on the reviewer's response, the workflow can follow two different parallel paths:

  • If approved, then the document is moved from its current location to a different document library for published content. An e-mail is sent to the author and approvers notifying them that the document has been approved.

  • If the content is rejected, then the document is moved to another document library and the author and approvers are notified electronically.

Regardless of the path, the workflow terminates once notification has completed.

Creating the Content Approval Workflow: Exercise and Tutorial

The following is a step-by-step walkthrough for creating a custom workflow that models the business process outlined in Figure 8-3.

This walkthrough introduces you to the concept of creating a custom workflow using SharePoint Designer. You are encouraged to walk through this exercise on your own:

  1. Create a new team site called Developers Team Site or use one you have already created.

  2. Create three new document libraries and name them Submitted, Published, and Rejected. For the Submitted document library, enable "Require content approval for submitted items" (from the Versioning Settings page).

  3. Open SharePoint Designer. Close any site that may be open using the File ➪ Close Site command.

  4. Open your Developers Team Site by choosing File ➪ Open Site. Inside of the Open Site dialog, enter the URL of your team site for the Site Name and click Open.

  5. Open the Workflow Designer dialog by selecting File ➪ New ➪ Workflow. Assign the name Publishing to the workflow. Attach the workflow to the Submitted list. Enable "Automatically start this workflow when a new item is created" and disable all other start options. The result, with the Workflow Designer dialog showing the initial configuration for the Publishing workflow, is shown in Figure 8-4. Click Next.

    Figure 8-4

    Figure 8-4
  6. Assign the name Launch and Wait to the Step Name.

  7. From Conditions, select Compare Submitted Field. Assign Field to Approval Status and Value to Pending. From the Actions menu, choose Send an email. Click this message hyperlink to open the Define Email Message dialog. Click the address book icon at the end of the To: line to open the Select Users dialog. Select the Approvers group and add it to Selected Users. The result should resemble what is shown in Figure 8-5. Add the user who created the current item to the CC: line using a similar process. Fill out the e-mail appropriately or leave it blank and then click OK. The e-mail message should resemble the one shown in Figure 8-6.

    Figure 8-5

    Figure 8-5
    Figure 8-6

    Figure 8-6
  8. From Actions, select More Actions and then select "Wait for field change in current item" and click Add. Assign Field to Approval Status. Change the "to equal" phrase to "not equal" and assign Value to Pending. This completes the Launch and Wait step. Compare your result to that shown in Figure 8-7.

    Figure 8-7

    Figure 8-7
  9. Under Workflow Steps, click the Add Workflow Step hyperlink. Assign the name Review and Routing for step 2.

  10. From the Conditions option, choose Compare Submitted Field. Click the Field hyperlink and select Approval Status. Click the Value hyperlink and select Approved.

  11. From Actions, select Copy list item. Click the "first this list" hyperlink and select Current Item. Click the "second this list" hyperlink and choose Published.

  12. From Actions, select Delete Item. You may need to choose More Items in order to see this option. Click the "this list" hyperlink, select "current item," and click OK.

  13. From Actions, select Send an email. Click the "this message" hyperlink and fill out the e-mail. Send an e-mail to the user who created the current item and CC: the Approvers group. An example of the completed e-mail for an approved document is shown in Figure 8-8.

    Figure 8-8

    Figure 8-8
  14. Click the Add 'Else If' Conditional Branch hyperlink.

  15. Add the Compare Submitted Field condition for the second condition. Assign Field to Approval Status, and Value to Rejected.

  16. From Actions, select Copy list item. Assign the first "this list" to Current Item and the second to Rejected.

  17. Add an action to delete the current item.

  18. Add an action to Send an e-mail to the item creator stating that their document has been rejected and CC: the Approvers group. This completes the Review and Routing step; an example is shown in Figure 8-9.

    Figure 8-9

    Figure 8-9
  19. Click Finish. As described previously, workflows authored using SharePoint Designer are automatically deployed and bound to the specific list during creation. The dialog shown in Figure 8-10 confirms that the Publishing workflow has been deployed and associated with the Submitted document library and that no instances have been created.

    If you are going to utilize the e-mail capability from SharePoint Designer workflow, make sure that you have configured an e-mail server as part of your SharePoint deployment. If not, the workflow may have problems and not function as intended.

    Figure 8-10

    Figure 8-10
  20. Navigate to the Submitted documents library. Create a new document and save it with the name First Document to the Submitted document library. Add some example text if you wish, such as this is a test of a new workflow. Close Word.

  21. View the newly created document item in the Submitted library. Notice that the Approval Status of First Document is pending because you enabled content approval (back in step 2). Also notice that the Publishing column contains In Progress, indicating that an instance of the Publishing workflow has been created. Navigate to the Workflow Settings page of the Submitted document library to confirm that one instance has been created and is currently running.

  22. Approve First Document by hovering the mouse over the item inside of the Submitted document library, clicking the drop-down arrow to reveal the context menu, choosing Approve/Reject, and then approving the content in the subsequent pages.

  23. Once the document has been approved, confirm that the document is moved to the Published document library.

  24. Repeat the process with a second document but this time reject the content to demonstrate that the created document is moved to the Rejected document library.

  25. As an exercise, view the e-mails sent to the author after the document is submitted and approved or rejected. In addition, you can add users to the Approvers group and review the corresponding e-mail communication.

Creating the Content Approval Workflow: Review

The previous exercise demonstrated several key points, advantages, and limitations of the SharePoint Designer environment for creating custom workflows:

  • A workflow is a model that represents a real-world business process. Therefore, a workflow consists of a series of one or more steps.

  • SharePoint Designer creates custom workflows without writing any custom .NET code. The workflow author associates a sequence of conditions and actions with a single SharePoint list or library. Changes to the SharePoint item can trigger actions in the workflow.

  • The conditions and corresponding actions chosen by the workflow author are formulated into a set of rules. Each rule is comprised of zero, one, or more conditions and one or more actions. These rules apply conditional logic so the workflow performs the associated action only if that condition is true. Multiple actions can be associated with a single condition, and actions can be subject to compound conditions. The actions in our custom workflow were performed serially but could have been executed in parallel.

  • SharePoint Designer takes this information and creates a rule-based template, based on XAML, that represents the custom workflow. For those interested, you should note that our custom workflow produced three separate files. These files are described as follows and can be viewed from the SharePoint Designer Workflows folder, as shown in Figure 8-11:

    • Publishing.xoml: The workflow markup file. This is only needed if the workflow uses conditions.

    • Publishing.xoml.rules: This is the workflow rules file.

    • Publishing.xoml.wfconfig.xml: This is the workflow configuration file.

    Figure 8-11

    Figure 8-11

A detailed discussion of the contents of each of these files is beyond the scope of this chapter. SharePoint Designer publishes these documents to a hidden document library called Workflows for each SharePoint site. The Workflows document library is hidden from the web browser by default. To enable viewing of this document library, right-click the Workflows folder in the SharePoint Designer folders list and select Properties. Select the Settings tab and uncheck the Hide from Browsers check box and click OK (see Figure 8-12).

Figure 8-12

Figure 8-12

This example illustrated the use of SharePoint Designer to create a custom workflow. Note a few key points:

  • During initial definition of the SharePoint Designer workflow, it must be associated with a specific list or library

  • The workflow template is automatically deployed to Windows SharePoint Services. No additional administration or configuration is necessary.

  • The workflow was initiated automatically in response to a new item being created.

  • The SharePoint Designer workflow, once initiated, executes in the security context of the logged-on user. This has implications for any resource that the workflow is accessing. For example, from our scenario, if the logged-on user did not have permission for one of the document libraries accessed by the workflow, then the workflow would not work properly.

SharePoint Designer has the capability to create custom workflows that are configured to be manually started by the user. Additionally, SharePoint Designer can automatically create forms that are displayed to the user so that the workflow can collect information from the user. These forms are .NET aspx pages. In the next scenario, we will create another SharePoint Designer workflow that illustrates these and other capabilities.

Quality Assurance Testing Scenario

Imagine the following scenario: Your company wants to track the types of quality assurance testing the development team is performing, including the results of that testing. Developers and QA testers will submit and store testing documents to a document library, and these documents will contain the details of testing that is to be performed. This library needs to show the status of this testing (Pending, Successful, Failed) on an ongoing basis. After submitting the document, the user needs to manually launch a workflow that tracks the status of the testing. The workflow needs to create a task in the Tasks list on the SharePoint site. This task maintains the status of the testing. Supervisors of the technical personnel submitting the test need to be notified that a new test has been submitted. QA testing personnel will complete the testing and then update the Tasks list to indicate the result of the testing. To complete the process, the document library status needs to be updated, and the task in the Tasks list needs to be deleted.

Creating the Quality Assurance Testing Scenario: Exercise and Tutorial

  1. Create a document library called QA Testing on the Developers Team Site used previously. Create a column called Test Result for the QA Testing library. Select Choice for the information type and enter Successful, Failed, and Pending as the possible options. Set Pending as the default value.

  2. Start SharePoint Designer and open the Developers Team Site.

  3. Create a new workflow called QA Test Assessment. Attach QA Test Assessment to the QA Testing list. Ensure that the workflow is configured to start manually only.

  4. Click the Initiation button to reveal the Workflow Initiation Parameters dialog. This dialog enables the workflow designer to automatically generate an ASP.NET web form that will collect data from the user prior to execution of the workflow.

  5. Click the Add button. Enter Supervisor's Email Address as the field name. Keep Single line of text as the Information type. Click the Next button. Leave the Default Value field blank and click Finish. Click the OK button and then click Next.

  6. Enter Create Task and Notify for the Step Name. Leave the first condition blank because you always want the first action to execute.

  7. From Actions, select Collect Data from a User from the drop-down menu. Click the Data hyperlink to reveal the Custom Task Wizard dialog. This dialog provides the capability to enter details of a custom task that will be created and assigned to a user in order to collect data from the user. Click Next.

  8. Enter QA Test Result for the Name and Result from the quality assurance assessment of the submitted test as the Description. Click Next.

  9. Click the Add button to add custom fields. Enter QATestResult for the Field name, Field to hold the result of the assessment as the Description, and select Choice as the Information Type. Click Next.

  10. For options, enter Successful on one line and Failed on the next line. Uncheck the Allow blank values check box. Click Finish. Click Finish one more time to return back to the Workflow Designer dialog.

  11. Click the This User hyperlink. Select "User who created current item" and click the Add button. Click OK.

  12. At the end of the collect data action sentence, click the Variable:collect hyperlink and select Create a New Variable from the drop-down menu.

  13. Enter QATestResultID as the Name and click OK. This completes the first step of the QA Test Assessment workflow.

  14. Click the Add Workflow Step link and name the step Process QA Result.

  15. Click Conditions and select Compare Any Data Source. Click the Value hyperlink and then click the fx button that subsequently appears. In the Lookup Details section, select Tasks from the Source drop-down and then select QATestResult from the Field options. Within the Find the List Item section, select Tasks:ID in the Field selection and then click the fx button. Select Workflow Data for the Source in the new dialog box that appears and Variable:QATestResultID for the Field option. Click OK and then click OK again.

  16. Click the second Value hyperlink and select Successful from the list.

  17. From Action, select "Set field in current item." Click the Field hyperlink and select Test Result from the drop-down menu. Click the Value hyperlink and select Successful.

  18. From Action, select Delete item. (If the Delete item is not visible, click More Actions.)

    Click This List and select Tasks. Select Tasks:QATestResult in the Field drop-down menu and Successful for the value. Click OK. If a dialog box displays asking if you want to continue, click Yes.

  19. In the upper-right corner of the Condition/Action step, click the inverted triangle, and select "Run all actions in parallel."

  20. Click the Add 'Else If' Conditional Branch link.

  21. Add a second condition that tests whether QATestResult equals Failed. If so, set the Test Result column to Failed. Delete the task from the Tasks list. You can refer to steps 15–19 if you need help in creating the condition.

  22. Feel free to also add e-mail notification for the item creator, just you did in the previous exercise, and e-mail notification of the submitter's supervisor.

  23. Click Finish to complete the workflow and deploy the template to Windows SharePoint Services.

  24. Review the QA Test Assessment workflow in the Workflows folder in SharePoint Designer. Note that there are five separate files, similar to what you saw previously for the Publishing workflow but two additional aspx files that represent ASP.NET web forms that were automatically generated to accept user input.

  25. Navigate to the QA Testing document library and create a new document. Launch the QA Test Assessment workflow from the document's context menu. Enter an e-mail address for the supervisor and click Start.

  26. Navigate to the Tasks list. Select Edit Item from the context menu of the QA Test Result item. Assign the QATestResult to Successful and click Complete Task.

  27. Confirm that Test Result = Successful for the document in the QA Testing document library, and that the item in the Tasks list has been deleted.

Creating the Quality Assurance Testing Scenario: Review

SharePoint Designer automatically generates ASP.NET web forms whenever user input is required for the executing workflow. The SharePoint Designer workflow author can create two different types of workflow forms: an initiation form and a task edit form:

  • Initiation form: This form gathers information from users when they start the workflow. Initiation forms are displayed to users when they manually start a workflow on a given SharePoint item. Recall that the Publishing workflow in the Content Approval Workflow exercise started automatically and therefore did not require an initiation form. Because the QA Test Assessment workflow required the user to enter the supervisor's e-mail address, SharePoint Designer automatically generated an ASP.NET web form called QA Test Assessment.aspx.

  • Task edit form: This form allows workflow users to interact with tasks in the Tasks list on a SharePoint site. From the SharePoint Designer Custom Task Wizard, custom form fields are created and added to a custom task form. When you finish designing the workflow, SharePoint Designer automatically generates the ASP.NET forms for your custom tasks (QA Test Result.aspx). When the workflow executes and the tasks are created, the user navigates to the Tasks list and modifies the list item as appropriate. The workflow responds to those changes as defined by the rules specified in the workflow and can utilize the data in the item as a source of information.

Once SharePoint Designer automatically generates the ASP.NET forms, SharePoint Designer can also be utilized to customize these forms. Workflow forms are ASP.NET pages with a Data Form Web Part and a master page applied to it, and they can be customized like any other aspx file. The web forms are stored in the Workflows document library on the SharePoint site along with the workflow source files.

SharePoint Designer does not create association forms because the workflow is associated with the SharePoint list as part of the authoring process. Modification forms cannot be created because workflows designed in SharePoint Designer cannot be modified during execution.

Custom workflows can also be created using Visual Studio 2005. This capability is not native to the Visual Studio 2005 development environment and requires an add-in called Visual Studio Designer for Windows Workflow Foundation (DWF). DWF is available as part of the download titled Visual Studio 2005 Extensions for .NET Framework 3.0 (Windows Workflow Foundation). The Extensions download also contains the WF runtime engine and the WF SDK.

Once installed, DWF provides graphical designer capability, workflow project templates, and toolbox items for building custom workflows. The process for creating a custom workflow is much more involved than what you had to do in SharePoint Designer and requires experience with the development environment and some knowledge of WF. This process generally includes the following:

  1. Author the workflow and write any custom .NET code required to complete the workflow.

  2. Create any forms that are required for the workflow.

  3. Create the two XML files that represent the feature definition and workflow definitions. These forms contain information about the workflow assembly, the binding to any forms utilized, and deployment characteristics.

  4. Compile the workflow assembly and create a strong-named assembly.

  5. Create a package to deploy the completed workflow to the server using the SharePoint Features functionality.

  6. Test and debug the workflow using the debugging capability of Visual Studio 2005 and DWF.

  7. Redeploy the completed workflow after any errors are fixed.

Next, you will use DWF to create a custom workflow. The focus of the exercise is to build a real-world workflow and to compare the process to that used when building custom workflows using SharePoint Designer. You will look at the WF details as you build the workflow.

In addition to installing the Visual Studio Extensions for .NET Framework 3.0, you should also install the Windows SharePoint Services and Office SharePoint Server Software Development Kits. The SharePoint Server SDK will install SharePoint workflow templates as well as some code snippets for creating Features to deploy custom workflows to your SharePoint sites. The SDKs are not required but will definitely improve the custom workflow authoring experience.

Content Approval Workflow Scenario

Following are the steps involved in this example: A content author submits a document for approval to a SharePoint document library. The author launches a workflow that creates a task for the content approver and posts the task to the Tasks list within the SharePoint site. The approver updates the specific task item in the Tasks list and approves or rejects the document after the content has been reviewed.

Creating the Content Approval Workflow: Exercise and Tutorial

This exercise creates a custom workflow using DWF that models the scenario just described. The workflow utilizes three custom InfoPath 2007 forms:

  • The association form will allow the administrator to configure the individual who approves the content.

  • The initiation form will allow comments to be entered by the author prior to starting the workflow.

  • The task edit form will provide the approver with the capability to approve or reject the content.

The emphasis is on using the graphical designer, writing custom .NET code, and introducing the WF object model. Experience using Visual Studio 2005 and C# is assumed.

The code and forms created in this exercise are available in the downloadable code for this book available at www.wrox.com. Because a detailed discussion of InfoPath has not been included in this book, the reader is not expected to create these forms as part of the exercise. Readers can utilize the completed forms from the downloadable code to test the workflow. For those interested, detailed instructions for creating the InfoPath forms are included in the download. The following exercise focuses on creating the actual workflow:

  1. Open Visual Studio 2005 and create a new SharePoint Sequential Workflow project from the SharePoint Server project types. Call the workflow project ApprovalFromScratch and save it to a folder location called c:\DevProjects.

    This project will add the proper workflow activities to the toolbox and configure the necessary workflow assembly and namespace references. The System.Workflow namespace and all the classes it contains represent the WF runtime. For creating custom workflows, a key set of classes reside in the System.Workflow.Activities and System.Workflow.Rules namespaces. The Microsoft.SharePoint.Workflow namespace is another key set of classes that provides functionality for managing SharePoint workflows, and collectively represents the Windows SharePoint Services workflow object model. Generally these classes are not a direct part of the authoring experience unless, for example, modifying an executing workflow is necessary.

    By default, the workflow contains an OnWorkflowActivated activity that can be seen in designer view. All SharePoint workflows must start with this type of activity. OnWorkflowActivated provides the initialization of the workflow when it is called for the first time by the Windows SharePoint Services host environment. As part of the initialization, workflow properties are set using the design-time values, and SharePoint passes information into the workflow that configures the workflow's properties. SharePoint's information includes such things as the site and list associated with the workflow and any data collected by an initialization form. Initialization form data is stored within the workflow for local use.

  2. Open the Workflow1.cs file in code view and make the following class-level declarations:

    public string supervisor = default(string);
    public string comments = default(string);
    public string taskStatus = default(string); 
    

    These fields represent workflow custom properties that are passed from one of the workflow's custom forms as an XML string. The workflow then extracts these values and stores them as local properties.

  3. 3Open the Workflow1.cs file in design mode and create an onWorkflowActivated event handler by right-clicking the onWorkflowActivated1 activity and selecting Generate Handlers. The following code needs to be added to the generated handler:

    workflowId = workflowProperties.WorkflowId; 
    

    This method is called when the workflow is activated. The incoming initiation data is read from the workflowProperties object variable. The workflowProperties object is initialized when an instance is created, and includes properties common to all workflows. Custom properties can also be passed in from a custom form, as you'll see in this exercise.

    Add the following code to retrieve the workflow's properties from the initiation form:

    XmlDocument doc = new XmlDocument(); 
    doc.LoadXml(workflowProperties.InitiationData); 
    

    Add the following code to extract each individual property:

    XmlNamespaceManager nsmgr = new XmlNamespaceManager(doc.NameTable);
    nsmgr.AddNamespace("my", "http://schemas.microsoft.com/office/infopath/2003/ myXSD/2007-01-03T18:31:17");
    supervisor = doc.SelectSingleNode("my:myFields/my:Supervisor", nsmgr).InnerText;
    comments = doc.SelectSingleNode("my:myFields/my:Comments", nsmgr).InnerText; 
    

    Now it's time to add activities that define the operation and flow of the workflow. These activities include creating a new task, assigning it to the specified user, waiting until the task has been completed, and then terminating the workflow. These activities will also use custom InfoPath forms that gather information from users and submit the data to the executing workflow.

  4. Information about the task properties needs to be stored in the workflow. Add the following declarations at the class level:

    public Guid taskID = default(System.Guid);
    public Microsoft.SharePoint.Workflow.SPWorkflowTaskProperties taskProperties = 
    new Microsoft.SharePoint.Workflow.SPWorkflowTaskProperties();
    public Microsoft.SharePoint.Workflow.SPWorkflowTaskProperties beforeProperties = 
    new Microsoft.SharePoint.Workflow.SPWorkflowTaskProperties();
    public Microsoft.SharePoint.Workflow.SPWorkflowTaskProperties afterProperties = 
    new Microsoft.SharePoint.Workflow.SPWorkflowTaskProperties(); 
    
  5. Open Workflow1.cs in design mode. From the Toolbox, drag a CreateTask activity onto the workflow and drop it immediately under the onWorkflowActivated1 activity. Within the Properties windows, set the CorrelationToken property to taskToken and the OwnerActivityName to Workflow1. Set the TaskId to taskId and TaskProperties to taskProperties.

    The correlation token, taskToken, establishes a relationship between the executing workflow and the corresponding task so that SharePoint Server can properly route data to and from the workflow. taskID is a GUID that identifies the task within the workflow instance, and taskProperties contains the properties to initialize the task. Now it's time to assign values to these properties.

  6. Right-click CreateTask1 in design mode and select Generate Handlers. Add the following code to populate the task's properties:

    taskID = Guid.NewGuid();
    taskProperties.AssignedTo = supervisor;
    taskProperties.Description = "Approve the document";
    taskProperties.Title = "Document Approval From Scratch";
    taskProperties.ExtendedProperties["Supervisor"] = supervisor;
    taskProperties.ExtendedProperties["Comments"] = comments; 
    

    The task is created and assigned to the supervisor. At this point, there may be a time lag befor the supervisor approves or rejects the content, so you must utilize a Wait activity.

  7. From the Toolbox, drag a While activity onto the workflow and drop it immediately under the createTask1 activity. From the Properties window, set Condition to Code Condition and the subproperty Condition to notFinished.

    The While activity loops until a certain condition evaluates to true. This workflow will use it to loop around the task change event until the supervisor explicitly completes the task. Setting the Condition property to Code Condition specifies that the While activity call a function to determine its complete state. The Condition subproperty specifies that the notFinished method will define completion. Next you will add an OnTaskChanged activity to the while1 activity to determine when the while1 activity is assessed. For this scenario, you want the while1 activity to loop every time the task is edited. Therefore, you need an activity that handles the task change event.

  8. Drag an OnTaskChanged activity from the toolbox and place it on top of the while1 activity. Set the CorrelationToken to taskToken and the OwnerActivityName to Workflow1. Set the TaskId to taskId, BeforeProperties to beforeProperties, and AfterProperties to afterProperties.

    The workflow is paused while the OnTaskChanged activity waits for the task change event, and then it is reactivated when the task is changed. When the task is changed, you need to determine whether the supervisor approved or rejected the document. If so, then the task is complete. You need to add a variable that holds a Boolean value that determines whether the task is completed.

  9. Declare the following class-level variable that will hold the Boolean value determining the completion of the workflow:

    private bool isFinished = false; 
    
  10. Create a handler for the onTaskChanged1 activity. Inside this method, add the following code:

    if (this.afterProperties.ExtendedProperties["TaskStatus"].ToString() == "Approved" | 
    this.afterProperties.ExtendedProperties["TaskStatus"].ToString() == "Rejected")
    { 
          isFinished = true;
    } 
    

    This method is invoked when the workflow receives the task change event. Inside this method you need to retrieve the contents of the TaskStatus variable, which holds the value of the supervisor's assessment (Approved or Rejected). The afterProperties variable represents the task properties after the task change event has occurred. You will set a variable isFinished that specifies whether the task is complete based on the value of TaskStatus.

  11. The notFinished method should have been automatically created in step 7, but if not, go ahead and add it to the workflow1.cs file:

    private void notFinished(object sender, ConditionalEventArgs e)
    {
          e.Result = !isFinished;
    } 
    

    This method is invoked by the while1 activity each time the task is changed to determine whether its condition is met. As long as the Result property of the ConditionalEventArgs object evaluates to true, the while1 activity continues to wait.

    Now, each time the user edits the task, the onTaskChanged1 activity handles the task changed event. It invokes the onTaskChanged method, which examines the task properties and sets the isFinished variable to indicate whether the supervisor completed the task. The while1 activity then invokes the notFinished method, which sets the result of the event to the opposite of the isFinished variable. If isFinished is equal to false, then the event result is set to true, and the while1 activity keeps waiting for task changes; if isFinished is equal to true, then the event result is set to false, and the while1 activity completes and the workflow continues to the next activity. The last step in the workflow is to complete the task.

  12. From the Toolbox, drag a CompleteTask activity onto the workflow and drop it immediately under the while1 activity. Set the CorrelationToken to taskToken and OwnerActivityName to Workflow1. Set TaskId to taskId and TaskOutcome to TaskStatus.

    The CorrelationToken and TaskId properties are set to the variables used in the createTask1 activity. This maintains the binding between this activity and the task created by the createTask1 activity.

    The workflow designer view of the completed workflow is shown in Figure 8-13.

    Figure 8-13

    Figure 8-13
  13. Build the ApprovalFromScratch project and fix any errors.

This completes the DWF portion of the workflow. The corresponding InfoPath forms that are utilized as part of the workflow would be created next. This workflow would need three forms: association, initiation, and task edit. The individual steps for creating the InfoPath forms and the workflow are available in the downloadable code at www.wrox.com. Once the workflow and forms are complete, the workflow needs to be deployed, tested, and debugged.

The actual deployment steps are not discussed in detail but they are covered in the downloadable material. The primary purpose of this exercise was to illustrate the capability of the Visual Studio Designer for Windows Workflow Foundation, give you a feel for the custom workflow creation process, and compare and contrast the DWF process with that used with SharePoint Designer. The table toward the end of the chapter summarizes the differences between these two authoring tools and is included as a detailed reference.

Custom Workflow Debugging

Custom workflows built using DWF can take advantage of most of the debugging capabilities of Visual Studio 2005. Recall that when you built the custom workflow using SharePoint Designer, you did not have debugging capability. Because the WF engine is hosted by another process, you must attach to that process to accomplish debugging. For SharePoint workflows, the host process will be the IIS worker process called w3wp.exe. Once attached to the worker process, the normal debugging process of setting breakpoints, stepping into and over code operations, and viewing call stack windows can be utilized. Unfortunately, the complete feature set of Visual Studio 2005 is not available because debugging of just-in-time (JIT) exceptions is not supported. A complete description of the capability and a step-by-step process for debugging is provided in the WF SDK that is installed with DWF

Creating the Content Approval Workflow: Review

Building the custom workflow using DWF illustrated the capability of the graphical designer, the general process for utilizing activities, and examples of the custom .NET code necessary to author a real-life workflow. As part of the authoring process, we also covered some of the basics of WF and the WF object model. This exercise demonstrated a lot of the key differences between authoring a workflow with SharePoint Designer and DWF. These differences are summarized in the following table:

Visual Studio 2005

SharePoint Designer

Authoring

Full development environment with a graphical designer that produces a template which can be associated with multiple sites, lists, and content types

Wizard-driven interface that utilizes conditions and actions to produce a template that contains a set of declarative rules and is bound to a specific list

Custom .NET code

Yes

No

Types

Sequential, State Machine

Sequential only

Completed Workflow

Workflow markup file and code-behind files are compiled into workflow assembly.

Workflow markup, workflow rules, and supporting files are stored uncompiled in a hidden document library on the site and compiled on demand.

Debugging

Yes. Visual Studio 2005 debugging except for JIT exceptions.

No step-by-step debugging available

Deployment

Packaged as a SharePoint feature and deployed to the server by an administrator

Deployed automatically when workflow is completed

Association

Template must be associated with each and every list before it will be available

Association occurs at design time only

Workflow Forms

Can use any forms technology, such as InfoPath 2007 or ASP.NET 2.0 forms

Automatically generates ASP.NET 2.0 forms, which can then be customized

Create Custom Activities and Conditions

Yes

No. Must use a predefined set of activities and conditions.

Workflow Modification

Executing workflows can be modified.

No modification is possible.

In addition to creating custom workflows, DWF can also be used to create custom activities and custom conditions. A condition is a .NET assembly containing a static method that evaluates certain aspects of executing code and returns a Boolean value. Once created, custom activities and conditions are then deployed to the server and utilized by SharePoint Designer in the custom workflow authoring process. Custom activity creation was beyond the scope of the chapter, but an example is included as part of the downloadable code available at www.wrox.com.

WF in combination with Windows SharePoint Services provides a platform for the information worker to create and utilize workflows in order to improve the effectiveness of document or content-centric business processes. This chapter has provided an introduction to WF, the workflow capability and implementation characteristics of Windows SharePoint Services and SharePoint Server, and the hands-on exercises for creating custom workflows using SharePoint Designer and DWF.

WF provides a runtime engine and a set of services for executing workflows that are hosted by Windows SharePoint Services. Windows SharePoint Services provides the architecture for hosting workflow applications but does not include any workflows itself. SharePoint Server extends the SharePoint workflow capability by installing templates that provide ready-to-use workflows, and SharePoint Server provides workflow integration with the clients of the 2007 Office system.

SharePoint Designer and DWF are two tools for authoring custom workflows. Each of these tools has its own strengths, and they are targeted at different audiences. SharePoint Designer is a wizard-driven environment for workflow authoring that doesn't require .NET developer skills, while DWF is a more complete, versatile development envir ment but requires a .NET developer. DWF can also be used to create custom activities and conditions that can subsequently be used in SharePoint Designer. A detailed comparison of each of these tools was also provided.

The workflow author should have the knowledge and skills necessary to build custom workflows using SharePoint Designer with little difficulty based on what was presented in this chapter. Authoring custom workflows with DWF may require additional skill and experience depending on the reader's .NET development background and understanding of the WF and Windows SharePoint Services object models. However, regardless of the reader's development skill, one should have a good understanding of how workflow is created and utilized within the SharePoint environment.

Collaboration effectiveness and efficiency can be improved by automating business processes using SharePoint workflow, so ultimately workflow can be another highly useful tool in SharePoint's collaboration arsenal.

Show:
© 2015 Microsoft