I have a requirement where for each service task if it fails then it will retry for few times after certain interval and then will go to a generic error section for User to fix the issue.
Start → Service Task 1 ->Service Task 2 → Service Task 3 → End
Now if the process fail at Service Task 2 and I throw exception from java then after certain point of time it will retry and when retry limit reached I would like to throw an error event.
Here my question is -
Many blogs suggested to mark the service as ‘Async Before’ and then mention fail count. Why Async Before is required.
If I configure R3/PT10M then after 3 reties how I will know that the retry threshold reached and to throw an BPMN Error.
If a service fails, Camunda will go back to the last point in the process that was persisted to the DB. Putting async before will persist to the DB before making the service call.
After the 3 retries, Camunda will not throw a BPMN error - it will create an incident in the cockpit to be handled by technical support.
Take a bit of time to fully differentiate between the Business Process (should not be implementation specific) and the included Technical Processes (will be implementation specific). A failure of the technology is not a failure of the business process, and trying to handle issues of the implementing technology in the business process will make the business process hard to understand.
But is it possible to know when the 3 retries is over and incident is raised. Because if I can catch that event or retry count then my problem can be solved.
I also agree that technical error and business error should not collide but some time this retries require user task to put it in the business process again.
Actually I am trying to avoid incident and would like to handle it in BPM error handling. my requirement is once the retry count is 0 raise a BPMN error.
I can write custom incident handler if needed but from there I didn’t get any option to raise BPMN Error.
Intention - Instead of incident, it will go to business error.
Hi. Have you solved this problem? I am interested in a similar design: we don’t want an incident after the last retry because we want to handle the “permanent failure” (technical or not) at the business process level, hence we’d like to be able to throw BpmError after the last failed retry.
If the count of “retries” reaches zero, a BPMN Error will NEVER be launched, because automatically when reaching ZERO, Camunda generates an incident.
For this expected behavior, the created script should consider throwing a BPMN Error when the retries count is “1”, and not letting it get to zero.
You can use the API call below in an execution listner, or even in a java delegate as you prefer.
var retriesNumber = execution.getProcessEngineServices().getManagementService()
.createJobQuery()
.activityId(execution.getCurrentActivityId())
.singleResult()
.getRetries();
With this call you will have access to the task’s number of retries, and you will be able to throw a BPMN Error or an exception using “if/else”.
OBS: The tip I gave above works, but when trying to print the current number of retries for each looping, for some reason camunda doesn’t return the number correctly… I knew a while ago that this is an old bug (since 2018 if i’m not mistaken ) that hasn’t yet was solved.
) that hasn’t yet was solved.