Appian Community
Site
Search
Sign In/Register
Site
Search
User
DISCUSS
LEARN
SUCCESS
SUPPORT
Documentation
AppMarket
More
Cancel
I'm looking for ...
State
Not Answered
Replies
11 replies
Subscribers
5 subscribers
Views
3705 views
Users
0 members are here
Share
More
Cancel
Related Discussions
Home
»
Discussions
»
Process
Active Instances to stick with Old Version of Code - Post Deployment
Karthik
over 7 years ago
I want the newer instances to follow the new code and older to follow older code. Is there a way to make the active instances to follow the older version of the code though the sub-processes are yet to be triggered?
OriginalPostID-256982
Discussion posts and replies are publicly visible
0
sanjays0006
over 7 years ago
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?
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
sanjays0006
over 7 years ago
*Unless you upgrade the processes, active instances would be following the older code
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
Mike Cichy
Appian Employee
over 7 years ago
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.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
Chris
over 7 years ago
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.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
Karthik
over 7 years ago
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?
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
Karthik
over 7 years ago
@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.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
Chris
over 7 years ago
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.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
Karthik
over 7 years ago
@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.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
jaredw
over 7 years ago
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.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
ashokv
A Score Level 1
over 7 years ago
@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.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
>