How to modify expression rule without break compatibility

@amirh Just to keep things simple, afaik the approach mentioned by @tajinders is called 'by keyword' approach and the approach you have used in your process model is called 'by position'.

There are two ways to resolve the issue as per my experience in working with in-flights:

1. Use the same old expression rule and work on in-flights:

a. Upgrade the version of those processes(that made use of 'by position' approach) to the one that makes use of 'by keyword' approach. You may study this by analysing the process details(along with their process model version) report. This is bit tricky as you need to make sure that the upgraded processes won't pick up the new nodes or features added in the new versions. If there are many instances, and various instances at various levels in the process and huge changes in the recent versions of the process model, it's really time consuming to design the in-flight modification. Once you are done with this step, the instances that haven't hit the node making use of the rule (which you have mentioned) will be cured.
b. Idenitfy those processes that has got their node cancelled because of this issue. Using a Shared Component target the failed node in the identified processes, cancel the node and restart the node. (Use the 'Restart All Nodes' from 'Process Management Services' plugin. Though the name convey 'All', I belive ít has got the capability to function based on the for a given node uuid and process id.) Post completion of this step, the failed instances should be able to recover.

I could say that this approach needs a lot of investment of time in analysing the existing processes, new features in the to-be upgraded version and how existing processes picks up new features and so on. Also this needs reproduction of the scenario, with the instances of those versions that are exactly available in prod. Most important thing is, if you are dealing with production data you need to be lot more careful. I wouldn't say that it's ompossible but it needs thorough knowledge of existing processes as well as changes.


2. Approach as specified by @stefanh or your thoughts over creating a new expression rule.

But I have seen some people arguing that 'by keyword' approach isn't great and prefers to go with the creation of new versions(by appending v2,v3 and so on.) of rules upon change in the definition(i.e. inputs). Their idea is that we don't need to really end up in complicating the rule upon handling the missing inputs over the time.

I would personally encourage to use 'by keyword' approach.

@amirh Just to keep things simple, afaik the approach mentioned by @tajinders is called 'by keyword' approach and the approach you have used in your process model is called 'by position'.

There are two ways to resolve the issue as per my experience in working with in-flights:

1. Use the same old expression rule and work on in-flights:

a. Upgrade the version of those processes(that made use of 'by position' approach) to the one that makes use of 'by keyword' approach. You may study this by analysing the process details(along with their process model version) report. This is bit tricky as you need to make sure that the upgraded processes won't pick up the new nodes or features added in the new versions. If there are many instances, and various instances at various levels in the process and huge changes in the recent versions of the process model, it's really time consuming to design the in-flight modification. Once you are done with this step, the instances that haven't hit the node making use of the rule (which you have mentioned) will be cured.
b. Idenitfy those processes that has got their node cancelled because of this issue. Using a Shared Component target the failed node in the identified processes, cancel the node and restart the node. (Use the 'Restart All Nodes' from 'Process Management Services' plugin. Though the name convey 'All', I belive ít has got the capability to function based on the for a given node uuid and process id.) Post completion of this step, the failed instances should be able to recover.

I could say that this approach needs a lot of investment of time in analysing the existing processes, new features in the to-be upgraded version and how existing processes picks up new features and so on. Also this needs reproduction of the scenario, with the instances of those versions that are exactly available in prod. Most important thing is, if you are dealing with production data you need to be lot more careful. I wouldn't say that it's ompossible but it needs thorough knowledge of existing processes as well as changes.


2. Approach as specified by @stefanh or your thoughts over creating a new expression rule.

But I have seen some people arguing that 'by keyword' approach isn't great and prefers to go with the creation of new versions(by appending v2,v3 and so on.) of rules upon change in the definition(i.e. inputs). Their idea is that we don't need to really end up in complicating the rule upon handling the missing inputs over the time.

I would personally encourage to use 'by keyword' approach.