refactor publish events towards engine scope

[nitram509]

trafficstars

motivation

being more compatible with BPMN standard

acceptance criteria

• [ ] published messages are 'global' on the engine (not on the instance)
• [ ] method is renamed
• [ ] documentation is extended, minimum mentioned, that IDs of messages must be unique in order to match the right process
  • [ ] tbc. what's the matching order? first come first served?
  • [ ] tbc. how to deal with different versions of a process

[lastchiliarch]

It's seems that we need to do the message correlation instead of publishing message event to specifiy process instance.

useful docs : https://docs.camunda.io/docs/components/concepts/messages/

[nitram509]

Hi,

that's an interesting thought, yes. Message correlation is a powerful feature in Zeebe/Camunda v8. I learned/observed, that people do struggle with it in the beginning, but once understood, it's very powerful. Since lib-bpmn-engine offers a somewhat different execution context, I consider offering both options. Meaning, two functions could exists in parallel:

• PublishEventForInstance()
• PublishEventWithCorrelationKey()

[nitram509]

Update,

adding/registering a task handler has similar concepts, when it comes to the possibilities of how to do it. the fluent API as implemented in https://github.com/nitram509/lib-bpmn-engine/blob/main/pkg/bpmn_engine/task_handler.go seems to be very good fitting, as it guides the usage better and also allows more minimal invasive enhancements over time.

So, we should use such an approach here as well.