If previous processes are not yet completed if you change existing CDT(Adding ad

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.

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

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

Thank you Nilesh

@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.

This explains clearly , thank you @Sikhivahans

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.

@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.

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.

@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).