What is difference setting message correlation inside/outside a delegate

What is difference setting message correlation inside/outside a delegate?

I have a process like this,

Test 1
When I set message correlation from outside of the process like this, the message boundary event gets triggered, and the workflow exits gracefully with “say Hello”.
I correlate the message in a Spring controller

@PostMapping("/foo")
public ResponseEntity<?> foo(FooRequest request) {
    ...
    runtimeService.createMessageCorrelation(Constant.MESSAGE_FOO)
                .processInstanceBusinessKey(request.getBusinessKey())
                .correlate();
    ...
}

Test 2
BUT, if I put the correlation logic in a Listener or Delegate, it failed. Here, I put the same code/logic in a Listener, which is set as a Start Listener in step-1. From the log, I did see the Step-2 is invoked. But it then got invoked again and failed with a different executionId.
The error message is like this,

"Execution with id '2731f374-85ae-11ea-b35d-92883b51563c' does not have a subscription to a message event with name 'msgFoo': eventSubscriptions is empty",

Here is my question, with the same setting of message correlation, test-1 was successful. but test-2 failed. and why the listener which sets the message correlation got invoked multiple times in test-2? I’ve verified, the failed execution belongs to the same process instance.

So this is because the BPMN standard requires that a message event cannot be triggered from within the same scope.
So this means that a process cannot sent a message to itself. Instead you should either look into using conditional events which are much easier to trigger from within the same scope.

1 Like

Thank you, Niall. “process cannot sent a message to itself”. Yes, this is why. Kept thinking the boundary event could capture message within the scope. Thank you for clarify.

But, why I am seeing the event handling branch was triggered? Actually the first trigger was the right one, but then followed by another failed trigger which should not happen

1 Like

Used Signal event perfectly resolved this issue. thanks!