Cannot correlate message '<message name>': No process definition or execution matches the parameters

There are some queries regarding this but I am not able to point the area where to look for. Here is my scenario.

  1. A process is started via Java Code using runtimeService.startProcessInstanceByKey() method.
  2. Process proceeds and reaches to a Send Event activity, which sends a message MessgeA.
  3. Event sub-process is triggered based on that MessageA which gets triggered perfectly fine.
  4. This event sub-process performs certain functions and at the end, it sends out the Send Message Event at the end.
  5. Main process is listening for that event but an exception is raised:
    ENGINE-16004 Exception while closing command context: Cannot correlate message ‘MessageA’: No process definition or execution matches the parameters.
  6. When i see the process instance in Cockpit, it stands Completed while a yellow token on main process’ receive task.

Here is the image from the cockpit:

I have tried using Async-before, Async-after combinations with ‘Increment Order’, Event Sub Process message event and other involved areas but started getting deadlock exceptions from the database due to that.

Any suggestion, advice would be appreciated.

Thanks
HKD

Replying to my own thread, seems like an interrupting start event was used which caused the flow to diverge from the main path for not coming back. Event Sub-Process apparently is for cases where an event is required to be handled concurrently without disturbing parent process and/or diverging from the main process to another path.

Please could someone confirm the understanding?

Thanks in advance

This is exactly right - but i should also let you know that generally its not good practice to have a process instance send a message event to itself. (It’s also against the BPMN standard) It might be easier to use an escalation throw/catch event or a conditional catch event.

Hello @Niall - Thank you for the reply.

Would you please advise on the scenario below:

I created a process which is orchestrating different services and at the end, I want a sub-process to be triggered and if that sub-process reports any issue, i want the main process to show that in Cockpit.

One more issue i am facing at the moment is that when I put a parallel gateway in the front and at the end of two paths and the tasks in each path is sending an event and then waiting for the response event, one flow completes while the other one complains with below:

org.camunda.bpm.engine.context : ENGINE-16004 Exception while closing command context: Cannot correlate message ‘<my_end_message_name>’: No process definition or execution matches the parameters

This is the design:

This is the code which is correlating to the message when the exception is encountered:
runtimeService.createMessageCorrelation(‘msg_name’).processInstanceId(‘my_process_id’)
.correlateWithResult();

All this is related as i am trying to see how Camunda EE can help me to implement SAGA.

Thank you in advance,

If an incident happens in a process called by a Call Activity - it will be visible in Cockpit in the parent process and you have the ability click down to the sub-process that caused the error.

Are you trying to send a message event another part of the same process? or are the messages coming in from an external source.

  1. OK let me work on that.

  2. Yes it is being handled by the code in the same JVM process but the message is leaving and being received again via Kafka. By this question, do you intend to see the possibility of previous activity not being committed to the database and marked as finish while the message landed for the next activity and process engine is asked to correlate?

This is a common problem with Kafka.
The way to solve it is to make sure you’re waiting to receive the reply to the message before you send it. make user you add async-before on both send tasks and model it like this

Its modeled the same way or you mean after each Send Task, I need to add Parallel Gateway and then another fork for Receive Tasks?

see the existing model please:

That’s not go work - a sync before the send only works if you’re doing the receive at the same time.

Do you mean something like below?

Exaclty - the key is to make sure the process is waiting for a response BEFORE you send out the message.

1 Like

Thank you @Niall for your speedy support, loved it :slight_smile:. It worked like a charm.

1 Like

Hello @Niall - I am still getting the exceptions every now and then. What is the way to ensure that Receive Task is created before the Send Task? I don’t think that adding a delay should be an option right?

Post your model you’re using - the error message and the call you’re making to the engine.

cloudtalk-modify-quantity-v7.bpmn (32.2 KB)

I am using camunda 7.14.0-ee version.

Here is the exception I am getting:

2021-02-09 19:32:26.202 INFO [saas-isv-cloudtalk,f1dfd09bff3fe3b3,7745c94c5fb8dc09,true] 38688 — [container-0-C-1] a.e.s.i.c.c.CloudTalkMessageListener :
===========> instance id: a08fc85b-6ae3-11eb-811a-40a3ccc21d7f , State: ACTIVE

2021-02-09 19:32:26.222 ERROR [saas-isv-cloudtalk,f1dfd09bff3fe3b3,7745c94c5fb8dc09,true] 38688 — [container-0-C-1] org.camunda.bpm.engine.context : ENGINE-16004 Exception while closing command context: Cannot correlate message ‘CT_AsyncCallbackMsg_End’: No process definition or execution matches the parameters

