Add element templates support for Connectors story

[MaxTru]

What should we do?

Implement pragmatic element templates support for Zeebe matching the first Connectors User Story.

Cf. Rest connector example

• support zeebe:taskDefinition:type binding (minimum Hidden)
• support zeebe:taskHeader binding (minimum String & Dropdown)
• support zeebe:input binding (minimum String)
• support zeebe:output binding (minimum String)

What is out of scope for now, but will be interesting in the next iterations

• Add ability to create optional inputs & outputs via cloud element templates #559
• Make it possible to structure element templates in sections camunda/camunda-modeler#2673

WIP branches

• https://github.com/bpmn-io/bpmn-js-properties-panel/commits/540-spike-c8-templates
• https://github.com/camunda-cloud/zeebe-bpmn-moddle/tree/540-templates-support
• https://github.com/camunda/camunda-bpmn-js/tree/540-c8-templates-support

Why should we do it?

To support the Connectors Project

Goals:

• Implement pragmatic support for element template descriptor to be provided by the Connectors team (DRI @nikku )
• Have this support ready ASAP as "end-2-end durchstich"

Non-Goals:

• Update of schema
• Update of schema-validation
• Logic to distinguish Platform or Zeebe templates and filter accordingly
• Refactoring of element templates architecture (given that we re-use element-templates for zeebe, this may be needed in the future)

Context

Child of camunda/camunda-modeler#2640

[pinussilvestrus]

As shared yesterday I created a first spike on it, only supporting basic BPMN properties for now.

This gives already some clarity on which parts can easily be reused, which things have to be added (zeebe moddle descriptors, custom properties), and which things need to be refactored later (making template properties groups reusable to prevent duplications).

Looking forward to the descriptors to be added 👍

[nikku]

@pinussilvestrus I was wondering: What is our take on modelerTemplate and modelerTemplateVersion properties which are currently in the Camunda Platform namespace?

Shall these remain in the platform namespace? Shall these move to the modeler-moddle or camunda-cloud namespace?

[pinussilvestrus]

I thought about this one and would probably go for adding these in zeebe-bpmn-moddle as well, having it in both worlds. Because

a) removing them from camunda: namespace would mean a breaking change for older templates, and we would need to come up with a migration strategy. That's doable for sure, but maybe not necessary.
b) keeping camunda:only and using them in the C8 editor would follow in mixed namespaces, I think we should avoid it.

If we decide to have it in both namespaces, we have to handle these carefully, since some things are tightly coupled. Tbh, I don't like these properties as they are - namewise, but also that they stick to camunda: - but due to being compatible in the future, I'd probably keep things simple.

[pinussilvestrus]

That's obviously up for discussion, I did not make a decision for myself yet 🙂

[nikku]

I thought about this one and would probably go for adding these in zeebe-bpmn-moddle as well

👍 for that.

[nikku]

Added sketch of first element template needed via https://github.com/camunda/example-invoice-connectors/pull/8.

[nikku]

Contributed initial REST connector via https://github.com/camunda/example-invoice-connectors/pull/8.

[pinussilvestrus]

After chatting with @MaxTru we decided that we will de-scope the optional property for inputs & outputs since it is not a hard requirement for the first iteration. We'd rather bring the bindings support out of the door (cf. #555), and build further features in a constructive manner.

I created a separate issue to track this: #559