I have designed a Nintex Workflow that loops through the items of a repeating section. I'm using Vadim's "Get Forms Repeating Section UDA" to extract form data from the repeating section.
Inside the loop, it does the following actions:
My repeating section has 40 items on an average. Looping on those 40 items takes about 4 hours to execute.
I know that we have safe looping enabled at the farm level, and that takes about 5 minutes per iteration. And, we cannot disable the safe looping option. My question is whether anyone has any ideas on how to improve the performance of the loop, or an alternative to looping. I had read somewhere that For Each gives better performance and is not bound by the safe looping limitation. Is that true?
I appreciate your thoughts and comments. Thank you!
Solved! Go to Solution.
Yes, using a For Each will greatly improve your process and should greatly reduce the amount of time this workflow runs. For Each is always my go to mechanism when iterating over a collection of information.
I wanted to share an update to my original question. I developed a solution using collection variables using For Each instead of Loop action. I used Vadim's post as a reference to develop my solution.
I forgot to mention that I to had make some changes differently in my solution for it to work. Here are all the steps that I followed to make it work.
For me, the key was to decode the XML before using it in Step #3 above.
Hope it help!
I have used For/Each loops to great success, but recently, I have two workflows in SP2016 that use this technique to loop through about 260 items. I had implemented a pause using a math operation to divide a minute down to 10 seconds and pass that variable to the Wait action. The work is not complex, but they are running 10s of hours to process ~250 items, where in 2007 they ran the expected 40 minutes.
Has something changed that would cause the Wait to default to the 5 minute initiator window?
My next test will be to remove the wait altogether - which was there originally to not overrun the workflow initiators as there is some cascading workflow activity after the batch update occurs on each item. This was problematic in SP 2007 and caused multiple timeout failures ("An error occurred").
Not sure if I understood completely, but I will say that the Pause action defaults to 5 minutes, even if you set it for say 1 minute. This can be changed internally within SharePoint but messing with the timer in such a way isn't really recommended as it can cause other issues.
What you might be able to do is introduce the Pause Action after X amount of items, so maintain a Counter and then Run If counter = say 25, then Pause for 5 minutes. In this way you can control the amount of Pauses that take place and ultimately lower the amount of time this process takes.
Thanks for the input.. I had suspected a 5 minute wait and have worked around that previously by using a variable as the wait interval (i.e. 1/10 = 6 seconds). What we are seeing is inconsistent, intervals in seconds, minutes, some in hours. Our admins are looking at cleaning the workflow history, logs and some other backend attributes that are likely the cause of the errant behavior. The wait time was to prevent overrunning the initiators as each item touched kicks off its own set of workflows (legacy SP 2007 workaround). I removed the wait time completely and the entire flow runs in less than a minute -- with no overrun/timeouts downstream. I expect my issue has to do with the admin/server side and clean up there.