Last modified at 3/21/2014 2:55 PM by Koen Zomers

The SharePoint 2013 architecture has changed quite a bit from earlier SharePoint versions. One of the biggest denominators would be that all custom code has been pushed out of SharePoint. So is the case with workflows which are now hosted in a separate generic workflow product named Workflow Manager.

 

The idea is that the workflow engine is now a generic Workflow Foundation 4.0 engine which is informed by SharePoint 2013 during setup and patching of SharePoint 2013 of the activities specific to SharePoint it should support. During this process it will also provide the Microsoft.SharePoint.WorkflowServices.Activities.dll located in the <15 hive>\TEMPLATE\WorkflowActivities folder which contains the logic behind the SharePoint specific activities. This file may be patched with each SharePoint update (CU, PU, SP), so this process of updating Workflow Manager also occurs when the SharePoint Configuration wizard is run after applying a SharePoint 2013 update.
 

When installing Workflow Manager it will create an IIS WebApplication at TCP ports 12290 (HTTPS) and 12291 (HTTP) at which it allows REST calls to trigger workflows.


You might wonder what would happen if this Workflow Manager would be down for some reason while SharePoint 2013 triggers a workflow. The answer is, it depends. If you manually start a SharePoint 2013 workflow, you will receive an error as it will poll to see if Workflow Manager is up and running:

Now if you have a SharePoint 2013 Workflow set to automatically start, i.e. when a listitem is being created, it doesn't thrown an error but the request by default will fail and will not resume once the Workflow Manager farm comes alive again. Unless, you install MSMQ on your server. If MSMQ is available, when the first workflow request comes in, SharePoint 2013 will automatically create and configure an MSMQ instance named "microsoft.workflow.client.publishednotifications":


If Workflow Manager happens to be down now, the message gets stored in the MSMQ queue and will automatically be picked up again to be sent to Workflow Manager once the workflow farm is available again. In order to make use of this great feature to enable reliable messaging, you must enable the Message Queing Services feature within Windows on each of your SharePoint 2013 servers:
 


You can also enable it via PowerShell instead by running:

Install-WindowsFeature -Name  MSMQ-Server -IncludeAllSubFeature

 

After enabling it reboot and use PowerShell to verify that queueing is enabled on the Workflow Service Proxy, which it should be by default:


 You're all set now. Once the first Workflow trigger comes in, SharePoint 2013 will automatically create the MSMQ. You can verify this by going to Computer Management (Win+R, compmgmt.msc)


The official product documentation regarding this feature can be found at: http://msdn.microsoft.com/en-us/library/office/dn467936(v=office.15).aspx