task attributes

[tom.baeyens]

there is a kind of loose relation between the execution and the task. loads of possibilities. this is an attempt to come to a comprehensive set of task proeprties in jpdl so that a) the properties are intuitive and b) they cover all use cases scenarios.

so the following i would see as attributes on the task activity in jpdl:

completion = "last | first | unsynchronized | {int} | {percentage}"

completion indicates when this task is considered complete in the context of subtasks.

last is the default and means that this task is considered complete when the last subtask completes.

first means that this task is considered complete when the fist subtask completes. The remaining tasks will be left open. Another attribute remaining-subtasks="keep | cancel" could be introduced to specify what has to happen with the remaining subtasks.

unsynchronized means that after creation of the task, the process execution will continue and the task will remain open.

{int} would specify a number of tasks that have to be completed before this task is considered completed. potentially, we could add a filter based on outcome of the tasks. e.g. completion="5 approve, disapprove" would mean that this task completes with outcome approve when the 5th subtasks completed with outcome approve, otherwise, (when no 5 tasks approve tasks can be reached) this task completes with disapprove.

{percentage} would be similar to {int}, but this time it specifies the number of tasks that have to be completed as a % of the total number of tasks.

on-cancel = "continue | cascade | throw"

on-cancel specifies what needs to happen when this task is cancelled.

continue is the default and means that the execution is triggered when this task is cancelled.

cascade means that the whole process instance is cancelled when this task is cancelled

throw means that cancelling this task is not allowed and an exception will be thrown.

on-signal = "keep | cancel"

specifies what happens with this task when the related execution is signalled. this can happen because of a timer that fires on the tasks or just because this signal is given programmatically.

keep means that the task is left as is, but the task will be updated so that it will not signal the execution when it completes.

cancel means that the task is cancelled when the execution is signalled.

[tom.baeyens]

in jpdl, a task activity defines one task. users can dynamically create subtasks if they want to with the webapp.

so another question is: do we need to support subtasks in jpdl starting from 4.0.0.GA ? or can we postpone jpdl support for subtasks.

[heiko.braun]

IMO it makes more sense to have handlers in place for assignment, on-signal and on-cancel events that can be replaced.

We can provide default handlers, that model implicit behavior and can be replaced by developers that have different requirements.

At least at these early stages it makes sense to limit the impact on the public API (jpdl and java API) to a minimum, until we get enough feedback from the community to roll out a 'stable' API and implementation.

Remember that once we ship GA we cannot easily replace elements of the public API.

[kukeltje]

First of all, I think it would have been better to put this in a wiki page since it can be more easily changed then. Secondly there are some proposals made that for me contradict that we'd try to follow bpmn as it fits, at least terminology and symbol wise or am I wrong here?

With regard to HeikoÅ› remark, I am in doubt for two reasons. Firt af all, there is a difference between jPDL and the api. What Tom proposes is jPDL (xml) and not the java api. Otoh, kind of an interface but on a different level. Secondly, having replaceable handlers is what jBPM 3 also has and is in many cases the cause of the academics saying jBPM does not support certain patterns. If it is considered just an intermediate step and 4.1 (the first subsequent release where jPDL can change) will support more out of the box, I do not oppose it.

otoh, many of the proposals are already in place now in jpdl3, so conversion will become more difficult if we go down this road...

[heiko.braun]

If it is considered just an intermediate step and 4.1 (the first subsequent release where jPDL can change) will support more out of the box, I do not oppose it.

right. it's an interim solution until we about the final requirements.
All i am saying is that no half baked solution should sneak into jpdl or the API because we are forced to stick with it after GA.

But you are right with regard to jbpm3. We should gather the jbpm3 feedback wrt. to task management and see how it fit's in here.

[tom.baeyens]

handlers indeed make sense. that way we can avoid putting it in the public api and in jpdl.

then we can go more slowly on introducing only the features that we know for sure are the right ones.

and with handlers in the right place, we'll have more possibilities then in jbpm 3.

i'll publish a task handler in the next beta release.

ronald (and other community members), could you have a look after the release if the task handler and evaluate it for these criteria:
1) making jpdl simpler
2) delegating all complex things to a task handler
3) task handler covers more use cases then we can handle in jbpm 3

ronald, do you see a violation of what we did in relation to bpmn or ws-human-task ?

[kukeltje]

ronald, do you see a violation of what we did in relation to bpmn or ws-human-task ?

'violation' in a generic sense? I cannot find the bpmn 2.0 draft spec anymore to compare things. I only have some 1.x things in mind where using some attributes you propose differ in name and usage. But I do not want to compare with 1.x. So please bear with me a little until I've found the 2.0 spec again. Google is leaving me in the dark.

I'll have a quick scan for WS-HT also over the weekend.