Better to use a "for each" loop when Possible.

You might be thinking that you need to use a Loop because you're not certain of the number of executions.  You may have a better idea than you think of the number of executions something will take . I will present an example of a Parent/Child Process that utilizes a State Machine to illustrate this in another article.

After some bad examples of Safe Looping Executions times, I determined there had to be a better way.  In a large facility, I wouldn't want to disable Safe Looping because Nintex will be used by a large range of users with different skill levels.  In short, I want the safety provision provided by Safe Looping for the general user population. Infinite Loops can bring a machine to its knees.

I began playing with the "for each" loop for a particular application that I had of creating 30 list records. Since I knew I needed to loop 30 times, I added 30 Numbers to a dummy list.  (The list contained nothing but a number column.)

I, then, used a "Query List" to extract that number items from the dummy list based on the number of iterations I needed. (e.g., if I only needed 20, I would set a condition for the number being less than 21.)  The creation of that same 30 item for a custom list took under a minute. (With 5 minutes a loop in the "Loop" control, the first list took an hour and a half to create 30 items.)

A colleague of mine, Jody Brooks, enhanced this idea by using collections created from the "Regular expression" control seeded by a string.

Jody noticed that in the Nintex "Regular expression" control a string could be split into multiple collection variables.  Take the following string to get the idea "1,2,3,4,5,6,7,8,9,10".  Splitting this using the "," would yield ten collection variables--each containing a number.

A heavenly marriage since the Nintex "for each" loop is designed for collection variables. With the above collection variables, I can iterate through a loop ten times. Also not you can set a Boolean variable to exit the loop early if needed.

Then Jody designed a UDA, User Defined Action, that created a collection of a thousand from with the numbers to 1000 in a single-line text variable punctuated with a comma between each.  This was kind of a pipe wrench approach. I didn't need that many loops and wanted some input as to the length of the collection.

I wanted to create five variable collections for looping: 100, 200, 300, 400, and 500.

The following is my approach for the creation of a UDA called "How Many For Each":

Essentially, a user of UDA enters the FinalCount Parameter. It is not required, so if a value of 200, 300, 400, or 500 is not found the other branch is executed and an array of 100 is returned.

The workflows is essentially a setting a variable, a switch statement with a build string, and a regular expression evaluation.

The build string is essentially a concatenation of the StringtoSplitVariable, which is set in the first step to:

1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,

Essentially, the build strings are concatenations of the variable to itself.

Here is the one in the 500 branch, I had to adjust slightly to make it come out to 500 with concatenating 1,1,1,1.  The initial string is only 198 characters long--if I made it 200--this loop ended up being 501--gremlins anyone!

Let me know if you find a use for this UDA. I'm attaching the code.