Flowable uses database transactions to isolate events from each other and ensure consistency. This means that in workflows that initiate a process outside of Flowable and awaits a response can run into issues if the response happens too quickly. The solution is usually to move the request to the external system outside of the commit transaction context. This is done with a transaction listener as follows:
Additionally, the “send a message with a service task and then have a receive task to accept the response” pattern is so common, we have a “triggerable service task” that can encapsulate both steps in the process.
That’s an excellent question, once a transaction is committed it would not be able to be rolled back.
How likely is it that you would fail sending a message? Perhaps @joram or one of the other devs with a bit more experience can offer some advice.
After some discussion, I think your best bet is use TransactionState.COMMITTING if you need to handle errors. This will ensure that message send is the last thing that happens before commit, greatly reducing the likelihood that a message would come back before the the execution was ready to be triggered. You would still need some logic that handles the received message gracefully in case it comes back too soon.
Correct. One way to solve it, is to use JTA transactions (which is heavyweight for this kind of thing).
The engine doesn’t have anything out of the box to do this, but one option could be to create a timer job (in a new transaction) to retry the message sending at a later point in time.