Recieve Task in flowable is not working propelly

while running business process and getting the execution of receive task it throws “exection is not found”

    List<Execution> executionList=runtimeService.createExecutionQuery().processInstanceId(trigger.getProcessInstanceId()).list();

runtimeService.trigger(executionId,varList);

please note that if wait(time) it return result successfully

any one have answer why the execution is not found without waiting

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:

Context.getTransactionContext().addTransactionListener(TransactionState.COMMITTED,
    commandContext -> {
        someService.someMethod();
    });

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.

Thanks alot for your reply

should this code be exist in service task before receive task
Context.getTransactionContext().addTransactionListener(TransactionState.COMMITTED,
commandContext -> {
someService.someMethod();
});

or where we can use this code

Yes, the transaction listener should exist in the task before the receive task. It should only contain the code that actually sends the message or contacts the external process.

Here was another post with a similar issue:

1 Like

Thanks a lot, wwitt!
how can i throw Bpmn error inside the transaction listener(in case failed to sending message)

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.

Thanks a lot, wwitt!

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.