Multi instance subprocess/task

[janisoft]

Congratulations on the development!

I'm getting to know the product, and I don't know exactly that it is possible to create multi instance subprocess or task?
My project is handle a customer offer process. Depend on the needs I have to collect one or more offer from my subcontractors. When all of them arrived, I can make the customer's offer ready.
Subcontractors have access to my system and every orderable item is connected to the subcontractor, so after recording the needs I could automatically produce the subtasks, if possible.

Thank you
Janos

[rallen2010]

You're looking for multiple instantiation of a sub-process? So You might have a sub-process "Make Offer" and this will fire once for each offer that exists, based on a result set returned by some query or pl/sql expression?

Sorry for not responding earlier.

[ogagneur]

Hi All,

We would have a similar requirement, where typically certain sub-tasks or sub-processes may need to be instantiated several times.
As an example, we would like to achieve something similar to what is shown on this diagram:

Number of sub-tasks/processes (approvals in this case) would be determined dynamically during the course of the main flow.

Thanks in advance for your feedback,
Olivier

[rallen2010]

OK - I get the general requirement. Variable scoping, added in 22.2 as part of CallActivities, was designed to facilitate this in a future release - as each iteration path would need its own variable scoping to avoid paths clashing.
Would it be acceptable if it were just the subProcess object that could iterate, but not individual tasks. (You can obviously put a task(s) into a subProcess and then iterate the subProcess if you wanted to) ?
Do you need iteration sequentially or in parallel or both?

[janisoft]

Dear Richard,

Thank you for your support. I think it's enough, if only subprocess has "multiple instance" functionality. For my example the parallel solution works. I can imagine this like a parallel gateway, where the number of the forward paths is a runtime value.
Janos

[ogagneur]

Many thanks to both of you.
I agree with Janos, parallel subprocesses would work for us as well.

[rallen2010]

Oliver, Janos - I have been doing some work in this area - would like to give you a demo and get your feedback.... please could you email me Richard (at) Flowquest.consulting

[rallen2010]

I think the "easy" (reminder to self: nothing is actually easy as it seems, in reality!) part of this would be adding iteration logic into the engine, to fork n-parallel iterations of a subProcess, each with a new scope, and then implement an implicit "parallel gateway merge" to recombine them.
Things to consider include handling process variable returns at the merge so that "Out mapping" doesn't just have n iterations overwriting each other (return expressions should be combinable).
But the complex part of this that might require some significant work is visualising process progress on the viewer - and how we could show progress on each of the n parallel paths. If the iterated sub-process only contains one task, you might say "I can live with that" -- but if your iterated sub-process has lots of steps and complexity, you are going to want to explore the state of each of the iterations.

It seems that there is a workaround that you could use today (with 22.2) to create your parallel iterations. It's a little messy, but not totally impractical if n < 5-7, say.

Let's build on your example above of an approval process with some in-process defined number (n) of parallel approvers.

The big idea would be to put your iterated approval process into a separate diagram, which we are going to call a variable number of times in parallel using an inclusive gateway and a callActivity. You would set the whole section up with a scriptTask or a businessRulesTask, that sets up the configuration of your iteration.

You set everything up in your businessRules Task, by setting a series of variables stream<n>_pk equal to the name or employee_id of each of the approvers. You also set a variable containing the number of paths required, num_streams := n.

The details of the approval task to be iterated is included inside a seperate diagram, which we call with a callActivity.

The nice feature of this is that functionality already inside Flows for APEX v22.2 allows you to see inside each of the n parallel approval processes - however complex that process is.

You could extend this solution into situations where you want to iterate sequentially, or in some arbitrary combination of parallel and sequential rounds. It's not quite as clean as a simple iterator -- but it should work out of the box today!

[rallen2010]

Taking this forward as an enhancement in issue #666