Hi,
We have long running K2 processes in our sysetm. Whenever we export a new K2 version, all the existing processes are left running under the old version. What are our options for migrating all these existing processes to the new verision, such that they will pick up all the new features now avaailable in the latest export version?
I would assume this is a common issue for K2 exporters? Are there any K2 migration tools available, or has anyone experience in developing a custom migrator for their needs? Any tips/hints would be greatly appreciated?
Many thanks,
Carl
+8
Hi Carl,
There actually is no built in way to do this kind of migration because there is no version consistency enforcement in K2. For example say you publish a 10 step leave approval process and then decide that you only need a 5 step process. You publish the 5 step process and want to migrate the open instances from the 10 step process to the 5 step process but what do you do with the instances that are on steps that no longer exist?
When you publish a new version of the process it can be completely different and have nothing at all in common with the previous version so there is no logical way to do this kind of migration.
The best recomendation is to finish out the old instances on the old version but what you can do, that I have seen other customers do, is write something that takes the data from the existing instances and starts new instances with that data. You will then have to sort of simulate the new instance through the process in order to get it to the correct step.
I hope this helps.
-Eric
There actually is no built in way to do this kind of migration because there is no version consistency enforcement in K2. For example say you publish a 10 step leave approval process and then decide that you only need a 5 step process. You publish the 5 step process and want to migrate the open instances from the 10 step process to the 5 step process but what do you do with the instances that are on steps that no longer exist?
When you publish a new version of the process it can be completely different and have nothing at all in common with the previous version so there is no logical way to do this kind of migration.
The best recomendation is to finish out the old instances on the old version but what you can do, that I have seen other customers do, is write something that takes the data from the existing instances and starts new instances with that data. You will then have to sort of simulate the new instance through the process in order to get it to the correct step.
I hope this helps.
-Eric
+1
Hi Eric,
Yes, I agree with your comments. The type of migration required is totally dependant on the actual changes made between the previous and the new versions.
We now have custom migrator working, where we have only extended the next version from the previous. By this I mean we allow:
- new activities/updates to current activities
- new line rules/updates to current lines
- etc
The migrator basically stops each process in the previous version, and copies the process data and creates a new active process in the new version. On the whole this has proved to work ok. We have not deleted the 'stopped' processes, as we still need to view the 'historical' data for this process (i.e. the path it took through the original work flow etc..).
If we should require 'breaking' changes to the worflow in the future, such as the removal an Activity then we will have to extend the migrator to handle this for sure.
Thanks,
Carl
Yes, I agree with your comments. The type of migration required is totally dependant on the actual changes made between the previous and the new versions.
We now have custom migrator working, where we have only extended the next version from the previous. By this I mean we allow:
- new activities/updates to current activities
- new line rules/updates to current lines
- etc
The migrator basically stops each process in the previous version, and copies the process data and creates a new active process in the new version. On the whole this has proved to work ok. We have not deleted the 'stopped' processes, as we still need to view the 'historical' data for this process (i.e. the path it took through the original work flow etc..).
If we should require 'breaking' changes to the worflow in the future, such as the removal an Activity then we will have to extend the migrator to handle this for sure.
Thanks,
Carl
+13
Are you allowed to share your custom migrator to other K2 users?
Is there a place where I can find 3rd party K2 add-ons/utilities?
Is there a place where I can find 3rd party K2 add-ons/utilities?
+1
Our Custom Migrator basically uses the K2ROM.Connection and K2Mng.K2Manager API's to iterate over all active processes and perform the following:
- create new process in new version
- copy process data from old process to new
- send new process to same activity as old (using goto)
- assign same user to new process as was assigned to old (using redirect)
- stop the old process
It's pretty basic, but works for us....
Hope this helps,
Carl
- create new process in new version
- copy process data from old process to new
- send new process to same activity as old (using goto)
- assign same user to new process as was assigned to old (using redirect)
- stop the old process
It's pretty basic, but works for us....
Hope this helps,
Carl
+8
Carl,
Is there any chance you could share your code with us? We have a similar need and would like to create a migrator, and it would be nice if we didn't have to start from scratch.
Steve
Reply
View our Community Site Map
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.