"Runtime Task" Why not ?

[alclientview]

Hi everyone,

I have a question about what change can(not)/should(not) be allowed to be done at runtime. More specifically I'm thinking about Task:

The way Jbpm is implemented (if I'm not wrong) allows client application to create task instance(s) for one Task at runtime. This can be done easily by using the API. And my question is what about "Runtime Task". I mean by runtime Task: Adding a Task to a process instance.
From what I've seen, nothing prevent a client application from adding a Task to a TaskNode at runtime but this means all process instances will be affected by this change (since the change is done at the process definition level).
I'm not saying this implementation is wrong, I just try to understand what is the logic behind this choice.
There are runtime actions for example why not to have also runtime Task. Is it against the BPM philosophy, saying this is part of the process design done by the BA and in anycase that should be changed at runtime ?
I can understand this rule but then how to support the implementation of a Task node for which the creation of Task is decided by a rule (RuleEngine) ?
Sorry to be long but I'm very interested and curious to know what you guys think about this, first regarding JBPM and then BPM in general...

Thanks in advance,

Arnaud.

[jbarrez]

Creating runtime tasks is easy: simple create a new TaskInstance and save it with Hibernate. The only caveat is that it needs a token, I believe (which is a bad design choice, but it works nonetheless).

In jBPM4, the task component will be a seperate component, which will allow even easier creation of runtime tasks.

[alclientview]

I agree it's easy to create task instances at runtime and that's the way I'm using when the implementation requires such feature. But it's a bit different... I was talking about Task (not task instance). Also the default implementation of the Task instance is that its properties are copied from the Task definition when it is created... I know we don't have to follow the default implementation, JBPM is flexible enough for that. But my point is more about the logic of domain model.

Let's take an example, I have an "Approval task node" that handles the approval from two departments: HR and Accounting. When I design this by using the GPD, I will create two Tasks and at runtime one Task instance will be created for each Task.

Now if I want to do this at runtime by using a rule file (or a delegation class), one way would be to create a default Task definition for this node when designing my process and then at runtime my rules will create two Task instances (one for HR and one for Accounting) for the same Task definition.
For the same idea, which is 2 Tasks one for HR and one for Accounting (at least in the BA point of view) I'm not using the same objects of my domain model to implement it. I'm just wondering if this is ok.... ? Yes, the implementation works fine in both cases but what if one day I'm stuck because I found out I can do some specific reporting in one case but not in the other case since the implementation is different ?

[kukeltje]

Let's take an example, I have an "Approval task node" that handles the approval from two departments: HR and Accounting. When I design this by using the GPD, I will create two Tasks and at runtime one Task instance will be created for each Task.

That is indeed an option

Now if I want to do this at runtime by using a rule file (or a delegation class), one way would be to create a default Task definition for this node when designing my process and then at runtime my rules will create two Task instances (one for HR and one for Accounting) for the same Task definition.

Correct, again, an option

For the same idea, which is 2 Tasks one for HR and one for Accounting (at least in the BA point of view) I'm not using the same objects of my domain model to implement it. I'm just wondering if this is ok.... ? Yes, the implementation works fine in both cases but what if one day I'm stuck because I found out I can do some specific reporting in one case but not in the other case since the implementation is different ?

Then you have the same api at you disposal and you can 'migrate' the tasks or the complete processes by deploying a new processdefinition (or changing the existing one as you found out is also possible) and place the part of the tokens in the new tasknodes. Since you obviously want to minimize that and have clear e.g. swimlanes, make sure in advance (design time) things are split.