Skip to main content

We have a requirement to allow existing instances of processes to be "upgraded" when a process definition is re-published. I have been thinking about the methods of doing this...

The first thought was to break a process up into many smaller processes, and then have an "angel" or "parent" process that chains the smaller processes together - then within each smaller process, have a data field recording where the process is, and line rules leading to an IPC call to kick off the same process again, and finish the current one. I gather this is probably how most people do updates to processes, but it quickly turns process definitions into spaghetti.

I had another idea...

What if (at the start of a process), two lines are taken - the normal route into the workflow, and a second route into an activity that has a preceding rule - which only happens if a "reset" condition is met... normally that second route will sit dormant, but if it does fire, the following should happen...

1. Kick off a new process instance with an IPC event
2. Remove the current process instance


Does anybody have any thoughts on how "do-able" this is? 

I've been thinking about this a bit more...

The technical problems to solve are;

1. Trigger the update of running processes by populating the process data of those process instances (programmatically open the current process instances, and set a process field to a particular value). Can this be done...

2. The worklist item that causes the reset will need to remove it's sibling worklist item. Can one worklist item remove another within the same process instance?
 

If anybody has any thoughts on this I'd love to hear them. 


If the goal is to get the data from the existing process instance into an new instance using the newly exported process definition, then check out the discussion in this post:


 http://k2underground.com/forums/thread/14132.aspx


As mentioned this uses K2ROM and K2MNG APIs.


Reply