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
8 subscribers
Views
3430 views
Users
0 members are here
Share
More
Cancel
Related Discussions
Home
»
Discussions
»
General
If previous processes are not yet completed if you change existing CDT(Adding ad
shanmukhaprasads
over 8 years ago
If previous processes are not yet completed if you change existing CDT(Adding additional columns) and Interface(example adding an extra parameter ) , User tries to access the same process then what happens and if it is a problem how can solve these type of problems ?
Thank you.
OriginalPostID-191920
OriginalPostID-191920
Discussion posts and replies are publicly visible
0
sonalk
over 8 years ago
Hi Shanmukhaprasad,
Please go through the link below, here various solutions and available smart services to solve the problem caused due to change in CDT in running instances are mentioned briefly :
forum.appian.com/.../e-191142.
Also the user will see error messages while accessing the same process.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
shanmukhaprasads
over 8 years ago
Thank you Sonal , I can see about CDT changes and Do we have any problem if any interface change i mean adding extra parameter something like that ? Thanks in Adavanc
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
nileshkumarg654
over 8 years ago
Yes , if your interface is changed it wll create the issue . The solution to this is either rename your sail interface so that older instances would use the old sail interface or use the process upgrade smart services
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
shanmukhaprasads
over 8 years ago
Thank you Nilesh
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
sikhivahans
over 8 years ago
@shanmukhaprasads Adding an extra input to the interface (the SAIL expression rule) is NOT an issue to the best of my knowledge. That completely depends on the way you pass the arguments to the SAIL interface. If you pass the arguments to the interface by keyword(https://forum.appian.com/suite/help/16.1/Expressions.html#By_Keyword), adding an extra parameter isn't an issue. In this case, the user won't see any error messages. But at the same time if you pass the arguments to the interface by position (as specified at https://forum.appian.com/suite/help/16.1/Expressions.html#By_Position) this creates an issue by breaking the tasks in old process instances.
Process upgrade comes into picture when the tasks in the older process instances break because of the extra parameter added in case when the interface is being passed the arguments via position.
And re additional columns, as long as you develop the interface in such a way that it won't try to access the newly added columns in older instances(for instance using index() or property(), controlling the behaviour of interface based on the a date and time value which indicates the newly added changes), then this shouldn't be an issue.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
shanmukhaprasads
over 8 years ago
This explains clearly , thank you @Sikhivahans
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
marky
over 8 years ago
An update to @Sikhivahans' post:
Passing expression rules and interfaces by Keyword is actually quite dangerous. This is because, if you call an expression rule or interface by not passing all parameters, the ones missed will be passed as null. In addition, this will NOT be caught by Appian, and could lead to Production defects.
Another option is to add a version to the interfaces and expression rules you are updating (such as V2), and have only the newest process models call the newest version of the interfaces, and therefore there is no issue of process instances failing due to changes to interfaces. The disadvantage to this techniqueis that any bugs identified in all versions of the interface require the bug fixes to be applied to all versions of the interfaces.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
sikhivahans
over 8 years ago
@marky Not sure if you have come across a specific scenario, but passing the arguments via keyword is really a good approach as per my knowledge. I am even sure that Appian recommends this kind of approach. Because this approach, in the first place prevents breakage of instances when there are some changes in rule inputs which may or may not significantly influence the output. I would like to oppose to the statement that it's dangerous and further would like to say that it's suggested to prevent breakage. We can see this implementation in many examples in the documentation as well.
When it comes to in-flight stuff, it depends on how we handle the changes - If we are able to handle the changes by using the same rule by considering the null values (and considering a particular point of datetime when the release is made), we can proceed with handling the same rule. This was our chosen approach and it worked very efficiently and without any issues.
Else we can create a copy of the rule, and further invoke a rule based on the datetime a release is made. I guess this should be chosen when handling the changes in existing interface becomes quite complicated or choosing this approach may also depend on individual's thought process, as it is also a kind of strategy.
Creating a new version as and when the rule inputs change might not be a great idea and best fit every time, as it is completely based on the use-case.
Probably it might be worth discussing your use-case so that we might be able to learn some new thing out of it, but definitely passing arguments via keyword is something which we shouldn't skip as per my knowledge.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
marky
over 8 years ago
Not sure if you have come across a specific scenario, but passing the arguments via keyword is really a good approach as per my knowledge. I am even sure that Appian recommends this kind of approach. Because this approach, in the first place prevents breakage of instances when there are some changes in rule inputs which may or may not significantly influence the output. I would like to oppose to the statement that it's dangerous and further would like to say that it's suggested to prevent breakage. We can see this implementation in many examples in the documentation as well.
It doesn't matter if Appian recommends it or uses this technique, it is dangerous in practice in that it creates defects that are extremely difficult to detect in testing but will be found in production.
If you pass by reference, the defects will be shown in Appian in both the interface designer and in tempo with the following error message: "Expression evaluation error at function rule!ruleName: Rule 'ruleName' has X parameters, but instead passed X-1 parameters." This means that Appian helps you in discovering that you didn't update your rule references when you updated your rules.
if you pass by keyword, you can only find error messages through extremely thorough testing including edge case testing. In practice, this level of testing is almost never done, therefore defects happen in production.
Blindly following what other people say instead of learning on your own why or why not to use techniques is not a good approach. I suggest you take the time to learn best practices based on personal experience, or listen to people that have the personal experience.
In the end, this topic doesn't matter much in version 7.9 or above. Learning to check dependencies of changed objects and update all of those dependencies is the best practice, whether you use pass by reference or pass by keyword.
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
0
sikhivahans
over 8 years ago
@marky Just because of the reason that the issues are faced, it doesn't mean that we need to stay away from the usage of 'By Keyword' approach. We can take advantage of the 'By Keyword' approach and at the same time we can also make the expression rule or interface work and derive a proper result based on the modifications made to it. This way we can stay away from breakage and also stay away from creating new rules as and when the inputs are modified.
"Blindly following what other people say instead of learning on your own why or why not to use techniques is not a good approach. I suggest you take the time to learn best practices based on personal experience, or listen to people that have the personal experience." - I wouldn't like to comment on this approach as it didn't seem correct to me and further I have gathered some info re the approach you have chosen and understood the situations that have welcomed the approach in your project. Just because of the reason that it worked for you, it might not be true to say that it's a good way to do. As per my experience earlier it depends on the scope of the use-case, because we have had come across the 'V2' approach, discussed it, but was ruled out later as it didn't seem beneficial for us (might seem for you) post considering the scope of the changes.
It's true that dependencies of changed object should be updated, but it's also important to remember that when some one isn't opting for 'V2' approach and wanted to go ahead with making the changes in same object (as we did), should also take care of preventing the breakage in in-flights and this can be done only when 'By Keyword' approach is chosen. Else we need to additionally focus on restarting the broken nodes in the process.
My way of doing is, I would lean towards 'By Keyword' approach and I would decide the strategy (whether to consider making changes in the same object or to create new version, mostly I would stick onto making the changes in same object and control the changes as per the inputs and release time) later considering the scope or project practices(in order to maintain uniformity).
Cancel
Vote Up
0
Vote Down
Sign in to reply
Verify Answer
Cancel
>