I’m considering using Flowable for a fairly major implementation. My biggest concern right now is that I don’t seem to be able to trap exception that may occur in the process orchestration and when an exception does occur, the process execution just seems to stop.
There does not seem to be a way to identify stopped executions or to restart them.
Is this true, or am I missing the documentation on how to handle this?
Matt
No, the current database transaction is rolled back to the previous stable state. The exception is thrown from the API call, most likely as a FlowableException. This exception can (and should be) caught if you want to react on it.
What use case are you trying to solve and where do you see the behaviour you’re seeing?
If you want automatic retries, it’s also possible to cofigure a ‘retry interceptor’ (but a per use case treatment is better, cause otherwise anything will be simply retried, including things like sending emails and such).
After more reading, I see that my task is being executed by the Async Executor and my job is ending up in the ACT_RU_DEADLETTER_JOB table. This give me pretty much what I need. Now I just need to determine how to resubmit the job for execution. I’ll have a look at the API. I assume I somehow just need to move the entry back to the job table.
Correct: you’d need to use the managementService.moveDeadLetterJobToExecutableJob(jobId, retries) method to do that.
Also note that the job in the deadletter table should have an exception that indicates what went wrong.