Hi,
Can anyone suggest me some good (Custom technique also for which i need to write some code) and full proof method(it should ensure that nothings breaks in his future journey) to migrate user from one process version to another process version. I have explored following techniques already:
Delete Previous processInstance and make new processInstance.
SetProcessDefinitionVersionCmd() functions.
Delete previous processInstance and create new processInstance through code and submit all user data to form till a particular information is not available. At that point as user to enter that field.
migrate user from one process version to another process version
I would say that you try to upgrade running process instance to the new process definition version. In that case I would use
SetProcessDefinitionVersionCmd() functions.
It is not enough to set only process definition version. You have to create executions…, to put the process instance into the state in which it can continue execution.
Hi,
My exact use case is, lets say i have a process version deployed and i made some changes in that process and deployed it again, so processes which were instantiated before new deployment keeps running on older version while new processes runs on newer version. So, i want old processes to run on newer version instead of old version. I know setProcessDefinitionVersionCmd() changes process definition but it is not full proof because it maps the key of task in old process to new process. I think it will fail in this condition :
Lets say initially their were 5 user task and user was on 3rd task. New process deployment was done and a new user task was added before 3rd user task in previous version. So setProcessDefinitionCmd() will put user on 4th task in new process version while he hasn’t done the new user task in newer version and if i use value of 3rd user task of new version in some later process, it will cause an error. So i want user to instead of going to a task which has same taskDefinitionKey, he should go to the new task if task is added to before his current task and stays on the current task if task is added after his current task.
Described use case is simple one. What to do when process model is more complicated? (e.g. parallel branches based on the decision …). It is not possible to easily migrate all process instances from one process definition to another in general. If you want to make automatic migration you have to take into consideration all states of the currently running process instances and map them to the new states. It means e.g. to use API to create executions, tasks, set/delete variables.
When I make this case just a little bit more complicated:
Old process definition: (Start) -> (UserTaskA) -> (UserTaskC) -> (End)
New process definition: (Start) -> (UserTaskB) -> (UserTaskA) -> (UserTaskC) -> (End)
What to do when process instance has UserTaskC active? Do we need to execute UserTaskB, UserTaskA again? Do we need to just set variables automatically?
Thanks for a quick reply. 1st case is simple. In second case what i want is, user should come at userTaskB complete it, come at UserTaskA, all values should be autofilled as user has already completed it(or fill unfilled values which might have been added in this new depoyement) so he can verify and just submit it and then come to UserTaskC.
In that case the described pattern should work for you too. Variables previously set on the UserTaskA are stored on the process instance that’s why they should be present on the UserTaskA again.
Yes, the only concern is how to automatically shift user from userTaskC to userTaskB (How to know which userTask we need to shift to) without changes in code like write logic one time and it should work everytime for every case.
If automatic migration means that we create new process definition with any change and we want to just click a button and migrate all process instances to the new definition without any further specification then
Automatic migration (Old process definition -> anyChange -> New process definition) x ( all process instances (states) -> migrates process instances (states) (and there are no restrictions to changes or states) is impossible.
We have to add some logic to the migration procedure to know what to do in the specific cases.
If we apply restrictions e.g.:
Process model is only one line of user tasks and we are allowing only adding user tasks to the line. And migration logic is that all process instances in the state after the added user task must be moved to the newly added user task, then migration can be done automatically with the described pattern.
Yes, that is what i am asking, like suggestions for logic on how to do it. I know it will require writing logic for handling all the cases and that is what i am asking. I have mentioned in my question also that custom technique is fine by me. I just need ideas on how we can do it correctly and efficiently.
The plan is to support process instance migration in 6.3.0 (https://github.com/flowable/flowable-engine/wiki/Flowable-roadmap#630-tbd)
Do you want to start to participate on this feature?
As I see now you can contribute with specific test cases at least. When you create specific jUnit tests with specification what is “old”/“new” definition/state and what is expected from migration the team can help with the implementation and examples.
Thanks for the opportunity. I would love to contribute but I am new to JAVA. Just started 2 months ago.
I don’t think i will be able to contribute anything at this point of time as i am still figuring about things in Spring Boot and Java.
