Active Instances to stick with Old Version of Code - Post Deployment

Karthik, Unless you upgrade the processes, it would behave in the same way. Can you add one more column(version -- pm!version into the Active instances report) and check whether the version is changed or not?

*Unless you upgrade the processes, active instances would be following the older code

Your subprocesses need to be backwards compatible, there is no way to select which version of the subprocess to select at runtime.

You could potentially create copies of models and map these in the parent, which means you would not update the existing process models. However, I think this could provide for a poor user experience since tasks triggered back to back will be different depending on when their parent was kicked off.

This adds to the case for data-centric design and short-lived processes. It makes backwards-compatibility so much easier to manage.

For this reason we have been implementing a 'version' variable in our process models - this integer is passed from parent to sub processes where you can define processing based on which version the parent model is running under. When you implement changes to the parent, increase the version flag and your sub process can use this logic where necessary: if(pv!version<2,*use old methods*,*use new methods*). Since both running/active parent and new parent processes will use the same sub process version, something such as this manual control is necessary if you need to maintain legacy sub process function for legacy parent processes.

Mike, I've already created a copy of the sub-process and did not alter the copy. The copy and the altered processes are kept as sup-processes in the main PM. I have to decide which sup-process to kick-start at runtime and currently I am considering a business data to make that decision. However, Is there any process data that I can make use of?

@csteward, thats a good idea. However, I dont have any variable defined at the parent PM to hold the version info and of course the active instance wont have this variable at its runtime. Hence, I am thinking to stick with a business data which can give me a clue.

In the situation where you do not have this defined yet, what you can do is define this variable/parameter at the sub process level with a default of 1, older parent processes (after you implement in the parent) will not send this variable, thus the sub will use a default of 1, where new parent processes WILL send in variable with version 2+, so it is achievable to implement this immediately but this method will not work for distinguishing between 2 legacy versions prior to implementation.

For your case, you might be able to achieve this by creating a process report for the parent processes with pp!id (instance ID) and pm!version. In your sub process, you should be able to retrieve the parent process instance id using parent_process_id(). You can then pull the parent version from your new report, based on this instance ID, and direct your sub process accordingly.

@csteward, thanks for the info. Let me try the first option of having a subprocess variable. In my case, I have only one legacy version.

There is a plugin that allows you to create a new process variable in running workflows of a specified workflow and set a value for it. So you could implement the solution that csteward suggested, you just have to be sure no one is using the active workflows at the same time you're adding the new variable.

@karthikeyans75: If you have used rules say ui_sample(), you can create a new rule say ui_sample_v1() with new code. You can use the new rule in the process model and save and publish it. This will take the new code while the old instances will be using the same old rule. Not sure if this works in ur scenario, but I've successfully implemented this approach for one of my process.