[Design of JBoss jBPM] - Re: task attributes
by tom.baeyens＠jboss.com
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 ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220744#4220744
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220744
15 years, 6 months
[Design of JBoss jBPM] - Re: task attributes
by 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...
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220650#4220650
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220650
15 years, 6 months
[Design of JBoss jBPM] - task attributes
by tom.baeyens＠jboss.com
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.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4220566#4220566
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220566
15 years, 6 months