org.camunda.bpm.engine.MismatchingMessageCorrelationException: Cannot correlate message ‘CT_AsyncCallbackMsg_End’: No process definition or execution matches the parameters
at org.camunda.bpm.engine.impl.cmd.CorrelateMessageCmd.execute(CorrelateMessageCmd.java:88) ~[camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.cmd.CorrelateMessageCmd.execute(CorrelateMessageCmd.java:42) ~[camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.interceptor.CommandExecutorImpl.execute(CommandExecutorImpl.java:28) ~[camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:110) ~[camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:46) [camunda-engine-spring-7.14.0-ee.jar:7.14.0-ee]
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:140) [spring-tx-5.3.3.jar:5.3.3]
at org.camunda.bpm.engine.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:44) [camunda-engine-spring-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.interceptor.ProcessApplicationContextInterceptor.execute(ProcessApplicationContextInterceptor.java:70) [camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.interceptor.CommandCounterInterceptor.execute(CommandCounterInterceptor.java:35) [camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:33) [camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.MessageCorrelationBuilderImpl.execute(MessageCorrelationBuilderImpl.java:313) [camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.MessageCorrelationBuilderImpl.correlateWithResult(MessageCorrelationBuilderImpl.java:224) [camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at ae.etisalat.saas.isv.cloudtalk.communication.CloudTalkMessageListener.handleEvent(CloudTalkMessageListener.java:148) [classes/:na]
at ae.etisalat.saas.isv.cloudtalk.communication.CloudTalkMessageListener.handleAsyncCallbaclEndEvent(CloudTalkMessageListener.java:128) [classes/:na]
at ae.etisalat.saas.isv.cloudtalk.communication.CloudTalkMessageListener$$FastClassBySpringCGLIB$$2ac3d1e2.invoke() [classes/:na]
at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218) [spring-core-5.3.3.jar:5.3.3]
at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:779) [spring-aop-5.3.3.jar:5.3.3]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163) [spring-aop-5.3.3.jar:5.3.3]
at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:750) [spring-aop-5.3.3.jar:5.3.3]
at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:123) [spring-tx-5.3.3.jar:5.3.3]
at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:388) [spring-tx-5.3.3.jar:5.3.3]
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119) [spring-tx-5.3.3.jar:5.3.3]
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) [spring-aop-5.3.3.jar:5.3.3]
at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:750) [spring-aop-5.3.3.jar:5.3.3]
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:692) [spring-aop-5.3.3.jar:5.3.3]
at ae.etisalat.saas.isv.cloudtalk.communication.CloudTalkMessageListener$$EnhancerBySpringCGLIB$$201c3c75.handleAsyncCallbaclEndEvent() [classes/:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_151]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_151]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_151]
at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_151]
at org.springframework.messaging.handler.invocation.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:171) [spring-messaging-5.3.3.jar:5.3.3]
at org.springframework.messaging.handler.invocation.InvocableHandlerMethod.invoke(InvocableHandlerMethod.java:120) [spring-messaging-5.3.3.jar:5.3.3]
at org.springframework.cloud.stream.binding.StreamListenerMessageHandler.handleRequestMessage(StreamListenerMessageHandler.java:55) [spring-cloud-stream-3.1.1.jar:3.1.1]
at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:134) [spring-integration-core-5.4.3.jar:5.4.3]
at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:56) [spring-integration-core-5.4.3.jar:5.4.3]
at org.springframework.cloud.stream.binding.DispatchingStreamListenerMessageHandler.handleRequestMessage(DispatchingStreamListenerMessageHandler.java:96) [spring-cloud-stream-3.1.1.jar:3.1.1]
at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:134) [spring-integration-core-5.4.3.jar:5.4.3]
at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:56) [spring-integration-core-5.4.3.jar:5.4.3]
at org.springframework.integration.dispatcher.AbstractDispatcher.tryOptimizedDispatch(AbstractDispatcher.java:115) [spring-integration-core-5.4.3.jar:5.4.3]
at org.springframework.integration.dispatcher.UnicastingDispatcher.doDispatch(UnicastingDispatcher.java:133) [spring-integration-core-5.4.3.jar:5.4.3]
at org.springframework.integration.dispatcher.UnicastingDispatcher.dispatch(UnicastingDispatcher.java:106) [spring-integration-core-5.4.3.jar:5.4.3]
at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:72) [spring-integration-core-5.4.3.jar:5.4.3]
at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:317) [spring-integration-core-5.4.3.jar:5.4.3]
at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:272) [spring-integration-core-5.4.3.jar:5.4.3]
at org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:187) [spring-messaging-5.3.3.jar:5.3.3]
at org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:166) [spring-messaging-5.3.3.jar:5.3.3]
at org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:47) [spring-messaging-5.3.3.jar:5.3.3]
at org.springframework.messaging.core.AbstractMessageSendingTemplate.send(AbstractMessageSendingTemplate.java:109) [spring-messaging-5.3.3.jar:5.3.3]
at org.springframework.integration.endpoint.MessageProducerSupport.sendMessage(MessageProducerSupport.java:208) [spring-integration-core-5.4.3.jar:5.4.3]
at org.springframework.integration.kafka.inbound.KafkaMessageDrivenChannelAdapter.sendMessageIfAny(KafkaMessageDrivenChannelAdapter.java:396) [spring-integration-kafka-5.4.3.jar:5.4.3]
at org.springframework.integration.kafka.inbound.KafkaMessageDrivenChannelAdapter.access$300(KafkaMessageDrivenChannelAdapter.java:78) [spring-integration-kafka-5.4.3.jar:5.4.3]
at org.springframework.integration.kafka.inbound.KafkaMessageDrivenChannelAdapter$IntegrationRecordMessageListener.onMessage(KafkaMessageDrivenChannelAdapter.java:455) [spring-integration-kafka-5.4.3.jar:5.4.3]
at org.springframework.integration.kafka.inbound.KafkaMessageDrivenChannelAdapter$IntegrationRecordMessageListener.onMessage(KafkaMessageDrivenChannelAdapter.java:429) [spring-integration-kafka-5.4.3.jar:5.4.3]
at org.springframework.kafka.listener.adapter.RetryingMessageListenerAdapter.lambda$onMessage$0(RetryingMessageListenerAdapter.java:120) [spring-kafka-2.6.5.jar:2.6.5]
at org.springframework.retry.support.RetryTemplate.doExecute(RetryTemplate.java:329) ~[spring-retry-1.3.1.jar:na]
at org.springframework.retry.support.RetryTemplate.execute(RetryTemplate.java:255) ~[spring-retry-1.3.1.jar:na]
at org.springframework.kafka.listener.adapter.RetryingMessageListenerAdapter.onMessage(RetryingMessageListenerAdapter.java:114) [spring-kafka-2.6.5.jar:2.6.5]
at org.springframework.kafka.listener.adapter.RetryingMessageListenerAdapter.onMessage(RetryingMessageListenerAdapter.java:40) [spring-kafka-2.6.5.jar:2.6.5]
at org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeOnMessage(KafkaMessageListenerContainer.java:2065) ~[spring-kafka-2.6.5.jar:2.6.5]
at org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeOnMessage(KafkaMessageListenerContainer.java:2047) ~[spring-kafka-2.6.5.jar:2.6.5]
at org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeRecordListener(KafkaMessageListenerContainer.java:1984) ~[spring-kafka-2.6.5.jar:2.6.5]
at org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.doInvokeWithRecords(KafkaMessageListenerContainer.java:1924) ~[spring-kafka-2.6.5.jar:2.6.5]
at org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeRecordListener(KafkaMessageListenerContainer.java:1812) ~[spring-kafka-2.6.5.jar:2.6.5]
at org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.invokeListener(KafkaMessageListenerContainer.java:1531) ~[spring-kafka-2.6.5.jar:2.6.5]
at org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.pollAndInvoke(KafkaMessageListenerContainer.java:1178) ~[spring-kafka-2.6.5.jar:2.6.5]
at org.springframework.kafka.listener.KafkaMessageListenerContainer$ListenerConsumer.run(KafkaMessageListenerContainer.java:1075) ~[spring-kafka-2.6.5.jar:2.6.5]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_151]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_151]
at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_151]

