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
4 replies
Subscribers
7 subscribers
Views
1831 views
Users
0 members are here
Share
More
Cancel
Related Discussions
Home
»
Discussions
»
User Interface
In one of my published process model, I have to change number of parameters/real
zeeshanp
over 9 years ago
In one of my published process model, I have to change number of parameters/real inputs in a form (same applies to expression rules). Since the process model is in production now, many of its instances have already been initiated by the users. If I change the number of parameters on a form and save it with the same name, it will trigger exception for all active process using this form. I was wondering how other guys handle this type of situation?
Thank you!
OriginalPostID-163125
OriginalPostID-163125
Discussion posts and replies are publicly visible
Parents
0
sikhivahans
over 9 years ago
@zeeshanp Hi, here we do need to consider two scenarios:
1. Live instances: The instances of process model which has been triggered already in the Production environment. The only issue that could arise is the form and it can break depending on the way it is invoked. So there could be two scenarios here as follows:
a. If you pass arguments to the interface/ expression rule that has SAIL form by keyword. Example: rule!XYZ(a:1,b:2,c:3). In this case you could create a constant that contains release date and time and surface the new components only if the process start time is greater than the value in release date and time constant. This way the new components will be surfaced only for new processes and also will be hidden in the processes that were triggered prior to release. I wouldn't confirm that this is an elegant way, but it drastically brings down the time required to develop, as in-flight modifications would involve many implications depending on the various scenarios. This method best fits to the changed SAIL interface as long as you invoke the expression or interface by passing arguments via keyword.
b. If you pass arguments to the interface/ expression rule that has SAIL form by position. Example: rule!XYZ(1,2,3). In this case the SAIL form breaks immediately after the release because of the change in number of parameters. So here there isn't an alternate way apart from going with the in-flight modifications as suggested by @mohanp.
2. Future Instances: The instances of process model that are about to trigger in the Production environment. As known already, there shouldn't be any issue with this.
Please do let me know if you have any followup questions.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Reply
0
sikhivahans
over 9 years ago
@zeeshanp Hi, here we do need to consider two scenarios:
1. Live instances: The instances of process model which has been triggered already in the Production environment. The only issue that could arise is the form and it can break depending on the way it is invoked. So there could be two scenarios here as follows:
a. If you pass arguments to the interface/ expression rule that has SAIL form by keyword. Example: rule!XYZ(a:1,b:2,c:3). In this case you could create a constant that contains release date and time and surface the new components only if the process start time is greater than the value in release date and time constant. This way the new components will be surfaced only for new processes and also will be hidden in the processes that were triggered prior to release. I wouldn't confirm that this is an elegant way, but it drastically brings down the time required to develop, as in-flight modifications would involve many implications depending on the various scenarios. This method best fits to the changed SAIL interface as long as you invoke the expression or interface by passing arguments via keyword.
b. If you pass arguments to the interface/ expression rule that has SAIL form by position. Example: rule!XYZ(1,2,3). In this case the SAIL form breaks immediately after the release because of the change in number of parameters. So here there isn't an alternate way apart from going with the in-flight modifications as suggested by @mohanp.
2. Future Instances: The instances of process model that are about to trigger in the Production environment. As known already, there shouldn't be any issue with this.
Please do let me know if you have any followup questions.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
Children
No Data