After calling the publishMessage gRPC API, you get nothing back except an acknowledgement from the gateway that the message has been received by the system. You get a unique key back that represents the message publish event.
You cannot know how you arrived there in the worker. If you need to know that, you could put the same service task three times in the model (same task type, and hence same worker), with distinct custom headers per instance. Then in the worker you can examine the custom header.
i meant after i publishMessage then i need to do some action in the code. where should i put this code?
for example
i have a flow and i want that if i publish msg “cancel-flow” its will stop the current flow and i will delete all data from db
If you mean the message that flows to the notify-flow-end service task, then your clean-up code goes into the notify-flow-end service task job worker.
You should be able to use the output variable in the next node in the flow. That’s an approach to specialising the pathway that I didn’t think of. It should work to examine the engine.apisec.canceled variable in the notify-flow-end job worker, and do the clean-up code if it is true.
can i do handler like this that will listen to boundary event? @ZeebeWorker(type = “cancel-apisec-message”, autoComplete = true)
public void cancelTask(final JobClient client, final ActivatedJob job) {
}
Message catches take place in the engine. The only way to do what you want to do here, is to do a boundary message event that flows into a service task. Your code then becomes the handler for jobs of that service task type.