How to automate clearing or cancelling of the processes which stopped with errors?

Hello,
I am agree with the Robert Shankin and also you can use the exception handling to terminate the process. You can use the timer event for that particular nodes who can give the error and on that by adding exception timer , you can terminate the process.
Thanks
Sahil Batra

Hi sahilb346 - 

Please reconsider your suggestions here, in light of the following:

First, look at figure 1.
I've extended the example process that I shared previously.
This now includes a 1 minute exception timer in the task that fails.
Simultaneously, I've changed the timer event in the timeout lane to 5 minutes.

> figure 1

Next, look at figure 2.
This shows the same process after 5 minutes.
The write to data store task exception time never fired. 
This is because, the previous state of the task was "problem with task", and the timer never started.
If the Timeout lane timer didn't exist, this process would live indefinitely until manually stopped.

> figure 2

Now, look at figure 3, and Consider unexpected outcomes. 
In this case, a task that is typically reliable, (the script task), fails.
Without a dedicated timeout timer, set to fire based on a "safe" interval" your process will just "hang".

>figure 3

Finally, consider whether or not addressing symptoms rather than causes effectively suits the business need.
For example, is it really in the best interest of the product owner to systematically terminate error-prone processes?  Or, would it be more beneficial to understand the root-cause of the errors and resolve that?

Hi sahilb346 - 

Please reconsider your suggestions here, in light of the following:

First, look at figure 1.
I've extended the example process that I shared previously.
This now includes a 1 minute exception timer in the task that fails.
Simultaneously, I've changed the timer event in the timeout lane to 5 minutes.

> figure 1

Next, look at figure 2.
This shows the same process after 5 minutes.
The write to data store task exception time never fired. 
This is because, the previous state of the task was "problem with task", and the timer never started.
If the Timeout lane timer didn't exist, this process would live indefinitely until manually stopped.

> figure 2

Now, look at figure 3, and Consider unexpected outcomes. 
In this case, a task that is typically reliable, (the script task), fails.
Without a dedicated timeout timer, set to fire based on a "safe" interval" your process will just "hang".

>figure 3

Finally, consider whether or not addressing symptoms rather than causes effectively suits the business need.
For example, is it really in the best interest of the product owner to systematically terminate error-prone processes?  Or, would it be more beneficial to understand the root-cause of the errors and resolve that?

Hi Robert Shankin,

Thanks for your detailed explanation, I agree with your point on having timer event though we define exception timer on the specific node which helps in terminating the process if the process failed due to node which doesnt have a exception timer defined with it.

Regards,
Balaji.R

Hello Robert,

Apologies for late reply, Yes your approach is very good. But I am having a scenario :- if we are having a UI which is allowed to be in green state for long time then that we mentioned in the timer event, Only for that scenario we can only give timer to particular nodes. If for this scenario You are having any other approach please share that will be helpful for us. Thanks in advance

A timer on a task that is not in an error state should work fine.

Hi Robert,

Thanks for your detailed explaination

regards,
Anji

so exceptions with timer works as expected only for script task and not for recommended for any other smart services?

ganeshbabuj said:

so exceptions with timer works as expected only for script task and not for recommended for any other smart services?

 

This is not correct.  Exceptions can be helpful in other places.
For example, if you want to "expire" a user input task that isn't completed for a long time, an exception would be a reasonable approach to address that.

Thanks Robert , I was about to ask below
so exceptions with timer works as expected only for "user input task" and not for recommended for any other smart services?

ganeshbabuj said:

Thanks Robert , I was about to ask below
so exceptions with timer works as expected only for "user input task" and not for recommended for any other smart services?

 

 

I have described design patterns that have been effective for me.

Beyond that, if you're facing unexpected behavior with task exceptions that is not clearly detailed in the documentation, I would suggest you open a support case to address this.