wild idea: taskinstances spawning new process instances

[icyjamie]

I would like to extend the Task/TaskInstance, so it would be possible to spawn a new process instance, similar to process-state. If the process instance ends, it could signal this to the taskInstance (which, in turn, could do its signal stuff as well).
Are there any pitfalls I should be aware of, besides the obvious transferring context from/to parent/child?
Could this be so useful it is worth contributing :-))?

[tom.baeyens]

what's wrong with the process-state node ? why do you want a task instance for this ?

regards, tom.

[icyjamie]

process-state is rather static meaning that it is specified directly in the definition.
Task instances can be created on the fly, process instances also, and it could be nice if these two are interchangable in some way. I looked into it somewhat deeper, and the original idea does not hold:
- a task is a graphelement, not a node
- a taskinstance implements only assignable
I'm now looking for a way to extend it, so it can follow the same rules defined in tasknode:
- process instances can be started using some definition specified as an element in tasknode (similar to task)
- ending a process instance notifies it, so the token in the tasknode could move, according to the rules specified on the task node.

It could be something like

<tasknode ...>
 <task name="taskName"/>
 <process name="processName"/>
</tasknode>

Of course, you could also do this by using actions, handlers, vars holding processid/tokenid and the like, but maybe it has to be a part of the engine(conforming to "Multiple Instances Without a Priori Runtime Knowledge" where and instance can be a process as well, driven by another definition)

It is Sunday today, so these thoughts are biased :-)

[tom.baeyens]

it might be because it's sunday morning here too, but i don't get it :-)

can you show the xml, its syntax and how you want the process to behave without reference to the current task mgmt ?

regards, tom.

[icyjamie]

Tom,

Maybe I could explain the business case behind it (it's still Sunday:-)):
we have little processes that behave like this:
create-approve-execute (and the alternative create-deny-correct-approve-execute). These are all tasknodes with one task defined, because different userroles (swimlanes) are involved here.

We have a main process were users are gathering information, according to a series of steps (a sequence). At a certain tasknode, the process should be able to start an arbitrary number of the above processes, based on runtime information gathered by the users. The main process should halt until the subprocesses are complete. (The token should stay on the tasknode, and moving along its path if al the subprocesses are ended, similar to the ending of taskinstances)
Fork/Join construct is not the right choice, because in the process definition, there is a fixed number of paths.
Tasknode/task/taskinstance is not the right choice, because the taskInstance has only a "completion" construct (taskInstance.end()), without having subprocess-spawning constructs.
ProcessState/Subprocess is not the right choice, because of its static nature.

Tomorrow, I will post a full example of the xml. PSP is waiting now :-)

James

[icyjamie]

As promised, an xml example. It could look something like this

<process-definition name="HandleCase">
 <start-state name="start">
 <transition name="toDefine" to="DefineTasks"></transition>
 </start-state>
 <swimlane name="manager">
 <assignment class="com.sample.action.ManagerAssignmentHandler" config-type="constructor"></assignment>
 </swimlane>
 <swimlane name="agent">
 <assignment class="com.sample.action.AgentAssignmentHandler" config-type="constructor"></assignment>
 </swimlane>
 <end-state name="end1"></end-state>
 <task-node name="DefineTasks" create-tasks="true" signal="last">
 <task name="DefineTasks" blocking="true" swimlane="manager"/>
 <transition name="toCreate" to="CreateTasks"></transition>
 </task-node>
 <task-node name="CreateTasks" create-tasks="false" signal="last-wait">
 <sub-process name="CreateDocument" blocking="true"/>
 <sub-process name="CreateEmail" blocking="true"/>
 <task name="callCustomer" blocking="true" swimlane="agent"/>
 <transition name="tr1" to="end1"></transition>
 </task-node>
</process-definition>

I left out any variable definition.
The process starts and assigns a manager to define some tasks, that will be created in the next step. The information is stored in map, which is passed to the CreateTasks node when the manager ends the DefineTasks instance.
The CreateTasks checks the map and creates all processes and tasks defined in there.
The CreateTasks waits until all subprocesses and tasks are ended. The token moves to the endstate.

I don't know if this functionality still is in the spirit of a TaskNode (as sub-processes are spawned as well). Maybe this could be another node definition.

James

[tom.baeyens]

i see 2 ways of modelling it within the current jpdl:

1) suppose your business analyst has drawn the process diagram and you're not allowed to change the nodes and transitions. in that case, you can write a custom node implementation in an ActionHandler.
...


...

...

In that implementation you can create tasks and subprocesses as you wish.

2) if you can change the process model, you could use a custom fork, a regular join and a task node. The custom fork will spawn new paths of executions (=tokens) over some of the leaving transitions, based on the selections made by the manager.

i think we should keep the functionality of tasklist management and subprocesses separated in 2 distinct node types.

regards, tom.

[icyjamie]

Tom

Thanks for the input. I will investigate the second suggestion. If we were not allowed to change the nodes and transitions, we would nail our business analyst to the wall and forced him to listen to some Vogom poems.