Can the message as defined in a message end event be retrieved for an external task?

Is it only possible to use this message in a Java Delegate, or is it available to the REST API?

Context: I would like to have an external topic consumer handle a message end event and log the specific message that was returned.

Hi @danny_xneelo,

yes.

See this (very basic) example: endMessageExternalTask.bpmn (1.7 KB), violating a lot of best practices like labeling.

Hope this helps, Ingo

1 Like

Hey @Ingo_Richtsmeier
Thanks for the response.

Sorry, Iā€™m not quite sure what your example is demonstrating? Iā€™m pretty new to Camunda.
I have an external task configured with a message associated to it, but when my worker calls fetchAndLock for the tasks - the ā€œmessageā€ value is not returned like the process ID and variables are.

Hi @danny_xneelo,

the message name which can be configured in the message end event has nothing to do with the execution.

Generally, you have to implement the message sending by yourself. (https://docs.camunda.org/manual/7.12/reference/bpmn20/events/message-events/#message-end-event)

The message name is needed when you want to receive a message: https://docs.camunda.org/manual/7.12/reference/bpmn20/events/message-events/#using-the-runtime-service-s-correlation-methods.

Hope this helps, Ingo

1 Like

OK, thatā€™s what I suspected

Thanks for the help!

To clarify, while a Message end event may have a ā€˜messageā€™ associated with it in the bpmn, that message is not passed to the External task in any way? If one wanted to specify a unique variable to the external task and specify it within the modeler, would an Input Parameter be a good option? I would like to have a generic End-Message-Task handler and be able to pass something like the message name to it. I guess another option would be to use the Topic name to distinguish different end events, but Iā€™d prefer not to have to change the external handler when new Topics arise.

My ultimate goal is to provide for message end events which return to intermediate message catch events in separate processes.

Hi @Bill_Powell,

I would go with the input mapping. It creates a local variable which is available in the client out of the box and you can code your generic handler around this.

Hope this helps, Ingo

1 Like