I have this service task which is an http-connector, which makes a call to an API.
I set her Retry Time Cycle as R3/PT5M to repeat 3 times, once every 5 minutes. My idea is that the API is called 3 times and if the call still fails, then the flow is sent to the Error Boundary Event as shown below:
What happens today is that, even setting the 3 retry attempts, the flow is still being thrown to the Error Boundary Event on the first attempt.
The way I found to do it was this one below, but I don’t think it’s the right way (the logic that I put inside the Error Event I described in the image below.):
I’m going to use the ManagementService API to fetch the number of retries and create the logic inside the execution listner, so when the retry number reaches zero, throw bpmnError.
I think you’d have to do it that way (or the way you modeled).
Retry with R3/PT5M will only work if there’s no general catch (Boundary Error) on the activity. When the 3 retries are done, then it throws an Incident.
If there’s a Boundary Error on the activity, that’s basically the same as putting a full error handler on the task, so the Retry logic doesn’t get executed.
I was already aware of this behavior, but I would like to do something like what I described, and preferably using Camunda’s default modeling, without creating too complex flow in the “design” of the process.
Anyway thank you for the answer.
I did it this way and it worked great…
Knowing that when we reach retries = 0 Camunda generates an incident, and with that the process is blocked until resolution, I solved the problem based on the “code” even before the process was blocked by an incident, making the “throw bpmnError” be thrown when the retry reaches 1, not zero.
Fiz o seguinte codigo como um END Execution Listner, na service task do camunda.
