Accumulate output of Terminal process across Target Group

[BOB NIEDERMAN]

I have a process (Workflow?) that I execute on a Target Group of terminal Targets.  I want to gather all the outputs of the Execute Terminal Commands into one place for processing.

Concatenating it to an Output variable doesn't work.  Each Target has it's own, with only it's output.

Even writing to a file doesn't work.  Eventually, two processes try to write at the same time and one fails. 

Concatenating it to a Global Variable seems to work.  But it seems like there must be a better way.

[Shaun Roberts]

I think a global variable(table) would be ok in this case since it's across a target group. Add each output to the table and then at a certain trigger point, for-each through the table and concat each output to a big multi-line string and then you'd have your output.

Using a target property will not solve much there in that it's a per target thing(like the output). Since you are doing things in parallel writing to a file won't work well (as you saw) because of concurrency.

If you wanted to really do a file, you could build a queuing mechanism into CPO to only allow 1 process to write to the file at once. We've done this in a handful of internal cases where we only want to allow so many "hits" to an API at once. But this is not already there and would need to be developed.

Another option could be a definition type string variable which is persistent across multiple process instances. You would have to code in how to handle when to clear it out and when to display/output it, but that might work as well.

[BOB NIEDERMAN]

So I have another problem:

When I try to run this process as the child of another process, even though I've set it to run on a Target Groups of many devices, (both inside the child process and in the use in the parent process) it only runs for one of the devices in that Target Group.

Running the child process separately does execute across the target group, in parallel.

Any ideas as to what that is about?  The idea is to have the parent process be one process, to set variables, start the child process and process all the results from across the interactions with Target Group.

[Shaun Roberts]

Currently CPO does not support running(or in this case broadcasting) a single activity or child process to a target group.

Here's why and some background.

Assume we have 10 targets in a target group.

You start process A against those 10 targets, what CPO actually does is spawn 10 process instances each against *1* target from that group. It does not spawn just 1 process instance.

Now assume you call child process B or an activity inside of a process. Even though you can select a target group that is only good for the parent process (or top process) level. Once you make that a child process, it operates similar to an activity.

Here is why you cannot (currently) execute a child process or activity against a target group...

And this is a discussion that has been running for some time, but how do you determine to the parent process if that child process was successful or failed? Some would argue it must be 100/100 for success, any failure is failure. Some argued that as long as it's better than 50% that's success. Some even argued that it should be just 1/100 for success. And that shows the main issue in allow child processes and activities to execute on target groups, which to this point is not supported or developed into the product.

I understand your use-case and you can accomplish the same thing in the following manner:

1) Set your variables in your parent process

2) Use Find-Target to find all the targets in the group you want to execute against

3) Use a For-Each loop to for-each through all the targets and then place the child process inside of the for-each loop and on the child process have it use the target item in the for-each loop iteration

Now If you really want it to mimic a target group or broadcast, I would then go and select the child process(inside of the parent) to execute asynchronously.  (see below SS)

Normally if you leave this unchecked each process would wait for the previous one to complete before starting. With that checked the for-each loop will continue pass each one, not caring if one succeeded or failed. It will just start them all in succession.

I cannot remember if there is already an ENH for the target group @ activity level/child process use-case, but if not, feel free to open a TAC case and suggest it, or if there is already one, they can give you the ENH number. (as I said, I think there is one, as it's been a long running discussion topic)