How to handle the exception of a node in process and define a different flow if exception occurs?

Question

Hi, 
 My requirement is I need to handle the exception (Technical) which occurs in any node in a process and once exception occurs I need to follow a different flow to inform the end user about the exception occurred and complete the process. All the nodes are connected through activity chaining so in both success or error scenario an output is expected from the process. 
 
 Regards, 
 Balaji.R

Ravi Roshan · Accepted Answer

First of all set the flag at the End of the sub process, so in case your flow breaks in between your flag will be blank otherwise it will have true. You need to set the timer on the sub process setup as per your requirement (for eg., say 1 minute). Please see the attachments.

Let me know if this helps..

Harsha · Answer

One approach is to wrap the node inside a subprocess and have an exception timer on the subprocess inside parent process. When the node fails inside the sub process it will wait till the timer event then can route to error flow as you call it.

aloks0189 · Answer

Hi @rpbalaji2006 as per my understanding, if you are more. Concern about performance, then do not use timer because it runs in background which degrades the application and server performance. 
 Now coming to your query, first of all, end-user should never be informed about errors, because it's the responsibility of administrators to deal with these errors and because they are configured under alerts tab hence they will be reported by Appian and also they will have e access to designer to check the respective alerts. 
 You should never complete the process in case if node breaks, because this will cause you unexpected response / behaviour. 
 For example, you next task is completely depending on previous process response, and now because you have timer configured so it will trigger the next process, now to handle that, you need to define a gateway which checks for a variable if it's null then terminate the process, but process should not be configured in that way, because let's say, your task got broken, and if process didn't terminate then admin team can inspect and fix the issue by adding the patch and will restart from that node. 
 Timers are best for the use case when you want to configure some schedulers in your application. 
 Hope it will be helpful to you.

aloks0189 · Answer

Hi rp_balaji i agree, correct me if i am wrong, when you talk about Transaction, definitely you will be allowing standard amount of time for the process to complete it's processing, hence anyhow if you hold the process for that long amount of time, will cause you activity chaining break, and will assign an another task to the end user, hence user won't be informed through the interface, instead he need to pickup an another task else you need to send an email notification.

Also when you talk about transaction, you must be very careful about performance, which you need to sacrifice if you want to go for timers. Let's say, there are 10,000 instances for your process in production, which means there are 10,000 active timers which will cause you lot of performance issues.

So, instead of this the better way could be, create a task report for this Transactional Process (which only contains Transaction logic excluding User Input Task, and will be triggered only when User Input Task gets submitted) and capture it's start time then compare the time duration between it's start time and now() if it's more than your defined business transaction rules then simply get the process instance it and terminate it using subrocess

Also, this an be automated using one Cleanup process, which will collect all this data, and if there are any process instance with matching criteria, simply terminate them, and before termination, get the initiator of that process and trigger an email post termination of this instance.

Also, you can query for those processes whose status is Paused by Exception with in the context of this Transactional Process model, which will return you those processes which have failed during it's execution.

I believe this could be the better approach, however it's your call, because you will have more understanding about your business requirement. This is just an another approach which can be feasible for your scenario.