wouldn't a decision node work better in place of the fork? That would prevent you from having to "kill" the waiting token.
sorry, that wouldn't work would it.
A small correction to the above post:
In the second solution, I need to "kill" the token at the other task, not for the process instance to continue (it will, cause there is no join node), but in order to eliminate the task instance from the other actor's task list. Otherwise, if actor A finished the task, actor B would still find a pending task, and I don't want that to happen.
In one of the very recent other post in a different topic, Alex (the great) reminded me of something. You can put multiple tasks in one task-node and give each task it's own actor. You can then use the signal and end-task attributes to 'configure' the behaviour of the task-node. signal=first and end-task=yes would give the behaviour you need for 'killing the other task' at least.
The default webapp in 3.1 still renders all transitions afaik. In 3.2 custom forms can be created where you just show the specific transitions.
This looks like a combination of both, but might be a suitable solution. I at least am going to try and implement something like this for a small internal demo.
Thanks for the reply.
I see what you mean, but for what I need, multiple tasks in a task-node are not too different from one task for pooled actors (my first suggestion). The available transitions are per task-node, not per task, so I still have to decide which transitions are forbidden for the logged actor.
The ideal scenario would be having transitions per task, but I don't know if that goes against the basis of workflow philosophy (which I am starting to grasp) :-)
There IS a big difference. It is possible to have a task node cancel other tasks if one is acted upon. Multiple tasknodes each with their own task cannot do this. You have to write additional code for that.
No, I mean one task node with multiple tasks vs. one task node with one task assigned to multiple (pooled) actors.
What about an NODE-LEAVE action that evaluates who's logged in and depending on that manipulate the transitions (like for example. storing in some list the available transitions for that user)
hmmm... then I don't understand your problem correctly (I think)
Let me summarize:
- one task per tasknode and a fork
advantage: you can have a generic page which shows only the transitions for that task(node).
disadvantage: write code to cancel other task
- two tasks per tasknode and no fork
advantage: other task is cancelled if one of them is acted upon (no code)
disadvantage: create custom page per task
I'd go for the latter and imo there is more than a little difference. A custom page will be very easy with jBPM 3.2 (one copy action and one delete (of one of the transition buttons) You could even make one page with a dynamically visual buttons for taking the transitions.
Cavalera: the node leave is to late in the handling of the action. One is already selected then, so all you can do is throw an 'not-allowed' exception e.g. and handle that in the page. Not an elegant solution.
Ok, Ronald, there's some confussion here so I will summarize too.
1) My first suggestion: one task node, one task, pooled actors, no fork.
2) My second suggestion: one fork, two task nodes, one task each task-node.
3) Your (Alex's) suggestion: one task-node, two tasks, no fork.
I said there is little difference between 1) and 3).
You said there is big difference between 2) and 3)
I think we're both right, it's just that we were comparing different options :-)
You correctly pointed out the advantages and disadvantages of 2) vs 3). I say the same advantages and disadvantages of 3) apply to 1).
What I see is that either for 1) or 3), as both have only one task-node and therefore a common set of transitions, it is impossible to define at the processdefinition.xml which transitions are allowed to which actors, no matter if the task-node has one task or multiple tasks .
So If I choose 1) or 3), I have to decide at the webapp level, without any help from jBPM, if I have to render a button for this transition for that actor. It's sad that this kind of information could not be available from the processdefinition.xml through the jBPM API, but again, maybe I'm missing the point. I don't know if jBPM 3.2 will help me either.
With this in mind, now I find it easier to implement the 2) option (a fork, and killing the other task).