This question comes up fairly often, and it may seem like a no brainer but here it is any way..

You have a workflow and it is calling an external web service.. Now for whatever reason the call has failed.. A 99% of the time this has nothing to do with the workflow itself, it is just the service didn't respond for any number of reasons.

A trick that I have been doing for a while now is to place the web service call inside a loop along for a pause action. "But how does this help?" you ask.. Well by using the OOTB feature of capturing errors of course J Opening the "Call Web Service" action scroll to the bottom under advanced. Change the settings to "Yes" capture error, Create a "Yes/No" variable to store whether or not there was an error and then if you wish to be emailed or store the error within the WF History, create a multiline Text Variable to store the error message.

In the logic of the loop conditions stay in the loop until "Error y/n" = N..

Expanding on this, I have also extended this by placing a "Math" action inside the loop to build an index of sorts. So every time the loop runs it is a +1 to a value of 0 to start with and then it grows by 1 every time the loop cycles. The reason for this was to place a limit on how many times the loop should retry the call. In the loop conditions no only check to see if there was an error using the OR condition check value of index, for example if index = 10 then exit loop. From here you could setup a schedule to run another workflow built especially for this scenario that will run the web service call at a later time. The can be achieved by using the Nintex Workflow Web service ' /_vti_bin/NintexWorkflow/workflow.asmx' and using the scheduling method… ANYWAY>>>>

Let's take a look at some screen of what I'm talking about.

First of all grab your Web service call and place it inside a loop:

We then need to configure the web service (If not already) and then configure the error handling section down the bottom of the action config screen. First things first, you need to create 2 variable to store the error..

Once you have your Error Variables, setup the 'Error Handling'

Ok, now with that done we can put some basic logic into the loop

If the 'wsError' variable is 'No' exit the loop..

To build this out a little to suite your environment.. For example, if you have safe looping tuned off. But first what is safe looping?

Safe Looping is a loop that is configured to run for many iterations without a pause can cause the workflow to use excessive system resources. As a precaution, a hidden delay is automatically added at the end of each iteration if the child actions are not guaranteed to cause the workflow to stop and wait. This can cause a 2 - 7 minute pause between each run of the loop. This option is called 'Safe Looping'. Administrators can disable Safe Looping from the Global Settings in Central Administration. The hidden delay is added when the workflow is published, so if the Safe Looping option is changed it will only affect any newly published workflows.  However, any existing workflows will need to be republished to see the change in the behavior.

So in light of that, if safe looping is turned off, or you would like to put a larger pause in between retries. Simply place a 'Run If' action with a 'Pause For…' action. Something like this:

From here you could also place in some other logic to assist in troubleshooting / notification for example, placing a condition in there that emails the admin team / workflow initiator that there has been an error and it will retry in 10 mins. When this notification is sent you would want to set a flag to acknowledge that a email has been sent as so you don't keep sending one every time it errors. Something like:

All I have done here is added another 'Run If' action that is acting on a 'Yes/No' Variable call 'SentMsg' which by default is set to 'No'

Once the Msg has been sent we just need to set that flag to 'Yes' as so when the Web service fails again, the workflow skips sending another email..

So now we have a bit of logic built up around our web service call, which allow the Web service call to fail – Which could be for a number of different reason, from load issues of the other system to network / comms issues. If it does fail the workflow will catch that and email the admin and/or the initiator, wait 10minutes and then try again (without emailing again) Once the call is successful the loop will exit and the workflow will continue on it's merry way J

Until next time.. Enjoy..