refactor publish events towards engine scope

nitram509 / lib-bpmn-engine

A BPMN engine, meant to be embedded in Go applications with minimal hurdles, and a pleasant developer experience using it. This approach can increase transparency for non-developers.

https://nitram509.github.io/lib-bpmn-engine/

MIT License

285 stars 74 forks source link

refactor publish events towards engine scope #44

Open nitram509 opened 2 years ago

nitram509 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.