I have a workflow that is using a Web Request action to retrieve the status of a document through the Citrix product Right Signature. I currently have a loop setup where the current status is being retrieved, and if it's not in the desired status it will delay before looping back and checking again.
Apparently, there's a limit on the amount of times a loop will run (250). I could determine the maximum amount of time the process could wait, and divide that by 250 to determine the length of time the delay should be set to. However, that possibly results in a longer time between the desired status being set, and Nintex actually checking the status and continuing on with the workflow.
I also tried to do a manual loop by doing a Branch by Stage action, where it would keep rerunning the same stage until it was the desired status. However, it appears the branch by stage also has a limited number of times it will run (I'm guessing either 50 per stage or 100 for the whole action).
Is there a way to get around these limits or a suggested method for a workflow to wait for an outside trigger/status before continuing on? Preferably, no one that's part of the workflow would need to do anything extra (such as completing a task that indicates the desired status is set).
A possible solution I'm finding is combining the loop and branch by stage actions. The default stage contains a loop checking the status. After the loop maxes out at 250, it exits the loop and is then directed to stage 2, which then directs it back to stage 1 where it starts the loop over again.
I tested this with a simple incrementing variable, and it ran the through the process over 250 times. So my assumption (assuming no other limits) is that this could run through 12,500 times (250 loop limit X 50 branch limit).
I would still love to know if there's a recommended way to do this repeated check.
@bsikes Without knowing the API capability it is hard to suggest the best option, could you split up the workflow and trigger a component workflow from Right Signature when the status changes. Otherwise as mentioned it could be a combination of loops and pause actions to get the desired result.
@leighburke In this case, it wouldn't make sense to split up the workflow. Depending on the status returned, we may want to kick back the workflow to an earlier stage to revise things.
You mentioned difficulties suggesting a best option without knowing the API's capabilities - Is there any context where a third party API could trigger something within an existing workflow instance, without that instance having to initiate the check itself (and thus need to be in a loop where limits are present)?
I've not played around much with the NWC API (Didn't seem powerful enough when it came with interacting with existing instances), but possibly there's a solution to this within the Task based API calls. Rather than having the workflow loop through a check/delay, maybe this would work:
Any obvious holes in that plan?