Condition based on context value

[sbuettner]

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

There are cases where we need to enable/disable properties based on external information depending on the environment.

One for example doesnt want to create separate element-templates based on the environment where a template should be used (execution platform version or product context) but rather provide the element template engine a context that can be used to conditionally enable/disable certain properties and features in a single element-template.

Examples:

• A property that should only be shown if the element-template is applied in a Self-Managed Web-Modeler instance and not in the SaaS environment.
• A property is valid only in the context of a particular execution platform version

These cases are currently (i.e. in the case of the AWS SQS connector) handled using the labels by indicating whether an option is available or not.

Describe the solution you'd like

It would be really handy to be able to pass a context variable into the element-template engine and use this context inside a condition.

Describe alternatives you've considered

The alternative is using a single template and label options and properties that should not be considered in certain cases or to use different element templates for each environment (which leads to a lot of duplication)

Additional context

This feature could also be useful in case of when dealing with sub-processes where the engine requires context whether a single element is part of a subprocess or not.

---

Related to Element Template Run-time Version.

[nikku]

This could be an interesting addition to element template conditional bindings! Is there any concrete initiative/use-case on your end that this relates to?

[sbuettner]

@nikku Another use-case for conditions based on context value is versioning. By having the execution platform version information available in the context, we would be able to enable/disable certain functionality depending on it.

[nikku]

By having the execution platform version information available in the context, we would be able to enable/disable certain functionality depending on it.

What specific feature do you think about, and what would happen during an upgrade from one engine version to another?

The usual way we handle "version conflicts" is through validation / linting.

[sbuettner]

@nikku The idea was to only offer/support certain properties based on the execution platform.

[nikku]

@nikku The idea was to only offer/support certain properties based on the execution platform.

And what would happen if the platform changed? Would elements magically upgrade? That is a general question we need to ask ourselves if we consider context for the applicability of an element template.

[nikku]

@sbuettner Could you link a connector that ships with the UI presented above?

[sbuettner]

The AWS Connectors come with the self-managed only property: https://github.com/camunda/connectors/blob/main/connectors/aws/aws-sqs/element-templates/aws-sqs-outbound-connector.json#L54

Regarding the execution platform: We have the case where a newer Slack Connector supports some features that are not present in an older runtime but we have to support both in the web-modeler. Thats where the idea of having access to execution platform information comes from.

[nikku]

Regarding the execution platform: We have the case where a newer Slack Connector supports some features that are not present in an older runtime but we have to support both in the web-modeler. Thats where the idea of having access to execution platform information comes from.

Why not solve the issue using our on board facilities, cf. screenshot below:

[sbuettner]

Because we want to offer a tailored experience and hide operations that are not supported instead of showing them and requiring the user to (and us) to leverage the problems panel. It can be a single property that is just not available in an older version for example. The logic would be encapsulated inside the element template and not spread into the linting.

[nikku]

Thanks! I think I understood now.

Building your own solution for "version compatibility" of course (rather than plugging into the existing capability). That however will mean that you'll also need to solve everything including upgrading (what happens when the "context" changes) yourself. Also, it will contradict our way of guiding the user, as the UX will be inconsistent.

Moving to backlog for now. Let's see if there is further evidence for contextual application of element templates in the future.

[sbuettner]

solve everything including upgrading (what happens when the "context" changes)

When a user changes the execution platform in the modeler the context would change and the conditions in the element template would be re-evaluated.

[nikku]

solve everything including upgrading (what happens when the "context" changes)

When a user changes the execution platform in the modeler the context would change and the conditions in the element template would be re-evaluated.

Magically, for all elements I presume, or giving folks a heads-up that updates are being applied to the diagram, with a list of the changes? What happens with existing configuration if I downgrade? The existing flow offers answers for all these questions, whatever we build "our own" in connectors needs to check the boxes, too.

Exactly because we encourage no surprises we go for validation for execution platform compatibility over showing and hiding things (and binding and un-binding of technical properties in the element template case). In the sense I'd invest into better hooking up connectors to the existing validation infrastructure, because it works out of the box locally (per element) but also globally (per diagram, potentially per project / process application).

[sbuettner]

In general the changes should be forward compatible and I dont see many use-cases for people downgrading.
In case you downgrade and functionality is not available you would not be able to use the data anyway for options not available.

Beside that a context could be used to provide validations as well in case one doesnt want to use it for hiding/diplay purposes.