We use camunda-bpm-spring-boot-starter version 3.2.1 . camunda.bpm.history-level is AUDIT. We have above subprocess. ‘Send Request’ send request to external system ( via service bus). ‘Wait for Reply’ trigger by external system response. I use custom endpoint for trigger it ( runtimeService.signal(executionId, variables); ) .‘Process Reply’ processes external system response. Generally, external system sends one response and subprocess finishes.
However, we have situations that external system response takes long time to response. In these cases, external system sends OK response. This response triggers a signal in order to do parallel actions. Final response is send to workflow and process finishes. The problem exists when these two responses have little seconds difference. In real circumstances , it is rare situation but it exists. Camunda does not throw any error and process stacks in ‘Wait for Reply’ . In order to overcome it , ‘Wait for Reply’ has be made Asynchronous After. In this case , OptimisticLockingException is thrown and subprocess is retriggered. Is there another more efficient way to overcome this problem?
In this example, my-message-name is the name of the message you define in the properties panel after you clicked on the Receive Task. To make sure the correlation finds only one receiver even if more than one process instance is waiting at the same point within the process definition you can provide further correlation keys. Please see the JavaDoc for details.
From the rest of your explanation I cannot see what you are doing in detail. Could you elaborate that.
Thanks for information provided in your response. However, it is not related with our problem. I came up with a better solution with help of history data and custom Spring rest web service.
I will try to detail problem and our solution. Lightpath_Creation_Subprocess.bpmn (10.6 KB)
In this diagram call activity with id lightpathCreation communicate asynchronously with OSS system, wait for its response and process its response. OSS/BSS system response usually takes long time to produce. OSS system send asynchronously ack OK response in order to signal lightpathCreationSignal ( Signal Intermediate Catch Event) and execute further actions waiting for final OSS System response. This is done by finding process waiting for signal lightpathCreationSignal and signal it.
New UTILS_RequestReplyCommandSubProcess is UTILS_RequestReplyCommandSubProcess.bpmn (9.3 KB)
This subprocess called by lightpathCreation communicate asynchronously with OSS system, wait for its response and process its response.
Communication with different systems is done with Apache Camel.