End Node Vs terminate Node

There is no difference in regards to data management.

The only difference is that processes that use terminate will usually end up finishing sooner (or at least are less likely to hang around unfinished), so it could have an indirect effect on your memory usage.

In general I'd recommend using terminate nodes on most process models (unless you explicitly have a reason not to) just to make it less likely that you end up with a bunch of abandoned process models. Terminates are also easier for troubleshooting, because if you end up creating multiple active flows as part of starting / restarting nodes, then you don't need to ensure that all of your active flows finish.

The only difference is that processes that use terminate will usually end up finishing sooner (or at least are less likely to hang around unfinished), so it could have an indirect effect on your memory usage.

In general I'd recommend using terminate nodes on most process models (unless you explicitly have a reason not to) just to make it less likely that you end up with a bunch of abandoned process models. Terminates are also easier for troubleshooting, because if you end up creating multiple active flows as part of starting / restarting nodes, then you don't need to ensure that all of your active flows finish.

Thanks for the detailed info, what do you mean by unfinished process or abandoned process?

Here's an example of an abandonded process: suppose you have a process model that just contains a user input task and node that writes to the database. If you start that process but then never complete the task, then the process will never complete (and the data will remain in memory indefinitely).

Now for this example in particular it won't matter if you use a terminate or not, but suppose instead you had a similar process where you had two active tasks and if either of them finished it went to an end event. In this case it would make a difference whether it was a terminate or not, because when the first one finishes the process then ends.

So that's why I mentioned that it's more of an indirect relationship, but it's still good practice to use terminate end events to prevent these cases where there are multiple active flows.

So its just a best practice, there is no difference

Here is  once scenario. I want understand

There is a parent process A that have a child process C that have end node
- On Instance there is node error on child process and after fixing it and re running node and on child process completion the parent process flow does not move ahead

- But if child process C have terminate node then on re running the errored node and on child process completion, the parent process flow moves ahead, 

WHY?????

The parent process will progress as the child process ends. "ends" is defined by: "There are no active nodes anymore". A terminating end event will take care of this and complete any active or failed node.

so it means, end node does not actually mark a process end which terminate node does, right?

Hm ... yes. The fine detail here is, that it is not about the process behaving differently, but all remaining active nodes are completed. And THAT makes the process complete and the parent progressing.

So conclusion is if we have this kind parent child sub-process scenario, we must give terminate node in child process else if a process is stand alone then it is not mandatory to have terminate node.

Am I right?

There is no "must" and no "mandatory" here. You need to understand what it does, and then use it to fit your requirements.

Peter Lewis described it pretty well.

Probably then it must or mandatory based on scenario.

Thanks for the explanation

Thanks for detailed explanation