Can't start transaction process with messageStartEvent

Hello,

how is it possible to start a transaction process with a non-interrupting message start event ?
I have the following process set up:
transaction-process
The throw event uses the same message name as the catch event.
I use a delegate to correlate the messages:

@Override
  public void execute(DelegateExecution execution) {
    execution.getProcessEngineServices().getRuntimeService()
        .startProcessInstanceByMessageAndProcessDefinitionId(MESSAGE_NAME, execution.getProcessDefinitionId());
  }

I receive the following exception:

Caused by: org.camunda.bpm.engine.MismatchingMessageCorrelationException: Cannot correlate message ‘testMessage’: No process definition matches the parameters.

I also tried the method

startProcessInstanceByMessage

but with the same result. I start to believe it’s not possible to start it within the same process_definition or am I missing something?

thanks

Hi @Lamevire !

Have You tried async approach? Try marking particular send activities as async-before.

If You refer to Transactions in Processes you might find some custom asynchronous continuations helpful in Your case.

Hi @Lamevire,

Two points:

  • Event sub-process can only be triggered while the process is running and since no wait state preceding the throw message then nothing is committed to the database at the time the message gets thrown. (You can tick async after for the start event as in below snip to have a transaction boundary preceding the throw message)

  • Use correlate method not a start* method
    execution.getProcessEngineServices().getRuntimeService().createMessageCorrelation("do_work_msg").processInstanceId(execution.processInstanceId).correlate()

Kindly find attached a running example
throw-msg-process.bpmn (5.3 KB)

This is interesting, thank you!
Why should I rather use correlate than the method I am currently using?

Hi @Lamevire,

I believe start* method should be used when the need is to start a new process instance of a workflow definition but not to correlate a message with an execution that is waiting for this message as the case with your event sub-process.