Simplify injection of static values via zeebe:input

[nikku]

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

As a user I'm happily automating my processes with Zeebe. What I already understood is that Zeebe has a clear way of distinguishing expressions (= someVariable) from static values (strings, HELLO WORLD).

What I also understood is that headers shall be used for "static configuration". Inputs on the other hand shall be used to (dynamic) variable binding.

As a matter of fact though variables can also be of "static" nature. I.e. as a user I build an email worker, require the PORT to be passed in as a variable. I do not want to have that variable in my process; I simply want to set it up in the easiest possible manner and want my team to use it.

So in order to provide that static PORT=25 value I need to specify the input using a =25 expression. What I wanted to do instead is to simply enter 25 (what would pass the result to my worker as the string "25". Intuitively I thought that simple conversion was supported, it is for messages.

Camunda Modeler + example diagram.

Bottom line: As zeebe already has a clear understanding if I pass an expression = ABC or not (not prefixed with =) it does not make sense why it would not be forgiving to me as a user.

Describe the solution you'd like

The engine uses = to determine if an input is an expression, if INPUT is not prefixed with = it will simply provide INPUT as a string.

In other places, i.e. messages it exactly works like this.

Describe alternatives you've considered

In a world where I as a user have full understanding of zeebe internals and/or can clearly distinguish I can freely switch between inputs and headers; so accepting the situation would be an option.

In the world of element templates and re-usable worker implementations (i.e. email or rest task) we'd always need to prefix everything, even plain strings with =. It does make things explicit but also requires users to learn more things as they get started automating with zeebe.

Additional context

This came up in the context of improved feel expression editing support as well as connectors.

[nikku]

cc @currandwyer

[npepinpe]

Makes sense to me 👍 I'm happy to receive a PR for this, or maybe someone (@felix-mueller ?) can clarify whether this is required for the connectors topic and within which time frame.