Before delving into how workflows can be
used in SharePoint, you should get familiar with WF and the key
concepts and structures involved.
What is a workflow? Perhaps the easiest way to
answer this question is to illustrate how a workflow differs from the
traditional applications on which we developers spend most of our time.
Workflows are declarative—that
is, they focus on what should be done rather than how to do it. This
has a significant implication: Determining what should be done within
an organization is a role performed by business users as opposed to
developers, and exactly what should be done often changes as business
priorities change. As developers, we’re very aware of this problem
since it often leads to a constant shifting of deliverables when it
comes to developing line-of-business applications. By adopting a
workflow-based approach, organizations can change business processes
simply by amending the workflows that define them.
Secondly, workflows are long running and stateful.
You may be thinking that most business applications are long running
and stateful, but there is an important difference with
workflows: The management of state and the processing of interactions
with running workflows is handled automatically by the runtime engine.
Although building business applications that maintain state is common
practice, such an implementation will usually involve a lot of custom
code. The same is also true for managing interactions with long-running
processes. There is a fundamental difference between using workflows
and traditional application development, and it all comes down to
perspective. When building traditional applications, we focus on
handling events and managing data; with workflows, the focus is on the
actual process logic with event handling and data management handled
automatically.
1. Types of Workflow
You can host two types of workflow using SharePoint:
sequential workflows and state machine workflows. A sequential workflow
is probably the most common type of workflow. State machine workflows
are not widely used within organizations.
Sequential Workflow
This type of workflow commonly manifests itself as a
business process and is the muse of many a Visio artist the world over.
Sequential workflows generally have a single starting point and follow
a series of sequential steps before reaching a discrete stopping point.
Consider the expenses approval workflow, for
example. An employee completes an expenses claim document. Completing
the document starts an approvals workflow that sees the document being
sent to a manager for approval. Once the manager has approved the
document, it is automatically passed to the accounts department for
payment. When the claim has finally been paid, the workflow is
concluded. This business process follows a series of steps toward a
final conclusion and is therefore typical of a sequential workflow.
State Machine Workflow
A common perception, possibly arising from the
assumptions of the various process improvement methodologies, assumes
that everything can be reduced to a series of well-defined sequential
processes. However, the core assumption of the sequential workflow is
that a process will progress in a predictable manner toward a
well-defined conclusion. In reality, however, this is not always the
case.
Consider, for example, the processing of a customer
order. A customer places an order for a particular item. The item is
not currently in stock and is ordered from a supplier. At the time of
ordering, the supplier provides an estimated delivery date, and from
this date an expected delivery date for the customer is provided. The
supplier ships the goods as expected, which are ultimately forwarded to
the final customer. On the surface, this may seem like a perfect
candidate for a sequential workflow, but what happens if the customer
decides to cancel the order? Or if the supplier can’t deliver the
goods? Or if the price of the goods changes between the time the
customer places the order and the order being fulfilled? Of course, we
could create complex sequential workflows to handle these exceptions,
but the point is this: Many exceptions can occur; trying to capture all
of them and define processes for handling all of them in a model
intended to represent a core business process can result in a process
that is fraught with minute detail. We’ve moved from defining what
should be done to defining how it should be done.
The
state machine workflow is a far more powerful tool when it comes to
mapping business processes within a software application. It allows us
to focus on the key steps while still allowing flexibility in handling
unexpected events. In the processing of a customer order example, using
a state machine approach, we could use four states:
Order Placed The customer has placed an order.
Order Fulfilled The items ordered are in stock and have been allocated to the customer order.
Order Received The order has been dispatched and the customer has confirmed receipt.
Order Cancelled The customer has cancelled the order.
Of course, several other business processes are
involved in the transitions between these four states, but the
important difference is that the actual logic of those business
processes does not necessarily need to be well defined. For example,
when the customer places an order, if the ordered item is out of stock,
most likely a business process would be in place to order it from a
supplier. However, the details of that process don’t matter to our
workflow, because we’re simply waiting for the state of the order to be
updated to Order Fulfilled after the ordered item becomes available.
As you can see, not all processes are predictable,
and sometimes modeling every eventuality simply muddies the waters and
creates a rigidity that defeats the objective of workflow. State
machine workflows allow you to focus on the goal of declaratively
defining business processes while still maintaining operational
fidelity.
2. Making Workflows Work
Let’s move on to consider how workflows are defined
and the nuts and bolts of performing useful functions. As you’ll see in
our demonstration scenario, SharePoint allows you to create workflows
in a number of ways. The end result is the same: an eXtensible
Application Markup Language (XAML) file containing an XML
representation of the steps to be performed and the rules governing
their execution. Although the file format used by WF is XAML, workflow
files use the extension .xoml,
allowing design time tools to differentiate between other uses of XAML
syntax such as Windows Presentation Framework artifacts. Workflow XAML
defines two key elements: workflow rules and workflow activities.
Workflow Rules
Let’s consider an example of a simple workflow that
might make use of workflow rules: An employee completes a purchase
requisition form, starting a sequential workflow. The workflow rules
determine that if the amount specified is less than $5000, the
requisition can be approved by any manager within the organization.
However, if the amount is greater than $5000, the requisition must be
approved by the purchasing manager.
Since the amount is a significant factor in
determining what should be done, it’s important that it can be changed
as part of the workflow definition. To make this possible, workflows
can contain rules and define variables for use by these rules.
Workflow Activities
When
it comes down to performing actual work, workflows use a series of
activities. Each activity effectively defines a method call, and within
the method is code that performs a particular function. So, for
example, if a requisition is sent to the purchasing manager for
approval, a workflow activity creates an e-mail message containing the
details of the requisition and then sends it to the manager for
approval. When the manager clicks the approval button in the e-mail,
the workflow activity completes processing and returns the results to
the workflow runtime. The results of workflow activities can be
assigned to variables and can therefore be used by workflow rules.
Out of the box, SharePoint 2010 includes many
workflow activities. Confusingly, within SharePoint, workflow
activities are sometimes known as actions, which include the following:
CreateItemActivity Used to create an item in a SharePoint list.
CreateTask Used to create a task with specified properties.
EmailActivity Used to send an e-mail to specified users.
SetStateActivity Used in state machine workflows to transition between states.
3. Custom Workflow Activities
Although more than 80 workflow activities are
available in SharePoint 2010, when it comes to building custom
applications, you will invariably have to create new activities that
are specific to your problem domain.
Custom workflow activities can be used in exactly
the same way built-in workflow activities are used; although it’s fair
to say that a bit more effort is involved in creating a custom workflow
activity than in writing a standard function. Workflow activities have
to satisfy the needs of two distinct audiences. First, workflow
activities need to do something useful at runtime. As developers, we’re
completely comfortable with writing the code to make our custom
activity do something useful. In addition to performing some function,
a workflow activity must also provide a useful design-time interface.
Business users must be able to configure our custom activity easily
within a workflow design tool if its runtime functionality is to be
used.
Runtime Behavior
From a runtime perspective, creating a custom activity is simply a case of creating a new class that is derived from System.Workflow.ComponentModel.Activity. Custom code can then be executed simply by overriding the virtual Execute method from the Activity base class.
Design-time Behavior
As well as the runtime behavior, you need to
consider the design-time experience. The WF framework allows you to
define the design time experience in three distinct areas, which are
discussed in the sections that follow.
Adding Validation
By adding validation to an activity, you can catch
configuration errors at design time. To implement this functionality,
you create a new class that derives from System.Workflow.ComponentModel.Compiler.Validator. As before, by overriding the virtual Validate method from the Validator base class, you can add your custom validation code.
Customizing Toolbox Behavior
When
you create workflows using Visual Studio, you can add activities to the
design surface by dragging them from the toolbox, as you’re accustomed
to doing with other design-time elements. WF lets you customize the
behavior of your activity when it’s dragged onto the design surface by
implementing a custom ActivityToolboxItem class and attaching it to your activity.
Creating a Custom Designer
As well as validating the configuration of our
activity using a validator and automatically setting up default values
using a custom toolbox item class, you can also extend the visual
representation of your activity by implementing a custom designer. In
much the same way as other WF objects, a custom designer can be
implemented by deriving a new class from System.Workflow.ComponentModel.Design.ActivityDesigner.
By implementing a custom designer, you can not only
alter the visual appearance of an activity at design time, but you can
also implement logic that determines how your activity behaves on the
design surface. For example, you can determine whether child activities
can be added to your activity or how many connection points your
activity exposes.
4. External Activities via Pluggable Workflow Services
New in 2010—A new
addition to SharePoint 2010 is the ability to use external activities.
Connecting to external systems has always been available as part of the
WF framework. However, creating a practical implementation required a
few additions to the workflow runtime. In MOSS 2007, extending the
workflow runtime was not possible, and therefore implementing the
extensions required to support external activities was not possible.
Now with SharePoint 2010, communicating with external systems is simply
a matter of creating a new class that inherits from the SPWorkflowExternalDataExchangeService base class.
The addition of external activities to the
SharePoint workflow runtime greatly expands the scope of SharePoint as
a workflow host. To pick up on the order fulfillment example used
earlier, if a product is out of stock and requires an order to be
placed with a supplier, it’s now possible for the order to be placed
directly from the workflow. Furthermore, any response from the supplier
can also be picked up within the workflow and acted upon automatically.
Bearing in mind the declarative nature of workflow and the aim of
easily allowing business users to model business requirements, this is
a very powerful enhancement to the platform.
Creating Workflows
When it comes to creating workflows for use with
SharePoint, you have a choice of a few methods, each targeted to a
particular audience and set of requirements.
Using SharePoint Designer
Creating workflows using SharePoint Designer
provides a complete no-code design experience. As you’ll see in the
upcoming demonstration scenario, workflows can be created by using a
series of simple wizard-based steps. In previous versions of
SharePoint, workflows created using SharePoint Designer were not
portable—that is, if you wanted to use the same workflow on more than
one list, you had to re-create it again for each list. With SharePoint
2010, that’s no longer the case; workflows can be easily used across
multiple lists and can also be exported for further enhancement using
Visual Studio 2010.
Using Visio 2010
New in 2010—The
ability to use Visio 2010 to create workflows is a new feature in
SharePoint 2010. Visio is undoubtedly the tool of choice when it comes
to documenting business processes, and now, by adopting the Microsoft
SharePoint Workflow template, workflows created in Visio can be
imported into SharePoint Designer for implementation. Furthermore, by
using Visio Services, imported workflows can make use of the Visio
model to provide a runtime status indicator.
As well as importing workflows from Visio, you can
also export workflows from SharePoint Designer in a format that can be
modified in Visio and then re-imported.
Using Visual Studio 2010
Using SharePoint Designer and Visio 2010 to create
workflows is undoubtedly the easiest way to go for the majority of
cases. But what happens when you need a bit more flexibility? You can
use Visual Studio 2010 to take advantage of the entire range of
functionality exposed by the WF framework.
Some features aren’t available outside of
Visual Studio, such as the ability to use pluggable workflow services
or the ability to use the CodeActivity
which allows developers to execute arbitrary code easily without having
to create a custom activity. Another important feature that is
available only to Visual Studio users is the ability to create state
machine workflows.
