Issues about persistence of variables

[sorinello]

Hello.
I have an Activiti consistency behavior issue.
The code below (I have 2 versions) starts an Activiti Process Instance (None Start Event node). NEXT node is a UserTask node, which has a TaslkListener attached. I am NOT able to get the process variables inside the TaskListener with the FIRST version of my code (the one without MAP). Any Idea why ? Shouldn't they behave the same ?
Using second version, I can get the process variables from the TaskListener using. The same code for first version returns null:

DelegateExecution execution = delegateTask.getExecution();
System.out.println("Username " + execution.getVariable("Username"));
‍‍‍‍

First Version

activiti.getProcessEngine().getRuntimeService().startProcessInstanceById(startMappingResults.get(i));
activiti.getProcessEngine().getRuntimeService().setVariable(processInstance.getId(), "Document Name", documentName);
activiti.getProcessEngine().getRuntimeService().setVariable(processInstance.getId(), "Document Space", documentSpace);
activiti.getProcessEngine().getRuntimeService().setVariable(processInstance.getId(), "Username", username);
‍‍‍‍‍‍

and

Second Version

Map<String, Object> variables = new HashMap<String, Object>();
  variables.put("Document Name", documentName);
  variables.put("Document Space", documentSpace);
  variables.put("Username", username);
ProcessInstance processInstance = activiti.getProcessEngine().getRuntimeService().startProcessInstanceById(startMappingResults.get(i),variables);
‍‍‍‍‍‍‍

I lost 2 full days until I tried starting the process instance with the Map already defined. Please, what is the difference between my 2 approaches ? Why one is working and the other is not ?

[hyapit]

Hello,

I just started using Activiti myself and where playing with the same code you were.

Your first version won't work, because you'll have to set the variables before you start your process instance. The 2nd version IS the way to go about achieving that.

Let me guess why you were trying 1st version and why you ask this question: Are you trying to set the variables for the process that starts at much later time? If this is the case, variables are not currently supported for deferred/timed process. My workaround was to store the variables as a HistoricTaskInstance ( as I need to keep some audit trails anyway for the fact that I'm creating a timed process that generates user tasks ), and then look it up when my TaskListener executes.

[sorinello]

Hello,

Well the idea is that you can/should be able to set variables whenever you want at runtime, right ? After the Activiti Engine has been built and started, you should be allowed to add process variables when you want. For example, in a ScriptTask you can set execution.setVariable("Name", value). I am wondering why my first approach does not work. Setting a variable from a ScriptTask WORKS, this is why I have a dilemma. Why from ScriptTask works, and right after starting the process instance does not ?

Because for example UserTask/Form variables are properly saved/persisted. I can retrieve them at any time after they are created.
<code>
return this.processEngine.getRuntimeService().getVariables(executionId);
</code>
Why do you say that variables have to be stored before starting the process since UserTasks are able to create new variables at runtime ?

[hyapit]

I'm trying to understand the problem too. I ran into the exact same problem as you did and immediately use your approach #2. From your response, our setup/use-case context seems different ( It was not ScriptTask and it revolved around timer definition in my case )

Would love to hear from Activiti devs for a better understanding of Sorinello's problem.

[trademak]

In your first version the user task is already created when you set the variables.
So it depends on which event for the task listener you are using if the variables will be available. I expect you used a create or assignment event, right? When using these events, the task listener is already executed when you invoke the setVariable methods. Therefore the second approach does work.

Best regards,