Task list and Nodes

[ashkumar]

I have 2 task nodes assigned to different swimlanes.

Node 1 is executed by actor A and node 2 is executed by actor B

When we enter node 1, Actor A is added to JBPM_TASKINSTANCE table.

When we transition from Node 1 to node 2,

Actor A remains in the JBP_TASKINSTANCE table and Actor B is added to this table and both entries have the same token id.

Now, when I query for the task list of actor A, I get erroneous results due to actor A still being present in JBP_TASKINSTANCE table with the same token ID. Actor A has already completed his task and the token ought to be in the swimlane of actor B and therefore there should be 0 tasks in Actor A's task list.

Is this the intended design or am I doing something wrong? I am infact saving the graph after the transition from Node 1 to Node 2.

Thanks,

[ashkumar]

Hi Have been able to correct the problem with a little workaround now.

if I use

taskInstance.end("tr1");

Somehow the transition is not being invoked. Maybe, the attribute "signal" in the task-node is mandatory and not optional as documented.

So, I deliberately call the signal method in the token.

taskInstance.getToken().signal ("tr1");

after the first statement.

Please note, that both the statements have to be present to get make the transition and also remove the task from the user's list of pending tasks.

But , this is not probably how the API is intended to be used. If someone could please point out what I am doing wrong, I will greatly appreciate it.

Thanks,

[akula.pratap]

Hi

I think theres no need to have 2 API calls... just signalling a taskinstance

taskInstance.getToken().signal("tr1")

not only transmits via the given transition but also it sets "end date" on the taskInstance of A. So the task-instance doesn't appear on the A's worklist.

Regards

[koen.aers]

It looks to me this is indeed a bug. Can file a JIRA issue? Most conveniently with a testcase proving this behaviour attached...

Regards,
Koen