cancel
Showing results for 
Search instead for 
Did you mean: 

null taskId for task variables

elsarfhem
Champ in-the-making
Champ in-the-making
I see that saving a task with this service
taskService.complete(task.getId(),vars);
or
taskService.setVariables(task.getId(), vars);
will not save taskId in TASK_ID_ column.

Only
taskService.setVariablesLocal(task.getId(), vars);
will do the trick but local task variables haven't the same scope of task variables.
Am I missing something?
9 REPLIES 9

ronald_van_kuij
Champ on-the-rise
Champ on-the-rise
I think the behaviour you see is correct, or at least as intended. Local variables have the scope of the task, others have the scope of the execution. What behaviour did you expect?

elsarfhem
Champ in-the-making
Champ in-the-making
At the beginning I thought that first method links together variables and task, not only execution because I see task id in the method's signature.
This way, I have to save them two times: first time as local task variable to keep track into historical task-var relationship, second time as process variable to make them visible to the next task. Is it right?

ronald_van_kuij
Champ on-the-rise
Champ on-the-rise
So you do not actually need task local variables, you just want to know what task was responsible for a specific update of a variable? I think it should indeed not be needed to use two api calls for this.

Is your history set to full?

elsarfhem
Champ in-the-making
Champ in-the-making
yes my history is set to full, but the information lacks either in ACT_RU_VARIABLE.TASK_ID_ so before activiti passes it to history I think.

ronald_van_kuij
Champ on-the-rise
Champ on-the-rise
Sounds like a fair request… know which task set a process variable without using task local variables and not requirering using two almost similar api calls to achieve this. Please file a jira issue. Could be that it is rejected and using the two api calls is the way to go, but I'm just not sure.

elsarfhem
Champ in-the-making
Champ in-the-making
ok, i opened a Jira issue here http://jira.codehaus.org/browse/ACT-1014

ronald_van_kuij
Champ on-the-rise
Champ on-the-rise
I edited it a little

smirzai
Champ on-the-rise
Champ on-the-rise
Doesn't calling taskservice.complete cause the task to be removed from runtime tables?
If yes, then we are talking about only history. It is possible to relate variable and task in history when taskService.complete is called by filling in    act_hi_varinst.TASK_ID_  accordingly.
But then, how we should distinguish in future the scope of original variable ?

groopk
Champ in-the-making
Champ in-the-making
I see this JIRA was closed as "Not a Bug". 

Is there another way for us to tell which variables were provided when a particular task was completed?  Using setVariablesLocal doesn't work because it reduces the scope of the variables, as mentioned by elsarfhem.