I just recently started to use and learn Camunda 8 and I’m having some troubles with message events.
I have a process that I’m trying to split in 2.
The first process is a POST REST Connector call. After receiving 200 response, I want to use a Message End Event.
The second process is going to be fired with a Message Start Event linked to the Message End Event of the first process, followed by a GET REST Connector call.
I put both processes bellow.
I see a lot of information about that but it’s always with Camunda 7 and there are some options such as “Message” and “Message name” that I cannot find with the desktop app in the properties panel (is it normal?).
So the way I was trying to do is not correct with one bpmn with process1 sending a message end event and another bpmn with process2 picking it up with a message start event?
It is correct, but usually you split the process models into two diagrams. And then you get a process chain, which is a common pattern.
As an edge case, you can wrap both processes into pools, make both executable and give them separate process Ids. But if you open either the first or the second process instance in Operate, you will always see both process models. It’s easier to split them up.
What would be the consequences splitting the original diagram in 3 separate ones, what is the advantage of it? I don’t think I understand fully understand that. How does it make it async.
The consequences are that you have created a loose coupling between your processes. As an advantage, you may reuse a process in another chain.
You send a message and don’t expect the full reply to be available synchronously. You check for the result later.
But this can all be done in a single process as well, as my process above shows. The Message receive tasks waits as well as the timer event. The difference is that don’t have to give the time beforehand.
Hello @Ingo_Richtsmeier , thank you again! Your explanation does help.
Regarding the Message receiving task, it will wait until the message is received. But here if I understand correctly, the timer event isn’t waiting a response but it’s just a timer to wait before going back to process2? At leat that’s what I wanted to do.
you can either attach an interrupting timer boundary event to the receive task and don’t wait forever, or change the receive task to a receive event and model the process like here with an event based gateway: Restarting an instance - #6 by Draakzward
Looking at Send task/Receive task I don’t understand the implementation.
After the gateway checking the post request response, there is the get request to retrieve a status value. Is this rest connector needed? Can the send task do the job of the get request?