2021-02-09 19:32:26.273 WARN [saas-isv-cloudtalk,f1dfd09bff3fe3b3,f1dfd09bff3fe3b3,true] 38688 — [aTaskExecutor-2] org.camunda.bpm.engine.jobexecutor : ENGINE-14006 Exception while executing job a0f39368-6ae3-11eb-811a-40a3ccc21d7f: OptimisticLockingException. To see the full stacktrace set logging level to DEBUG.

Here is the call to the engine to correlate the message:

runtimeService.createMessageCorrelation(event.getType()).processInstanceId(event.getCorrelationid())
.correlateWithResult();

Hi @Hammad_Dar,

don’t use Async before on receive tasks.

Removing async before on the receive tasks will create the message events in the database before the message is sent. In your case, an unnessesary job executor hop is needed, which may bring the issues you saw.

Hope this helps, Ingo

@Ingo_Richtsmeier async-before is used in Send Tasks and not Receive tasks. Could you please check as I downloaded the bpmn file and verified.

<bpmn:receiveTask id=“Activity_175kyd8” name=“Email Sent for Increment” messageRef=“Message_0do93ne”>
bpmn:incomingFlow_1pepq0h</bpmn:incoming>
bpmn:outgoingFlow_15j71u3</bpmn:outgoing>
</bpmn:receiveTask>

