Support generic properties as extension element

[menski]

Is your feature request related to a problem? Please describe.

In some use cases it is helpful to embedded generic properties inside the BPMN model to be used by another system then the workflow engine. For the Connectors use case we would need this feature in the context of inbound connectors to store configuration for the connectors in a generic way.

Describe the solution you'd like

Extend Zeebes BPMN meta model to support the following extension element on the base element type

<bpmn:extensionElements>
  <zeebe:properties>
    <zeebe:property name="name1" value="value1" />
    <zeebe:property name="name2" value="value2" />
  </zeebe:properties>
</bpmn:extensionElements>

Describe alternatives you've considered

Using existing elements like task headers, but these are not available in other elements like events, gateways etc.

Additional context

This is aligned with the Camunda 7 properties extension element and usage in the modeler.

Product Hub Epic: https://github.com/camunda/product-hub/issues/174

[korthout]

I like the idea, but want to argue for one additional alternative: use task headers for tasks, and extend events with event headers.

Arguments:

• properties might be a too general concept, which can lead to overuse and bikeshedding in the future (counter-argument: bikeshedding is exactly what I'm arguing for with task headers 😆)
• the task headers concept already exists, so we can use it for this use case as well
• adding properties next to the task headers gives a second way to express the same thing. This could lead to confusing usage. What is the recommended way to express something?
• adding event headers as a compliment to task headers seems more consistent semantically

I'm not sure whether it's much better, and I might have missed something. Let me know what you think.

[berndruecker]

I am very much in favor of zeebe:property for basically two reasons:

1. This is in line with C7 and will ease migration. If the structure is the same, we could just copy them when migrating a model. And it would be beneficial to ease migration if there is no good reason against it.
2. This is basically a generic extension mechanism allowing you to add configurations to every place in your model. We only need to provide the extension and the API, and then also customers can use that for whatever. We had use cases with C7 in the past where this was quite beneficial - and I don't see a significant disadvantage of doing this.

The difference to task headers would be (at this point in time) that task headers can be easily queried via API within a Job Worker - whereas properties need to be read from the BPMN model. Of course, we could also provide properties in the API of the Job Worker - then it might be some idea to deprecate TaskHeaders.

One other thought: if we differentiate between task and event headers, what happens if I change a Message Send Event to an Message Send Task? The behavior stays the same - but the headers are lost?

So in a way, to me, it feels like zeebe:property allows us to avoid bikeshedding, as we give people the extension points to build their own bike shed if needed.

[nikku]

@berndruecker #9868 (comment) is the exact reason we've picked this up https://github.com/camunda/product-hub/issues/335 😄