What is difference between end event and a terminate the event?
Discussion posts and replies are publicly visible
I always recommend that a process have a terminate event. A terminate event makes sure that receive email message nodes are no longer listening, timers are no longer active, quick tasks (for process backed records) are no longer available, ... This will make sure that this instance of the process model is now beginning its data management journey to archive, that in turn, helps keep your environment leaner.
Strong agree - I make all end nodes Terminate nodes until/unless otherwise required. In fact I'm actively annoyed that there's no way to add terminate nodes by default or at least have them show up as an extra selection - since it costs 5 or 6 clicks to switch an End around and activate the Terminate functionality.
If Appian is still interested in time savings, just look at the total minutes recovered across an application's development when you've made Terminate the default behavior of the node, and End the secondary behavior that you have to explicitly define.
100% agree as well, defaulting to Terminate functionality would be a nice time saver. Checking our dev environment, 1566 process models has costed at least 7830 clicks to just setup terminate functionality on the primary end nodes, which is probably used in over 90% of our overall End Events as well. Got my vote.
Mike Schmitt Interesting PoV. I take the "horses for courses" view - know when to use a terminate event, know when to use an end event and use as applicable. I don't see the need for making the end event terminates by default because (for me) that causes special behaviour that is only needed in certain circumstances. Which you use has no bearing on when a process instance gets flushed from memory. The criteria for that is the Data Management policy you've instituted only comes into force when all active threads have completed. So: I use End by default, and ONLY use Terminate when I need to kill the process and kill all currently active threads.
That's fine until you work O&M, and suddenly realize that if you restart or bypass a node that failed due to an error, the end event no longer actually forces the instance to close and resume the parent process. I can't count the number of times I've needed to edit an instance just to turn its plain End node into a Terminate to handle various permutations of this situaton, when they could've just used a Terminate node instead. I've never regretted using terminates liberally - the only possible exception is when a newbie developer used a terminate where they should really have used an end node, but even that is usually the other way around.
Sub process O&M is a great example - with a non-terminating end event, after restarting a node you have to ensure to cancel the error instance of the node as well (or edit to terminating end event as Mike notes). Also bitten us multiple times, which is why our code reviews require a terminating end event (properly placed of course) in all processes. In 10 years working with Appian I can't recall having many issues with terminate events, but also can't count how much troubleshooting I've done with non-terminating.
© 2023 Appian. All rights reserved.