Workflows in SharePoint 2010

New features make it easier to create, customize, and re-use workflows

Serge Luca

January 31, 2011

10 Min Read
ITPro Today logo in a gray background | ITPro Today

Based natively on the Workflow Foundation engine, SharePoint 2007 was the first version of SharePoint that made use of workflows. Now SharePoint 2010 provides a set of welcome workflow improvements. With SharePoint 2010, Microsoft shipped the .NET Framework 3.5 SP1 (and, thus, Workflow Foundation 3.5). Even though a new version of Workflow Foundation 4.0—with its improved architecture and design—is provided with the .NET Framework 4, Microsoft chose to stick with a tested and reliable product. SharePoint 2010 workflow improvements include the following features:

  • Workflows that can be associated with websites (and not just lists)

  • New options in out-of-the-box workflows

  • The ability to create workflows by using Visio 2010

  • The ability with SharePoint Designer 2010 to create workflows that can then be used out-of-the-box

Additionally, you can now generate workflow forms in Visual Studio (VS) 2010 to create a better,  more flexible communication channel between the workflow and the outside world.

Previous versions of SharePoint didn’t allow a workflow to be associated with a specific list or, indirectly, with one or several lists through a content type. In SharePoint 2010, you can associate one or several workflows with a SharePoint website. This is handy if the workflow has to monitor actions that are occurring in multiple locations across the site. Let’s look at some more specific features of workflows in SharePoint 2010.

New Out-of-the-Box Features

SharePoint 2010 adds a new version of the Approval workflow and the Collect feedback workflow, which let you assign tasks by stages or even assign tasks to all members of a SharePoint group. Figure 1 shows two tasks assigned to users Amy Alberts and to Brian Cox in serial; two other approval tasks are assigned in parallel to Alan Brewer and to Alan Steiner; and, in the next step, tasks are assigned to all members of the “Litware Managers” group.

Visio 2010 includes a set of workflow shapes to easily generate workflows. A user can author a workflow with Visio 2010, then hand the workflow to a developer to customize it. This can be done in either direction: going from SharePoint Designer 2010 to Visio 2010 or from Visio 2010 to SharePoint Designer 2010. Figure 2 shows how an expense report approval process can quickly be designed in Visio 2010.

Visio 2010 goes beyond workflow design; it also generates real workflow code (XOML) that can be reused and customized in a tool such as SharePoint Designer 2010. In fact, Visio 2010 can export the design into a file that has a .vwi format (Visio Workflow Interchange). This format is actually a .zip file that contains files that are recognized by Workflow Foundation (.xoml and .rules files) in addition to a .vdx file for the purely Visio part (shape layouts) of the workflow.

SharePoint Designer 2010 Workflow

SharePoint Designer 2010 has become an essential tool for a wide range of users, such as business analysts, designers, and SharePoint developers. I strongly suggest that you familiarize yourself with its new and improved workflow features:

Importing from Visio. Importing a Visio-generated workflow is a straightforward process that allows room for customization by a designer or developer (see Figure 3). The workflow designer is also more intuitive than in the previous version of SharePoint Designer. The annotations that are provided in Visio 2010 (such as “Expense Report too expensive” and “Approve it” from Figure 2) are also available in SharePoint Designer 2010 (see Figure 4).

Reusing and customizing out-of-the-box workflows. Out-of-the-box workflows, such as Collect Feedback and Approval, can be reused to customize workflows. This is a functionality that you saw in Figure 2 in Visio 2010 under the label “Assign item for approval.” Given that most custom collaborative workflows use some kind of approval functionality, and that this functionality is sometimes very complicated to program (even for skilled Workflow Foundation .NET developers), this is a major improvement.

Office task. The Office task adds a touch of flexibility to the behavior of the out-of-the-box workflow tasks. It lets you assign specific behavior to individual tasks—or to the whole approval session. For instance, you can implement the following requirements:

  • If 50 percent of users approve, approve the item.

  • If the user is not available, assign the task to the user's manager.

  • As soon as an approval starts or completes, start a specific action (such as sending an email message).

  • As soon as when a task is assigned to a user or is complete, start a specific action.

Content types and site workflows. Probably the weakest feature of SharePoint Designer 2007 workflows was that they had to be associated with specific lists and couldn’t be reused. However, workflows that SharePoint Designer 2010 generates can be associated with content types—generally considered a good practice. These workflows can also be associated with a site.

Figure 5 shows the options you can choose from to create three kinds of workflow associations in SharePoint Designer 2010:

  • Associated with a specific list

  • Associated with a content type

  • Associated with a site

Security: Impersonation Step. Another security improvement is the new Impersonation step feature. In SharePoint Designer 2007, declarative workflows were based on the identity of the user who initiated the workflow.  This could be a problem if you wanted to access some unauthorized resources. Workflows that are generated in VS 2010, on the other hand, run in full trust mode by using the identity of the application pool user.

SharePoint Designer 2010 offers a kind of hybrid mode in which you can run different parts of the workflow as different users. By default the workflow runs with the identity of the user who started the workflow, but most importantly you can run part of the workflow by using the identity of the user who published the workflow (typically the designer). You do this through an Impersonation step action(see Figure 6).

InfoPath workflow forms. Workflows forms for SharePoint Designer 2010 workflows are now InfoPath forms by default. Previously, they were .aspx forms. Workflow forms can, therefore, be visualized in the Microsoft Office 2007 rich client or in the Office 2010 rich client. They can also be easily customized by using InfoPath 2010 Designer.

