We are still learning Flowable and how we can use OOTB functionality like email tasks etc. We have created a generic integration process for webservices like below screenshot, but we want to make sure that failing email tasks due to network errors will not halt the process. According to the documentation, boundary error events work like this:
“If errorRef is omitted, the boundary error event will catch any error event, regardless of the errorCode of the error.”
We have not configured any Error reference on the boundary event so it should catch all error events. But when simulating a network issue the boundary event is not triggered and the process is roled back to the last wait state.
what are we missing here? is there another way to catch errors on email tasks?
In this particular problem mail service task does not throw org.flowable.engine.delegate.BpmnError, but standard java Exception. That’s why transaction is rolled back.
If you want to create process despite of network failures, I would make mail sending task asynchronous. Job executor tries to execute failed job 3 times by default with some delay. When it fails after the last try the job is moved to the failed jobs. (You can trigger job again.)
Problem we have is that we need to keep all tasks exclusive. Before we had a problem with optimistic locking when doing tasks asynchronous (https://forum.flowable.org/t/transactions-and-concurrency). This is a generic workflow (subprocess) for fault handling during integrations and are run in parallell with one or more identical subprocesses started from a parent process (see screenshot). Users are giving and denying consent in frontend systems and we are using flowable-camel-activemq stack as orchestration engine to update external systems that are doing marketing etc.
Is there a way to catch a standard Java exception with a boundary event?
When transaction is rolled back, we end up in a timer event. The timer event is there because we needed a wait state for API response to northbound system creating the process through message event. If any of the system APIs in the subprocess where unreachable, flowable could not return the api call.
this workflow needs to do stuff in parallell and it is really important that we never get optimistic locking issue that roles back transaction and do API call again. But we want to get notified if there is issues with southbound systems, network or internal issues.
Yes, wrap mail sending task behavior in try-catch block and re-throw BpmnError instead.
I would say you can throw BpmnError (or send a signal/message) if you want to handle notification in the process model. In other case You can catch the exception and send the notification in the catch block. Another possibility is just to set result var in the catch block to error and based on the result var value make a decision whether to send notification or not.
Many thanks for the help! We now have a better understanding of how to handle mail tasks for future automated processes and are more aware of the features in flowable-admin app to handle deadletter tasks.
One way is to add a custom org.flowable.engine.impl.bpmn.parser.factory.ActivityBehaviorFactory that returns a different implementation (wrapped version) for the #createMailActivityBehavior method.
I’ve wrapped the createMailActivityBehavior of the DefaultActivityBehaviorFactory in a try catch that would throw a BpmnError if any exceptions are encountered, however it seems that the Boundary error event on the Email task could still not catch it.
