Nested Workflow Question

[BillStreet00]

I have a workflow that has a nested workflow made up of three separate workflows. Nesting these workflows is a requirement as the number of workflows in the nested workflow will grow substantially.  Additionally each new workflow that is added has a requirement to be "pluggable" meaning the workflow can stand alone and run OR get added to the nested workflow without any additional scripting needed.

Each workflow has two inputs, masterTable and masterScore.  The workflows read in the values of these two variables, perform an operation and append/add their results to these variables.  Once complete the working variables are output again to masterTable and masterScore.  The end result is masterTable and masterScore will be used as part of a report.

I am getting an error that states "Bindings used twice for an out parameter, this is not allowed [masterScore]".  I had a small scriptable task that collates the data with seperate outputs, works fine but breaks the pluggable requirement because additional scripting is needed when another workflow is added.  If I create the workflows inline, I can resuse the variables with no issue but this workflow will quickly grow very large and bulky.

Anyone encounter this issue before and how did you get past it?

[iiliev]

What's the type of these inputs masterTable and masterScore? How do you use them both as input and output parameters? If possible, could you export and attach sample workflows showing how the parameters are bound?

[BillStreet00]

Attached.

The primary reason for this workflow is to promote a vm from staging to operating stance.  We will be checking the build code and os patching compliance (puppet module) but expect the number of these checks to grow very quickly.

tableScratch mimic what I would expect to get back on my checks.  Master table workflow is the basic version that collects the data from the two table scratch modules and collates the data.  The nestedmaster is an attempt to use nested workflows for readability.

The scratch workflows read in a string and number variable.  If the variables are blank they get initialized and the results of that check added to the string (results) and score (number). Once the first check is complete, the updated variables get passed to the second check and so on.

Thanks

Bill

[iiliev]

OK, it is clearer now.

Unfortunately, this approach won't work. One of the reasons is that nested workflows are executed concurrently, so in the best case the order in which particular executions will complete and would try to update shared output bindings would not be deterministic.

One possible solution would be to replace nested workflows with an attribute of type Array/Workflow in master workflow. This attribute will contain your scratch workflows, in the order you want they to be evaluated (if the order is significant). Then, in the master workflow, you can write some scripting code to iterate over the scratch workflows in this list, and on each iteration to manually start it via scripting, passing the accumulated results fom previous iterations as input parameters, and collecting the output parameters from this execution to pass as inputs to the next execution. A bit more code to write but 1) it satisfies your requirement to add a new scratch workflow without changing code and 2) the code should be pretty straightforward to write as your input/output parameters are simple.