Some tasks need to be ran against multiple servers. I sometimes write custom scripts / batch files for this. Not a problem; however, suggest the following to augment Visual Cron:

Create some sort of looping task contstruct... perhaps a task that repeats the next n tasks, until a variable = x or something like that or until it reaches the task named ______.

This looping contstruct should have the ability to query odbc databases / active directory, etc. and place database style output into some runtime macros.

So say I queried AD for a list of servers in the 'Web Servers' OU, then it may return a list of server names.

The next task could then execute based on {QUERIEDCOLUMNNAME}

Hi Shohn,

I see several requests in your post:

1. Task with some sort of repeat feature, to repeat the next x tasks y times with the capability of using variables;
2. Task with capability to query databases (odbc / active directory / ect?)
3. Task with wil run several times based on an inputtext. This inputtext should have a delimiter so you get x items. Your task runs x times and every time you use a different items from the inputtext (based on the delimiter)

Am I correct?

My comments:
1. Could be to complex. What if I have two of these tasks behind each other. It is not clear anymore what the task order will be.
2. There is already a database sql task with odbc feature. What datasource do you need to access?
3. This could be a nice addition to the current tasks.

In this example you see a job wit a repetition task. The Repetition task uses task 1 to task 3 in his repetition sequens. In the GUI you should see that task 1 to task 3 belongs to the repetition task.
You might want to repeat the repetition task based on a fixed number (variable/output other task) or bases on amount of splitted items from an inputtext (point 3). These splittes items should be, I think, in some sort of variable from this repetition task.

+JOB-A
....sql task
....+Repetition task
.....| task 1
.....| task 2
.....| task 3
....copy task
....other task

The sql task gets data for example:

Henri
Erik
Shohn
Somebody

In the setup of the repetition task you use the output from the previous task as inputtext and it has a linefeed as delimiter.
task 1, task 2, task 3 wil run in this sequense 4 times and can use every name (Henri / Erik / Shohn and Somebody). Henri in the 1st run, Erik in the 2nd, etc
The repetition task should have an output variable to use the splitted inputtext.

Lot of text over here, but I like the repetition task... 🖐

Any other ideas?

---

I have some things to add in my story:

- If you use the repetition task with: repeat tasks x times, the output variable from the repetition task should give the repetition number.
Every time the repetition task runs it will add 1 to the variable starting at 1 till # is reached of course.

- If you right click on the repetition task you should have an option to add a task to the repetition task.

- The order of the containing tasks could be changed in the repetition task itself, don't think you should do this at job level.

- The variety of tasks should be the same as all the normal task. Don't think you shouls allow netsted repetition tasks though (for now 😉...

Regards,
Erik

---

