HI,
I have embedded a flowable engine in a spring boot application.
I have a simple service task which calls a third party API which may fail at times.
In case of HttpServerErrorException, I want the service task to be retried in the specified FailedJobReryCycle(3 times). This is happening as expected as I’'m throwing a RuntimeException.
But after the number of retries, the process variables are not getting persisted.
How do I show the users what went wrong?
I’m not using any database in the application, except the one flowable uses.
Is there any way to persist
Following is the code in Delegate execute
if(e instanceof HttpServerErrorException){
throw new RuntimeException(e.getMessage());
}
else {
throw new BpmnError("ServiceTaskError", e.getMessage());
}
I have an exception boundary event with reference ServiceTaskError.
If you want to display this to your users, you will need to catch the exception and model in the BPMN model what happens when this exception happens.
Yes, this is what I’m doing now. In the service tasks, I’m catching Exception and throwing BPMNError and handling it with a boundary event.
But I would like to retry the service tasks a few times before throwing the BPM error. (Service tasks is asynchronous)
I was indeed able to achieve the retry setting the failed retry cycle and throwing a runtime exception instead of BPMNError. But this will roll back as you said.
How can I know in the service task that it has reached the maximum retries?
if I can get this number and the retry count set for that services task, then I can throw BPMNerror instead of RuntimeException. Or is there a better way to handle this scenario?
Yes. There is a database used by flowable. And only flowable reads/writes data to it.
We use a microservice architecture and the application data is handled by a different service.
The context of this discussion is again regarding the number of retries for a service task. I saw this discussion Retry configuration is not maintained - #3 by sukalpo in the forum regarding the failed service task retry.
An approach is mentioned by @sukalpo to store the retries in the database. I cannot go with that approach as I don’t have a database to write. :
You can get the job entity related to the current execution (the one you’re getting in as a parameter in the delegate) and check the retries (if it’s 1, it’s the last try). And then throw the BPMN error. Wouldn’t that work?
You can get the JobEntity by going through the regular service calls and then #createJobQuery() and #executionId