Terminate SharePoint Site Workflows with Nintex Workflow Part 1| SharePoint How-To

November 19, 2016 nellisconsulting 1 Comment

We’ve all been there. You schedule a Nintex site workflow to run on a schedule. Everything is working fine and leave for the day only to come back and something went terribly wrong with the workflow and now you have 10s if not 100s of errored workflows with the status of “Error Occurred” that built up overnight. You troubleshoot and fix the problem, but you still have the problem of canceling the errored workflows. You now have to go through the not-so-fun process of canceling all these workflows by hand.

I thought there could be a way to write a Nintex site workflow to terminate all of the errored workflows looping through all the workflow instances and invoking a web service to terminate the workflow, but alas, such a web service doesn’t exist. In the pursuit, I did come across several solutions using PowerShell and the SharePoint Object Model, but nothing through Nintex. So, after spending more time than I typically would for such a task, I gave up on the possibility and chalked it up to a limitation in both SharePoint and Nintex.

That was until I came across Scott Brickey’s article Mission Impossible : Remotely terminating a SharePoint Workflow . This article opened my eyes because although Scott offers up another PowerShell solution, he does it in a different manner. Instead of using the SharePoint Object Model like many of the other solutions, he leverages web requests, the underlying markup of the pages, and form post actions to terminate the workflow. Since Nintex does offer the web request capability, I figured I’d give it one more try.

And guess what… it worked this time.

Terminate Workflow Action – Under the Covers

Before going into the Nintex solution, we need to understand how the “Terminate Workflow” action works under the covers.

When you go to the “Site Workflows” link from the “Site Actions” screen, you are taken to the page <Site URL>/_ layouts/15/workflow.aspx. Clicking on one of the workflow links (that have the status of “Error Occurred”) takes you to this URL: <Your Site URL>/_layouts/15/WrkStat.aspx?WorkflowInstanceID={<some GUID>}.

This is the Workflow Instance Page where the link “End this workflow” shows. If we were to terminate this workflow manually, we would click this link. Since we want to execute the same action through automation, we need to look at this link a bit further. If we look at the HTML markup, we see the following code:

You can see that when clicking this link the JavaScript function “__doPostBack(‘ctl00$PlaceHolderMain_HtmlAnchorEnd’,”)” gets executed. At times, you have to dig deep in the core SharePoint libraries to see how some of these internal functions are defined, but luckily in our case, it’s all on this page.

Further up the markup, you can find the definition for our function:

Here, you can see that when the __doPostBack function is executed, it submits the form with ID “aspnetForm”. The 2 parameters passed into this function (eventTarget and eventArgument) are then passed in as form values with similar names. From the snippet above, you can see that eventTarget has a value of ‘ctl00$PlaceHolderMain_HtmlAnchorEnd’ and eventArgument is blank. It is important to realize that these values do not change from workflow instance to workflow instance.

This isn’t where the magic is, though. Luckily for us again, the actual form that gets submitted (aspnetForm) is contained within the same page markup:

There are a number of hidden input fields that this form can accept, but for our purposes, the important ones are: __EVENTTARGET, __EVENTARGUMENT, and __REQUESTDIGEST. The first 2 we already know are passed in through the __doPostBack call. So we need to grab the __REQUESTDIGEST value from the form itself. Unlike the other 2 values, this value is unique to each workflow instance page and will need to be grabbed dynamically.

The last thing to note in the markup is the action for the form itself. You can see that when this form submits, it performs a post action to the URL: ./WrkStat.aspx?WorkflowInstanceID=<encoded Workflow InstanceID>.

From all of this, we know that with the following information, we can successfully terminate this workflow:

Form Action Parameter: Workflow Instance ID
Form Field: __EVENTTARGET
Form Field: __EVENTARGUMENT
Form Field: __REQUESTDIGEST

In our next post, Terminate SharePoint Site Workflows with Nintex Part 2, we will show how to extract all of these values from the markup and programmatically terminate all errored workflows in a loop… all with just Nintex.

Nellis Consulting, LLC

Blog

Terminate SharePoint Site Workflows with Nintex Workflow Part 1| SharePoint How-To

Terminate Workflow Action – Under the Covers

One thought on “Terminate SharePoint Site Workflows with Nintex Workflow Part 1| SharePoint How-To”

Leave a Reply Cancel reply