Nintex Workflow comes with a concept called Safe Looping, which is enabled by default.
Safe Looping was created to protect the SharePoint environment from a workflow which goes into a infinite loop and inadvertantly affects the SharePoint environment in a negative way (high CPU usage).
The way it does this, is during the process of publishing the workflow, if there are Change State actions, a hidden delay action is added (single timer service cycle – usually 5 minutes). Also, during each iteration of the Loop action, a hidden delay is added.
Where is Safe Looping enabled?
In Central Administration > Nintex Workflow Management > Global Settings
You will find an option called “Enforce safe looping”. Set it “yes” to enable it.
When making changes in Global Settings, these changes are not automatically applied to the farm. Usually, 15-20 mins and the change will propagate throughout the farm. Alternatively, perform an IISRESET and this happen now.
What are the risks?
With Safe Looping disabled, you risk having workflows go into infinite loops and potentially have high CPU load on a SharePoint server.
If you have a Loop action, your workflow could get stuck in this loop, going through the loop continuously as fast as the server will let it, using up as much CPU processing power as possible.
In either of these cases, high CPU load on a server would result in slow SharePoint performance and end users will find slow responses from pages, other workflows may be affected during run time and you may generally get timeouts because the server doesn’t respond to requests on time. With the server being so busy, you may even find it difficult to terminate this workflow because the server can’t respond.
With Safe Looping enabled, you risk having a workflow that looks to be quite simple, have hidden delays and potentially run a lot longer than you would normall expect.
When it comes down to it, having Safe Looping enabled is the preferred option. You can’t guarantee that one of your employees won’t design a workflow with a loop that will continue forever, due to some workflow logic mistake. From a corporate stand point, you would rather a workflow take longer to run, rather than risk bringing down your farm.
I recently got asked a question on how to find out the number of weekdays between two dates.
The quick (as in design-time) way, would be to have a loop that iterates through each day and figures out what it is (weekday or weekend).
The risk here, is if you have 2 days that are very far apart, each iteration through the loop would cause a hidden Safe Looping delay.
The alternate way, is it figure out a way to do this without Loops or Change States.
The down side to this way, is that it increases design time dramatically because you need to build the logic to actually do this and test it out. It will also increase the size of the workflow, so your best to put this type of logic into a User Defined Action.
In my test, my loop UDA was 34kb and my no-loop UDA was 128kb
I won’t be going into the User Defined Actions themselves as what they do is fairly straight forward. So I’ll leave that up to the reading. You can download the UDAs below.
If you have a loop that runs the logic inside it 100 times, with Safe Looping enabled you could potential have 5 mins multiplied by 100 iterations = 500 mins. This translates to a little over 8 hours.
Without safe looping, this could potentially run in very little time (unless you had delays or task actions).
If you have a time sensitive workflow, Safe Looping may not be an option. Remember, the hidden delay is put into the workflow at the time of publishing the workflow.
So if you don’t want a workflow to have Safe Looping in it, you can disable Safe Looping in Central Admin > Nintex Workflow Management > Global Settings. Perform an IISRESET.
Next, open the workflow in design mode, publish the workflow and it will now have no Safe Looping in it.
Turn Safe Looping on in Central Admin.
You now have a workflow without Safe Looping, and any other workflows you design will have Safe Looping in them.