Perfecto! yes, now let's get this implemented as quickly as possible, because I'm going to have to write external scripts otherwise :(

On item #2, I need to query either active directory or an internal database or maybe even a file.... and basically execute

a task against it in a repeating loop. It doesn't have to get wacky complex.


So let's say I have a list of domain controllers in a particular OU and need to run the ol' check active directory script against all domain controllers.

Now I know I could have that in an external script, but would prefer to have it in Visual Cron, because we have built an extensive error reporting system around visual cron and would like to avoid placing the error handling inside of the scripts.

This can be done by using Conditions today.

The problem is not adding a loop function. This has been done by others. The main problem is that the loop functions they have implemented are too simple and give instant limitations. Another problem is, while giving total flexibility and still keep simplicity in interface and understanding how to use it.

It is easy to come up with one scenario that is easy too implement but we are searching for generic solutions that fits different environments.

I am not saying no to this just that we need to refine:

* how this will be different from using Conditions
* how we maintain simplicity and still making it generic for all kinds of problems
* what kind of repeaters we need and how they differ in function
* is a Task the best way to implement this (maybe it is and Erik may be on the right way here)

The more feedback we can get on this issue the better.

---

Dunno, but I guess if this were to be a loop feature added to tasks - perhaps a row source - either file, ad / ldap query, odbc query, etc.

Then column names for each row I guess.

How would one do this with conditions already?

With Conditions you can move back to a specific Task in the Job depending on output for example. But maybe you are searching for something else.

One question is if the number (X times) is interesting? Isn't it more interesting that it repeats until value X meets value Y?

---

On version 4.9.24...

This might be a first step. I can see other things that would be really good to query, but for the most part it is probably system names in terms of remote execution of scripts. Not sure if others have other items...

Feature Suggestion 


Under the Manage Hostnames - there might be a screen to configure common hostnames queries - so you might define a query for all domain controllers, or make it able to read from a file, etc. In this case, a looping construct would be unnecessary, if the presumption is that it loops until it runs out of items in the query.

Here are my thoughts. I'm going to go at this from a query iteration perspective, but it should be applicable to any type of set.

It makes the most sense to me to have a task that is defined as an iterator and that task should then start either a single job or a single task - either way they should run in process. In the case of a query, my thought is for each iteration assign each field to a variable named as the field name prepended with a prefix. That way the contents of the recordset would be readily available. The variables could be automatically cleaned up after the task is complete. Something similar could be applied to a csv file or a cr delimited list.

I don't understand exactly the problem. Maybe I have the same problem.

I want to have a job with a single task which should run x times.

The task should take the parameter out of a csv file with x lines.
The parameter should be used as argument (see hardcopy).

Is that possible without API (I don't know that)?

I don't understand exactly the problem. Maybe I have the same problem.

I want to have a job with a single task which should run x times.

The task should take the parameter out of a csv file with x lines.
The parameter should be used as argument (see hardcopy).

Is that possible without API (I don't know that)?

You can change your batch file for this and use a looping construction in there.
Use the parameter from the cvs output as a looping counter in the batch file.

Regards
Erik

---

Erik, it works! Thanks!

Here my batchpgm1 statement:

FOR /F "eol=#" %%i in (%List%) do @call batchpgm2.bat %%i

%List%: Name of list, here as parm für batchpgm1
eol=# : ignore all lines starting with #
%%i: actual entry of list

Erik, it works! Thanks!

Glad I could help.

Regards,
Erik

---

in the first phase of implementing a loop or iteration of a task, the process should be kept simple and finite in its construction. this gets a quick implementation of the new tasks and events out to the public for use. then as users implement this phase I approach, the limitations will show and a more detailed implementation will be added to this simplistic but highly functional approach.

in this approach a task will have the ability to use the output of a SQL statement to a csv file (the read of a file is already implemented) or the user will manually create a csv file for input.

for example, if the task is to create a folder.....
add a BEGIN LOOP task to start, which says what to base the loop on. a csv file read, a DO X times, etc.
add a create folder task (the column names will be user variables that can be referencable in the create folder task. the cron system will simply cycle thru the rows and call the task for each record.)
add an END LOOP task to end

no method to stop the loop and skip records should be attempted in this phase. simply do not put rows in the csv file that are not needed or should be skipped.

i think this approach gets a usable version to beta in a short amount of time.

thanks

Hi,

This is an old topic, but I still think some kind of looping construction is a good addition to the product.

We might want to talk about this again.

Regards,
Erik

---

I am attaching and image our idea of Task looping. Nothing is implemented yet but we are just discussing to get feedback. Main reason is that we don't want to build us into a corner but be as generic as possible.

Here are the fundamentals of this looping capability:

* looping is a set of properties available on each Task
* there are three types of looping For, For each and While
* the 3 loop types uses Variables or direct input (numbers) as the base for looping
* there is a possibility to sleep/wait in each iteration
* loop values are available within the Task. For example you could retrieve value X in for loop or column(2) in the current "table". Read more in For each loop.

Loop type 1: For x to y

You could enter values like 1 (x) to 10 (y) or use Variables. These must be able to be converted to an integer. Both value x and y is available as temporary Variables during the Task run.

Loop type 2: While

This loop type compares two values. You need to set the type so the right comparison type is used. Left hand value (x) and right hand value (y) is available as temporary Variables during the Task run.

Loop type 3: For each

We have not fully decided on this one. But the main idea is that you have some sort of Task with output or result Variables that you use in (y). That could be FTP files download, a result of SQL query etc. We need to know the format of this "data table". That is why we have added properties for line break, tab delimiter etc.

Sleep/wait

As an additional property you can set a sleep between each iteration.

Your feedback

If there is anything are missing here, like a property or scenario, please let us know. We want to prepare for all scenarios so send us questions if you are unsure of if your particular case will be solved (and how) through this looping capability.

Also, please let us know you initial thoughts about this proposal.

---

Hi,

I think a lot of previous discussion is processed in this screenshot.
I like the For Each loop type a lot. Based on task output and a delimiter do make several iterations.

This screenshot looks like it is a task repeater. What about repeating several tasks? The might be more tasks to run in the right order than just one within the loop.
However, you can make a seperate job with all the steps for the loop, and in a different job the loop task pointing to start the job with all the steps. Is the looping value still accesible at that time?

I like the ability to have the looping values within the task. I think this is a must!

If indeed the loop method is only for 1 task only, the wait section make sence. If not, there is a wait task to handle this.

It might be handy to add a loop counter as well, telling which itteration it is. So when using from x to y, and x=4 and y=10, the itteration counter will start from 1 till 7.

Hope to get the discussion going again over here. Love the looping 😍

Regards
Erik

---

Hi,
It might be handy to add a loop counter as well, telling which itteration it is. So when using from x to y, and x=4 and y=10, the itteration counter will start from 1 till 7.

Sounds good.

This screenshot looks like it is a task repeater. What about repeating several tasks? The might be more tasks to run in the right order than just one within the loop.
However, you can make a seperate job with all the steps for the loop, and in a different job the loop task pointing to start the job with all the steps. Is the looping value still accesible at that time?

Yes, this is a limitation. But one idea could be that we add the same looping capability at Job level as well.

I don't see any good way to group a loop.

---

Yes, this is a limitation. But one idea could be that we add the same looping capability at Job level as well.

I don't see any good way to group a loop.

Looping at job level could be the trick to have more tasks repeat in order.
But it could be complex to understand, becouse you than can have looping tasks in there as well. Some looping tasks can run looping jobs.. oh oh... can this go wrong?

Regards
Erik

---

If we provided loop at Job level as well it would be a whole different thing. The idea of the Task loop is to loop the Task. If that were added to the Job one could expect that the Job should be looped - but, what you may want is to loop several Tasks within a Job - not the Job itself.

Another idea is to set some kind of property in the Loop at Task level that it should continue the loop in the next Task.

The main problem with all these properties is making it easy and intuitive to understand.

---

The main problem with all these properties is making it easy and intuitive to understand.

I agree.

I think looping one task is fine, if the task can also be 'run job'. Than the looping task should wait until the job is finished and rerun the task again if looping isn't finished. This way you can have multiple steps for a loop. During the run time of this job the looping variables must be accessible.

But you could have (if above is in place) run a job from a looping task which contains a looping task. How many levels deep do you support? This could be hard for enduser to solve issues.

For me this looks like a fine and easy solution.

Regards
Erik

---

But you could have (if above is in place) run a job from a looping task which contains a looping task. How many levels deep do you support? This could be hard for enduser to solve issues.

This is currently just on paper but there is no real limit, which is both good and bad.

---

Any new thoughts?

Regards
Erik

---

As this is a large change we are awaiting some more feedback before starting.

---