FIX: SharePoint 2013 Workflow recursion prevention – Part 1
ISSUE:
Consider a scenario where you have a SharePoint 2013 workflow that creates an item on another list. On this other list you have another SharePoint 2013 workflow that’s set to auto-start on item creation. When the first workflow is triggered, it adds the item to the other list and completes successfully. But you’ll notice that the workflow associated with the other list does not get triggered at all. If you look into the ULS, you’ll see the following message.
08/19/2014 07:20:18.95 w3wp.exe (0x0948) 0x05A8 SharePoint Server Workflow Services al2s8 Medium Workflow recursion prevention attaching property Microsoft.SharePoint.ActivationProperties.IsEventFromWorkflow to event ItemAdded with value c1df2261-1ce4-60f4-b691-b58e44d387ca c1df2261-1ce4-60f4-b691-b58e44d387ca
This is cause because of an intentional change that was introduced in SharePoint 2013 product somewhere between April/June 2013 CU/updates. The workflow recursion prevention measure was put in place to mitigate the following scenario:
1) We have two workflows and both activate on item updates in the same list.
2) The workflow also updates list item in the list causing an infinite loop of workflow activations.
Fixing that unfortunately resulted in the above scenario not work which is a genuine and quite commonly used approach.
Good news is that this problem has been addressed with the release of SharePoint Server 2013 May Cumulative Update 2014.
A note about this fix: This fix is a bit different from the usual fixes we might be aware of. Unlike the regular fixes, which when applied we expect the problem to be resolved by itself, this fix requires us to update our workflows (be it Visual Studio or SharePoint Designer workflows for 2013 platform). The implementation of this fix is that there are new REST APIs exposed that we can call to trigger the other workflow using HttpSend action/activity. Since fixing the original mitigation plan isn’t appropriate as that may have a potential to cause workflows to loop recursively thus resulting in exceptions, farm instability etc., exposing new REST APIs were the way to go forward to enable this scenario to work as it did in SharePoint 2010.
And yes, the scenario mentioned above is only applicable for workflows built for 2013 platform. SharePoint Workflows targeting 2010 platform would still work on SharePoint 2013 farm when implemented the way it’s explained at the start of this post.
To be clear, these changes we need to do both in designer and visual studio workflows are purely declarative and there’s no code involved. The HttpSend activity has the ability to trip everyone off in our understanding of what a code action/action is or is not. HttpSend action/activity is absolutely declarative as are the other actions/activities available when we develop workflows for SharePoint 2013 platform.
SOLUTION:
Since I wanted to walk-through the process of designing both SharePoint Designer and Visual Studio workflows (the content is quite lengthy) I’ve split this post into 3 parts, this post being part 1.
SharePoint 2013 Workflow recursion prevention – Part 2: This will walk-through the process of how to leverage the new APIs exposed using HttpSend action from within a SharePoint Designer workflow.
SharePoint 2013 Workflow recursion prevention – Part 3: This will walk-through the process of how to leverage the new APIs exposed using HttpSend action from within a Visual Studio workflow.
The new APIs:
A new method called StartWorkflowOnListItemBySubscriptionId is exposed off of the type /_api/SP.WorkflowServices.WorkflowInstanceService.Current, which is also new. StartWorkflowOnListItemBySubscriptionId accepts SubscriptionId and ItemId as parameters. SubscriptionId can be retrieved by calling EnumerateSubscriptionsByList from SP.WorkflowServices.WorkflowSubscriptionService.Current. Read through the next parts to know more on how to leverage these new REST APIs to sort of work around the issue described above.