Add ability to create optional inputs & outputs via cloud element templates

[pinussilvestrus]

Is your feature request related to a problem? Please describe

The way element templates work is that properties are persisted in the XML in all cases, although they could be empty (cf. #501). For the newly added element templates support (cf. #540) for zeebe:input & zeebe:output I want to prevent having empty parameters, to ensure they don't have effects on the execution engine.

Describe the solution you'd like

Add the possibility to mark a zeebe:input or zeebe:output property as optional. E.g.

[
  {
    "name": "REST Connector",
    "id": "io.camunda.connectors.RestConnector-s1",
    "description": "A generic REST service.",
    "appliesTo": [ "bpmn:ServiceTask" ],
    "properties": [
      {
        "label": "Request Body",
        "value": "",
        "type": "String",
        "optional": true,
        "binding": {
          "type": "zeebe:input",
          "name": "body"
        }
      },
      {
        "label": "Result Variable",
        "value": "response",
        "type": "String",
        "optional": true,
        "binding": {
          "type": "zeebe:output",
          "source": "= body"
        }
      }
    ]
  }
]

When the input field is then configured as empty, it should not persist in the resulting XML. We have to make sure it works alongside existing template configurations (or permit them via JSON Schema)

• optional = true and value != null (default value is defined, what happens after I deleted the value via UI?)
• optional = true and constraints.notEmpty = true
• optional = true and editable = false

Describe alternatives you've considered

We have something similar in Camunda Platform (C7) for output parameters, where we handled this via toggle switch. This doesn't work in a generic fashion though / with simple custom fields.

Additional context

Related to #501
Related to #540

Child of camunda/camunda-modeler#2640

[pinussilvestrus]

optional = true and value != null (default value is defined, what happens after I deleted the value via UI?)

What I would expect here is
1 - Define an element templates with a zeebe:input, optional = true and value = 'foo' (default value)
2 - Apply element template --> input parameter gets created with source = 'foo', UI shows 'foo' as value
3 - User removes value in UI --> input parameter gets removed from XML (empty value)
4 - UI does not show the defined default value on empty (as it is now), but leave it empty

[nikku]

@pihme @pinussilvestrus I can confirm that optional is required to make our connectors story fly. Empty / unbound inputs are rejected by the engine on deployment => We need to ensure we don't add them, unless non-empty.

Specifically the following configuration on a service task is being rejected by the engine:

Generated by an element template we must ensure it is possible to not add the input, unless filled in.

[pinussilvestrus]

Thanks, @nikku for reporting 👍 I think we should give this one a higher priority then.

Furthermore, empty zeebe:input elements might also be interesting for our implementation linting investigations.

/cc @MaxTru @philippfromme

[philippfromme]

Agreed. ✅ Optional properties like zeebe:Input must not be added unless they're supposed to be present in the XML. We always lint a BPMN diagram as-is, meaning we lint what would be exported at that point in time.

[nikku]

Optional properties like zeebe:Input must not be added unless they're supposed to be present in the XML. We always lint a BPMN diagram as-is, meaning we lint what would be exported at that point in time.

So what you're saying is that linting for zeebe:input (https://github.com/bpmn-io/internal-docs/issues/435) would just work out of the box. Broken "empty" inputs would just not be serialized; and if they were, that is a clear user error.

[philippfromme]

Yes, no changes should be necessary from the linting side of things.