<bpmn:receiveTask id=“Activity_1dizb66” name=“Callback completed for Increment” messageRef=“Message_13dzr93”>
bpmn:incomingFlow_0w9bsix</bpmn:incoming>
bpmn:outgoingFlow_1az67ju</bpmn:outgoing>
</bpmn:receiveTask>

Rechecked and reconfirmed, same error occurs randomly when 4-8 process instances started. I printed out the state of the process before the code which is correlating the Receive Task:

What I feel is that we have two ways:

  1. Hope that Parallel Gateway will create Receive task at-least in parallel to Send Task in my scenario.
  2. Add a wait before the Receive Task (that again has a problem as if Send Task fails and goes into retry, we are left no where)

Looking forward guys and appreciate your time which you both have already spent with me.

2021-02-09 19:59:40.806 INFO [saas-isv-cloudtalk,46c83883815f7993,bdffb168a6e86ad8,true] 5204 — [container-0-C-1] a.e.s.i.c.c.CloudTalkMessageListener :
===========> instance id: 3f5422b6-6ae7-11eb-a7ee-40a3ccc21d7f , State: COMPLETED

2021-02-09 19:59:40.814 ERROR [saas-isv-cloudtalk,46c83883815f7993,bdffb168a6e86ad8,true] 5204 — [container-0-C-1] org.camunda.bpm.engine.context : ENGINE-16004 Exception while closing command context: Cannot correlate message ‘CT_AsyncCallbackMsg_End’: No process definition or execution matches the parameters

org.camunda.bpm.engine.MismatchingMessageCorrelationException: Cannot correlate message ‘CT_AsyncCallbackMsg_End’: No process definition or execution matches the parameters
at org.camunda.bpm.engine.impl.cmd.CorrelateMessageCmd.execute(CorrelateMessageCmd.java:88) ~[camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.cmd.CorrelateMessageCmd.execute(CorrelateMessageCmd.java:42) ~[camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.interceptor.CommandExecutorImpl.execute(CommandExecutorImpl.java:28) ~[camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:110) ~[camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:46) [camunda-engine-spring-7.14.0-ee.jar:7.14.0-ee]
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:140) [spring-tx-5.3.3.jar:5.3.3]
at org.camunda.bpm.engine.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:44) [camunda-engine-spring-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.interceptor.ProcessApplicationContextInterceptor.execute(ProcessApplicationContextInterceptor.java:70) [camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.interceptor.CommandCounterInterceptor.execute(CommandCounterInterceptor.java:35) [camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:33) [camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.MessageCorrelationBuilderImpl.execute(MessageCorrelationBuilderImpl.java:313) [camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at org.camunda.bpm.engine.impl.MessageCorrelationBuilderImpl.correlateWithResult(MessageCorrelationBuilderImpl.java:224) [camunda-engine-7.14.0-ee.jar:7.14.0-ee]
at ae.etisalat.saas.isv.cloudtalk.communication.CloudTalkMessageListener.handleEvent(CloudTalkMessageListener.java:148) [classes/:na]

Hello @Niall and @Ingo_Richtsmeier - Any help further?

Please confirm the understanding as well:

Even if we create parallel flows using Parallel Gateway, there is a chance that Receive Task will be created after the message arrives for the Receive Task and in that case, error will always be reported.

Hi @Hammad_Dar,

I apologize for the confusion I created here. You’re absolutely right and I was too quick by checking your process model with the Transaction Boundaries plugin.

My learings:

  • help to improve the transaction boundaries plugin to distinguish between given transaction boundaries like a receive task and Async-Continuation configuration.
  • Don’t answer questions too quickly.

Sorry again, Ingo