Workflow visualization. Thanks to the new Visio services that are built into SharePoint 2010, you can now visualize the state of your workflows. Figure 7 shows an approval process in which Brian Cox has completed his task, and the system is waiting for Amy Alberts to take action before assigning a task to Alan Steiner.

Sandbox activities. Workflows that are authored in SharePoint Designer 2010 run in full trust mode, but they can’t put the SharePoint farm into danger. Custom workflow components (“actions”) can be created by using VS .NET 2010 either in full trust mode or in the fully secure sandbox mode. If it becomes necessary, these sandbox actions can be deployed to an on-premises farm or to Office 365, the new Microsoft hosting environment formerly known as BPOS. Workflows that are generated in VS must run in farm mode; they can’t run in a sandbox environment.

 

 

 

Missing Features in SharePoint Designer 2010

Just as in SharePoint Designer 2007, SharePoint Designer 2010 still doesn’t let you author state machine workflows as you can in VS. Even if most workflows are sequential workflows, there are some situations in which you have to be able to move back to previous steps in the workflow. In that case, forget SharePoint Designer 2010 and move on to VS 2010! Also missing is that lack of a looping mechanism in SharePoint Designer workflows. For instance, you cannot loop through several list items without having to rely on .NET custom activities that are created in VS.

What's New in SharePoint Workflows Created in VS 2010

There's also good and bad news when it comes to creating SharePoint Designer workflows in VS 2010. First, the bad news:

No sandbox. Unlike declarative workflows that are authored in SharePoint Designer, workflows that are created in VS can’t run in a sandbox mode but only in the fully trusted farm mode. This is a serious limitation to take into account if you want to move your customizations to SharePoint Online in the future.

Still the old Designer. Workflow Foundation 3.5 is the workflow engine for VS 2010 because Workflow Foundation 4.0, which includes the new designer, isn’t supported., For this reason, you are stuck with having to use the old designer, which is quite slow when you try to display many activities.

Importing from SharePoint Designer: irreversible. It’s now possible to easily import workflow that’s generated in SharePoint Designer 2010 into VS 2010. However, the process is irreversible. This is contrary to working in the other direction from Visio 2010 to SharePoint Designer 2010.

But it’s not all bad news about creating SharePoint Designer workflows in VS 2010. As in previous program versions, VS 2010 provides two workflow project templates,Sequential Workflow and State Machine Workflow, but it also adds some templates. And improved features make some tasks easier:

Feature Designer. Creating workflows in VS 2010 is far easier than before thanks to these new features:

•     Feature Designer: manages SharePoint features

•     Package Designer: manages SharePoint solutions packages

•     Automatic debugging: pressing F5 attaches the debugger to the corresponding worker process

List or site workflows. You can create workflows that are linked to a list or to a site.

Workflow events. You can now handle events that are generated when a list workflow is started, postponed, or completed (see Figure 8). This is also true for declarative workflows.

Workflow association and initiation forms. Creating workflow association forms and initiation forms (see Figure 9) is now very easy thanks to two new templates that generate .aspx pages. This is possible thanks to code that provides an exchange mechanism between the forms and the workflow. The developer has only to add specific controls to the .aspx forms, then implement two required methods: GetAssociationData and GetInitiationData(). Unfortunately, no template is provided to generate workflow tasks forms and workflow modification forms.

Communication with the outside world. One of the biggest improvements in SharePoint 2010 workflows is the ability to create pluggable workflow services. These are an efficient way for workflows to communicate asynchronously with the outside world. For example, a workflow might have to invoke an external line of business (LOB) application such as SAP. The answer coming from the LOB might be returned in one second; but it also might take one hour, one day, or even longer.

So what was the communication problem in SharePoint 2007? In a typical SharePoint workflow scenario, you try to communicate with users by creating tasks and by listening to any task action that’s performed by the users. In this case, the tasks are created by using the CreateTask activity that calls the SharePoint API. You can make the workflow listen to the task changes by using the OnTaskChanged activity. As in all activities that have a name starting with “On,” these are event-based activities. When a workflow runs, an event-based activity becomes idle.

The importance of idle workflows is that they’re automatically suspended, removed from the host process (“dehydrated”), serialized in a media ( the SharePoint content database), and “rehydrated” when the event occurs. The benefit of using event-based activities is that workflows lie dormant in the SharePoint content database while they wait for an event. Therefore, we can run thousands of workflows in parallel and achieve great scalability.

In SharePoint 2007, however, we could use only a limited number of event-based activities provided by Microsoft. This made it quite shaky to asynchronously call a LOB because you had to create tasks and ask the LOB to communicate with the workflow by changing the tasks.

In SharePoint 2010, you no longer have to follow this complex pattern. Instead, you can listen to any custom event, and you can use the HandleExternalEvent activity that is provided together with Workflow Foundation 3.0 (see Figure 10). This process is well known by .NET developers.

However, to achieve this result, you must still create a pluggable service by creating a custom class that is derived from the new SPWorkflowExternalDataExchangeService class. This custom class must be declared in the Web.config file.

A Value-Added Upgrade

Even though the workflow aspect of SharePoint 2010 isn’t revolutionary, it makes the process of creating workflows much easier. SharePoint Designer 2010 and Visio 2010 bring you major added value in the process: Workflows you create in SharePoint Designer can be reused, you can customize and reuse out-of-the-box workflows, and you now have a better, scalable communication channel between SharePoint and the outside world.

 

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like