HI Joram,
Thanks for the reply .
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. :