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.
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()
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.