I am using Flowable 6.6.0 java API and I am trying to implement process instances migration logic.
I have processes with UserTasks that have assigned form keys.
When I execute migrate method on ProcessInstanceMigrationBuilder, with ActivityMigrationMappings, I have seen than UserTask key and name were changed, but the form key assigned to activity was not changed.
This is a problem for me because i see the correct task in my task inbox but when I open the task, I see the old form fields.
I have a similar problem if the new task name has variables (p.e “My task ${var1}”). The var1 value is not rendered because it is not evaluated in the migration (I am using withProcessInstanceVariables method on migration).
Is there any way to resolve these migration problems?
For the form key: that sounds strange - if you migrate to a new process definition, those things come from the lastest definition. You’re using simply formKey=“XYZ”?
For the task - yes, that could be a problem, task names are not re-evaluated on migrated (which is what you want).
Now I want deploy “Process1” (version 2) with following definition:
Start → UserTaskA (formKey:taskA) → UserTaskC (formKey:taskC) → End
In process version 2, UserTaskB doesn’t exist anymore so I do the migration with mapping UserTaskB to UserTaskA because I want that all old processes that were waiting in UserTaskB have to complete UserTaskA again.
When migration finishes, my existing instance is waiting in UserTaskA (that’s OK) but its form key is taskB, so I see in inbox a UserTaskA waiting the data defined in taskB form (because on migration, flowable only changes task key and task name).
I hope my explanation help to understand what my problem is.
Thanks for the explanation, that seems to be a bug. We’ll work on a fix.
In the meantime, you could ‘fix up’ the related task in a custom piece of Java using the .postUpgradeJavaDelegate() method.
Thanks for your quickly and fantastic work!
We will try to integrate your fix in our project and see how we can resolve listeners executions and task name expression evaluation.
We have tested your fix in our project and it works OK, but we have found a similar problem with executions listeners and tasks listeners.
We are trying re-execute the listeners (start and create events respectively) using post migration processor as you recommended us, but the DelegateExecution parameter passed to execute method presents different currentActivityId (taskA) and currentFlowElementId (taskB).
If we use currentFlowElement to get the listeners, we get taskB listeners. The only way that we have found to get taskA listeners (the listeners that we want to re-execute), has been getting the BpmnModel, getting the “taskA” flowElement (using the currentActivityId) and execute its listeners.
This makes us unable to use the ListenerNotificationHelper (because it uses currentFlowElement) and implement a similar code using the listeners obtained by BpmnModel.
But this “solution” has many problems with the database transaction, error handling… because the process instance is migrated even if its listeners execution fails.