Is it possible to create and run a looping BPMN? We are handling this Java application using the Camunda 7 library, and we get errors in message correllation, messages don’t seem to arrive in the sequence expected by the BPMN, and this is out first looping BPMN.
Is it possible that Camunda 7 has issues with that?
Here is.
rpa_bib_connect_integrated_process_no_parallel.bpmn (24.9 KB)
We are connected to the Camunda Java library. We have two sources of messages (I don’t understand why we have two). In one of the message handlers we do message correlation: we receive a message bearing the name of the Service Task, and then we correlate it to the name of the event task that follows, just by adding “_OUT” to the message name. Messages seem to be generated and regenerated with the same name (I know that our process is reccursive), but after correlating one message name, it appears impossible to do it again because we get OptimisticLockExceptions. I am sure not to understand many things.
Thank s for your help.
Hello my friend @BigBlackHoss, Welcome to community \o/
from what I’ve seen, your BPM model seems functional.
Something might be happening in your message send handlers.
Just to provide some context, the OptimisticLocking occurs when there are 2 or more transactions in the Camunda database that try to update the same variable/entity. Thus, Camunda uses this OptimisticLocking mechanism to control this concurrency.
Imagine that while waiting for the message correlation in the “Receive one row” Receive task, your two messageCorrelate handlers try to correlate the message “BIB_IN_READ_BATCH_OUT” at the same time. This could cause an OptimisticLocking and lead to undesired behavior.
So, I believe the first main point would be to check that.
The second point that I would address, and actually what I usually do, is…
Set “Asynchronous continuations = After” on the Receive tasks. This is because, imagine that this correlation is done automatically. When you don’t have anything set, Camunda saves transactions at the “stop” points… thus, it will save the transaction before receiving the message.
Now, imagine you received the correlation, and in your service task, an incident occurred. The instance will return to the last point where the transaction was saved, which was the “receive task,” and then you would lose the “correlation” that you had obtained previously.
If you set async after on the receive task, it’s like creating a “save point” after receiving the message correlation, and it won’t be lost anymore.
Anyway… I hope this helps in some way.
William Robert Alves
William, thank you for your response. Be patient because you are far more advanced on Camunda topics and I am trying to understand what you said. So I take away the following points:
OK, so I did all of that (maybe it’s an overkill) and then I got the file attached. The Optimistic Lock Exception is still there in the version of the file that I attach now. In other version, I agree that I did not have it but in all cases the execution blocks at the end of the sub-process. Do you have more suggestions?
And then I have another question: The fact is that I don’t understand message correlation. For all I know, message correlation allows you to go to the next activity in the BPMN. But then, in the BPMN you already have arrows and gateways that allow you to determine the next step. So what is the role of correlation in the end?
rpa_bib_connect_integrated_process_no_parallel.bpmn (26.3 KB)
Hello my friend! I apologize if maybe I’m going too fast, but thanks for letting me know!
It’s basically what you said below, Camunda by default makes transactions in the database at each “breakpoint”, and the breakpoints are exactly where the instance is stopped waiting for some action to occur in the process.
However, this behavior can be modified using async before or async after.
Below is a link from Camunda itself explaining very well about the subject, I’m sure it will be a great knowledge to add.
As for your process, I see no reason to have a “message boundary event”.
I believe that the desired behavior in your subprocess, when it finishes you want it to exit your subprocess and start the service task “Read one row”, right?
If so, you can remove your boundary event, and connect it only with a sequence flow, because when your instance reaches the “End event”, it will go out through the sequence flow towards your service task, as I did in the example below :
The message correlate is for you, at some stage of your process, to be able to “warn” so that another stage starts through a message correlation…
For example in this process of yours, when your subprocess receives this message correlation, regardless of the stage it is in, it will exit the subprocess without finishing, because you sent a message to it saying: “I am ordering it to exit, and go to the service task NOW” hehehehe, almost like that.
That is, when you have subprocesses interconnected by sequence flows, you shouldn’t use message events.
I hope this helps!
William Robert Alves
Hello !
Did my answer solve your problem bro?
Let me know please!
Regards,
William Robert Alves
Hi William! Thanks for the follow up. I’m sorry but we were somewhat busy with a PROD deployment.
We still have a problem, but I think it’s in the way we use (or don’t use) Camunda. We followed one of your suggestions involving thriggering the async after, but it doesn’t change anything. Are we supposed to get a message of some sort? What is the observable of that?
You’re welcome my friend @BigBlackHoss 
!
No my bro, it would just change the behavior internally in Camunda and in the database transactions, avoiding some types of errors like the ones I mentioned earlier. But you would not receive any kind of warning about this. 
Hi William! Thank you for your support! We have found the problem in our system. Apparently it was an error on our part. In the Camunda context we had a variable called “jobId” and then by mistake we also added “JobId” with a capital J. Camunda 7 reacted with the Optimistic Lock Exception without reporting the specific culprit variable name. I understand this call is probably delagated to lower software layers, but I recommend to improve this error reporting in future versions if it is possible. Thanks again!
Excellent! I’m glad you found the problem.
Thank you for sharing the answer and your feedback with us. \o
William Robert Alves
