Custom error handling after async service tasks retry limit is exceeded

Camunda 7 Topics Discussion & Questions
1

I have the following situation:

I use embedded Camunda process engine to start a new workflow instance when I receive a message. The workflow consists of multiple async service tasks that call some external services and also register the progress of processing the message in a local DB (business requirement).

In case of technical exceptions calling the external services, my service tasks need to be retried and, after exceeding the retry limits I need to update the state in the local DB and send a notification. Something like, beside creating incident also notify a custom handler to do some specific operations. Is there any way of modelling this?

I saw that it might be a solution to create a custom incident handler but I also saw that if you need to keep the default incident handler behavior as well you need to use Camunda internal API and that is not recommended. Any advice is much appreciated as I’m a new Camunda user.

2

Do you have any advice/suggestion for the matter (please)?

3

Hi @mm222089,

you should not model them in the process. A catching error event will not retry, it is invoked at the first exception.

I would go with this way: https://docs.camunda.org/manual/7.10/user-guide/process-engine/error-handling/#retry-failed-jobs

Offer an API in your user interface to retry the service call. You can inform the user with a custom incident handler. The incident is visible in Cockpit as well, so it could be solved by an operator, too.

Hope this helps, Ingo

4

Hi @Ingo_Richtsmeier,

Thank you for response. Unfortunately we can’t ask user to retry as its journey on the website has finished and this is a backend job that we’ll finish with sending a user callback with the results. Beside having the incident logged in cockpit and manually solve it there is no AUTOMATED way to fallback on some failure path and keep the incident logged? I have found BerndRuecker workaround but then I depend on internal API and also I loose incident creation.
We would like to be as automated as possible but not loose the default retry mechanism of async service tasks.

5