1. Introducing Workflow Manager
The Workflow Manager is the new
workflow engine that runs on the newest workflow technology from
Microsoft, the Workflow Framework in .NET 4.5. The Workflow Manager
also leverages the Windows Azure Service Bus when running in the cloud
or Service Bus for Windows Server when running on-premises to provide
workflow state consistency, reliable event delivery, and brokered
messaging with the publisher/subscriber (Pub/Sub) messaging pattern.
Workflow Manager and Service Bus working in concert provide a workflow
service that can work at Internet scale, independent of SharePoint.
This independence enables workflow processing to happen in a more
predictable and transparent fashion because it is no longer coupled
with the SharePoint server, competing for resources. Figure 1 shows the high-level architecture for the new workflow.
The integration layer that connects SharePoint to
Workflow Manager is through the Workflow Service Application Proxy, and
all the new workflow capability is exposed in the object model via the
Workflow Services Manager. To make the actual connection from
SharePoint to Workflow Manager, a workflow client is required to be
installed on the SharePoint machine.
The workflow API has four major components:
- Deployment Service: This is used to publish workflows and create associations.
- Messaging Service: Events are piped
into the workflow through the Messaging Service. When SharePoint sends
an event into the workflow, the event is saved in the Windows Azure
Service Bus database before it is delivered to Workflow Manager. The
Workflow Manager takes care of keeping the state of the workflow and
the state of the message queue in sync. Messaging Services uses another
feature of the Service Bus, which is Pub/Sub. With Pub/Sub multiple
workflows can subscribe to one event. For instance, suppose you have 10
workflows waiting on a list item. SharePoint will send only one message
when an event fires on the list and Service Bus takes care of
delivering that message to the 10 workflows that subscribe to that list
item. In the classic SharePoint 2010 workflow model, SharePoint would
have run 10 event receivers, putting a greater load on the workflow
engine.
- Instance Service: This is used to
query an instance to see information about it and control workflow
instances; for example, you can terminate them.
- Interoperability Service: This is used to invoke or start instances of classic SharePoint 2010 workflows.
All workflow callbacks into SharePoint take place over the _API
endpoint using the REST/OData protocol. The communication between
SharePoint and the Workflow Manager is secured using the OAuth security
model, making the new workflow infrastructure a premier implementation
of the new cloud app model.
2. The Big New Features for SharePoint Designer
SharePoint Designer (SPD) has been the
mainstay for SharePoint workflow creation. In SharePoint 2013 SPD has
advanced its feature set for making workflow design easier, and in some
cases, just more enjoyable to work with (as you will experience). Also,
although you could stitch together workflows in SharePoint 2010 to do
some very powerful things, a number of features, actions, and
programming constructs were not available to give you the type of
control over the “flow” in workflow that you really wanted and needed.
SPD fills these gaps. Following is a list of some of the big new
features you’ll experience in SPD 2013; these were highly requested
features from Microsoft partners and customers alike:
- Visual Designer: For those who
prefer a visual design surface with which to build their workflow,
SharePoint Designer has a new Visual Designer. However, you must have
Microsoft Visio Professional 2013 installed on your computer to use it.
- Stages: You no longer need to use
just linear workflows that go from top to bottom as with SharePoint
2010. Human business processes are not strictly linear. Typically these
processes have a number of tasks to be performed as a unit of work
and processes generally include one or more units of work. When a unit
of work is completed, sometimes there is a pause for a period of time
before the next unit of work is triggered. Other times the business
process needs to return to a previously completed unit of work to have
its steps performed again, or it might proceed on to the next unit of
work in a linear fashion. In human processes, business rules and policy
guide the transitions between one unit of work being completed and what
the next unit of work to be started should be. SharePoint 2013
workflows can now better parallel these human process patterns by
representing a unit of work as a specific set of workflow actions
within a stage. In your workflow, once a stage, (that is, unit of
work), is complete, you can choose the next stage for your workflow to
transition to, or whether to pause, return to a stage previously
completed for further processing, or continue on to the next stage in a
linear flow. Therefore, stages give you the flexibility to logically
determine your transition from one stage in your workflow to the next.
- Call Web Services: You can now
extend your workflows to reach data beyond the boundaries of
SharePoint. You can reach out to different systems using HTTP/REST and
bring the external data you need into the context of your workflow
process.
- Copy/Paste: In SharePoint’s
Text-based Designer and the new Visual Designer, you can now copy/paste
individual lines or complete constructs.
- Looping: You can loop by using the
transition between stages to continue to go to a specific stage unless
a specific criterion is met. You can also use the two new loop
structures — one describes a determinate loop, the other an
indeterminate loop.
- Dictionary Variable: This new
variable data type is suited for storing complex data, such as a JSON
object returned from a REST call or an array of data.
- Portability: Any workflow type can now be packaged as a .wsp file for redeploying from site to site. You can export your SharePoint Designer workflow into a Visio .VSDX file and import it into another site as well.
- App Step: This contains actions
that run with app-level permissions in your workflow. This means that
these actions can run outside of the users’ permissions if your
workflow needs to perform some action on behalf of users where they do
not have that level of permission.
- Interoperability: This provides
support for interoperability with classic SharePoint 2010 workflows.
Sometimes you might need to use a 2010 action inside of a SharePoint
2013 workflow, but these two workflow engines are inherently
incompatible. Two actions are available in SharePoint Designer 2013 —
Start a List Workflow, and Start a Site Workflow. With them, you can
pass parameters into a SharePoint 2010 workflow, and the 2010 workflow
can execute its actions and return data to the 2013 workflow that you
can use for its processing.
Hopefully these new feature descriptions have
whetted your appetite for wanting to get your hands on the tools, so
let’s take a look at them.
