One important question: Are all these tokens for identical tasks?
Besides this question, look at www.workflowpatterns.com and see what pattern fits most. Then look at the testcases of these patterns to see how to implement one.
If you have some more questions then, please get back to us.
Based on the website you suggest, this is the pattern I am looking for
This is effectively a case of multiple choice followed by multiple synchronized merge. The fork and Join seem right for this except that fork does not implement multiple choice - it creates tokens for all the underlying nodes.
I do not see a test case under jbpm that implements this multiple choice. Please let me know if there is one.
Yes, the nodes (Tasks) are basically the same but belong to different swimlanes.
In other words, People in different groups need to approve the contents of the same webpage simultanoeously and add their comments in the web page. But the choice of groups that can be assigned the tasks vary form one situation to the other. I think we can model the situations based on decision nodes.
Now that I read the pattern implementation in greater detail, I think there could be a creative way of doing this. We could put a decision node before each task and after the fork. The decision node will decide weather to transition to the node or to the join.
Any ideas for improving upon this idea?
This is effectively the way you would model what you want to do currently in jPDL. What you really want are guarded transitions. Another way to do this would be to create your own custom fork with a way to configure the guards...
We do it also like this:
a decision before each subpath of execution which moves directly to the join if the condition is not met.
A custom fork... aaaaah... yezzzz... several times mentioned in the forum. Maybe it is time to have a "standard" jBpm fork that does this trick :-), or to have guarded transitions everywhere (not only in decisions). I know the last one is rather difficult, because of the problems that exist with merges (how does a merge node know what paths where taken in the first place... )