I'm guessing it's not probably possible, right? Or is there something missing?
My question to the dev's would be:
What is the reason that it is not implemented in jBPM? Is this due to a lack of interest from users or due to being a low priority feature? Or is there a technical / architectural problem and so it is no possible or very difficult to implement? Or is it possible and a concept how to implement this is missing?
Looking forward to your comments.
From my point of view, this feature is extremely important.
What seems the hardest is the synchronization between instances, which I cannot conceive of how to solve. If it weren't for it, it would be really easy though.
According to this site jBPM 3.x supports the variant without synchronization:
Is this also the case for jBPM 4.x? If yes this would be the point to start, no?
Workflow Patterns lists 3 variants of your desired pattern. Take a look at the patterns 13, 14 and 15. Before you can think of an implementation first of all you would have to be sure about what you are trying to achieve.
Basically instead of a task or subprocess being created directly a kind of "controller" would need to be created who creates the number of process or task instances which is needed. It would need to hold a list of all created instances. As soon as an instance has finished the controller would need to be notified. As soon as it has received notifications from all instances in the maintained list the process flow could continue.
I found a paper which explains how to implement some patterns which aren't provided with jBPM. Unfortunately the implementations are only for v3...
jPDL 3 had a task-node, which allowed spanning of multiple instances with custom java and then waiting for all of them to complete.
The code is at http://www.computer.org/portal/web/csdl/doi/10.1109/PACIIA.2008.377 , on the PDF.
Unfortunately jPDL 4 does not suppor the task-node .
As stated on the workflow patterns website:
jBPM does not support this pattern. There is a proposed implementation in Java of a node-type Node to capture this semantics. As the solution relies on java-coding we consider it outside the capabilities of the proposed jPDL language
So basically it means you can do it with jBPM, but it requires some Java coding.
Can you perhaps explain your use case?
My use case applies the concept of atomic document reviewing.
A group of people gets assigned to a reviewing task of a document. The next task can only be done when all people have reviewed the code.
The problem is that according to the document type, the peoples that might be interested in reviewing it may vary. That is only known at runtime, meaning that we don't know a priori how many review instances we are going to get. At the end, all instances must end, so the next task can proceed (e.g. giving a verdict).
look at the foreach forkhandler examples in the wiki (search the forum for more info) and implement something similar for jBPM4
I was browsing the wiki lately but I did not mange to find the foreach example. Can you point me to it, Ronald? Thanks.
take a look at this JIRA issue. There are plans to do something like this. Maybe you can support this plan by helping out with coding and testing.
How can I help? :-)
E.g. by migrating the wiki example for jBPM 3 to jBPM 4 initially.
I had a look at the wiki and even the legacy wiki but I could not find the page you're talking of, Ronald. Can you point us to it? Thank you very much.