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 15-1 shows the high-level architecture for the new workflow.

FIGURE 15-1

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.