I’m trying to receive status of an external job I’ve submitted from Camunda Process. I have a POST method which receives the status and correlates it to the process Instance. But the process engine throws MessageCorrelationException:
org.camunda.commons.logging.BaseLogger.logError ENGINE-16004 Exception while closing command context: Cannot correlate message ‘JOB_STATUS’: No process definition or execution matches the parameters.
This happens only if the status is sent by the external system in less than a second or two after the job is submitted by the process.
If the external system sends the status with a delay of 2-3 seconds after the job is submitted, my process correlation is successful and execution continues.
This is my model
Can you please let me know if there is a better model or if I’m missing anything here?
This can happen some times with fast messages. You’re pretty close to the solution. Using a parallel gateway is the first step but then you need to make sure to create a “wait state” before sending the message by ticking the “async-before” box. This will ensure that the engine starts waiting for the reply before sending the message
Thanks for your help. I’m able to receive the quick response.
Now the job I have submitted sends status periodically. I added a explicit loop to the the model to receive the status. But I get an error when I receive quick responses. The error is
Exception while executing job 30227133-86b7-11e7-b986-f6f9d34d513a:
org.camunda.bpm.engine.OptimisticLockingException: ENGINE-03005 Execution of ‘UPDATE VariableInstanceEntity[31d1cf13-86b7-11e7-b986-f6f9d34d513a]’ failed. Entity was updated by another transaction concurrently.
at org.camunda.bpm.engine.impl.db.EnginePersistenceLogger.concurrentUpdateDbEntityException(EnginePersistenceLogger.java:125)
Im curious about the structure of your process. I tend to use a parallel gateway split when the order of tasks is not important. In your use case, I would have thought that your receive job status is serially dependent on your submit job task. Hence why are you using a parallel gate as this seems to be causing some process structural challenges?
Yes, my job receive job status is serially dependent on submit job task. But the receive job status is very quick that the Camunda workflow couldn’t reach the receive task by time the response was received from the job. It was throwing No process definition found when I correlate the message to the Camunda instance. So I had to use parallel gateway and “async before” before sending the message to ensure the engine starts the “receive task” before sending the message. This allows me to receive the quick responses.
Hi,
If thats the case, heres a few more design patterns;
Is it really just a synchronous request/response rather than a status update?
Could an asynchronous service task suffice?
As an alternate to the parallel gateway approach, perhaps you could use a non interrupting, event driven sub-process?
If your called context is returning multiple status updates in quick succession, then I could see how you may get optimistic lock exceptions. Consider two events arriving concurrently. Both may trigger a thread of execution across the process model. Thread scheduling may result in interspersed execution thus resulting in optimistic lock exception. A non-interuupting sub-process may be better in this scenario, but you will have to serialise state yourself…
