AnsweredAssumed Answered

Exception Handling of Asynchronous Processes

Question asked by flavio.donze on Apr 12, 2013
Latest reply on Apr 24, 2013 by frederikheremans1

After the discussion here about transaction deadlocks, I ended up setting my callActivity activiti:async="true".
This solved my deadlock problem, but now I'm facing the problem of handling exceptions.

The workflow that caused the deadlocks, does not have any user interaction, it consists of a bunch of serviceTasks.
Before adding the async="true", in case one of the serviceTasks threw an exception it was caught by the client and displayed in a message box.
The whole transaction was rollbacked and no workflow was stored in the database.
Using the async="true", the client does not get notified if something went wrong, since the workflow is running asynchronous on the server.
I found this in the documentation:
But this won't fit my usecase, I dont want to have an outgoing "exception" sequenceFlow for every service task, plus it won't work because the transaction is marked for rollback.

This is one of my service tasks, for all service tasks I use my own com.softmodeler.workflow.OSGiLookup.
Right now I catch the exception in the implemented JavaDelegate.execute(DelegateExecution execution), at this point the transaction is already marked for rollback.
I can not redirect the process since it will have no effekt after the rollback, so right now I'm creating and sending an error mail to the initiator of the workflow.
As I mentioned earlier, before the workflow was asynchronous, the exception was directly displayed to the user.

      <serviceTask id="storeRepository" activiti:class="com.softmodeler.workflow.OSGiLookup">
             <activiti:field name="serviceName" expression="com.softmodeler.service.IRepositoryService"/>
             <activiti:field name="methodName" stringValue="storeProductiveObject"/>
             <activiti:field name="objectId" expression="${objectId}"/>
             <activiti:field name="param1" expression="${version}"/>

So I was wondering maybe there is a "standard" way to handle this?
Maybe an exception or fail listener on the overall workflow.
How do other people handle exceptions in asynchronous workflows?

Also now I get three mails, since the job executor tries three times to execute the workflow.
Is it possible to disable this behaviour?