Support for BPMN Script Tasks

[saig0]

Is your feature request related to a problem? Please describe. I want to calculate an expression in my workflow and store the result in a workflow instance variable. The expression is simple and does not represent essential or complex business logic.

Describe the solution you'd like

• the expression is evaluated in the Zeebe broker itself without providing an additional job worker
• the expression language is FEEL, like for the other attribute expressions
• the expression is represented in the workflow as BPMN script task

Describe alternatives you've considered

• having an additional job worker to evaluate the expression (e.g. Zeebe-Script-Worker)

Additional context Calculating an expression and storing the result in a variable is already possible using input/output variable mappings. But putting the expression is a script task can improve the visibility of the workflow.

[github-actions[bot]]

This issue has been awaiting more information for at least two weeks and has been marked as stale, and will be closed in two weeks if it is not updated.

[sumiranphq]

Looking forward to this feature. which release would this be targeted to ?

[saig0]

@sumiranphq: It is not planned for a release yet. The stakeholders need to decide if and when do we want to build this - also, depending on the user feedback :)

[npepinpe]

I would close this for now, as we currently support deploying processes with script tasks. What we don't have is script execution, and I don't see this coming for now as we use Zeebe as the backbone of Camunda Cloud, and remote execution of third party code would be a major security concern. I could imagine having this feature behind a feature flag to easily disable it in a SaaS environment, but we also don't have the infrastructure for feature flags for BPMN symbols right now.

Let me know if you think otherwise :+1:

[saig0]

remote execution of third party code would be a major security concern

I disagree with this point. The described solution suggests executing only FEEL expressions in script tasks. FEEL doesn't allow calling arbitrary code (like in a sandbox). We use FEEL already for evaluating other expressions.

I see that we will not work on it in the near future. However, I think it is still a valid feature request.

[npepinpe]

That's a fair point. If we stick to FEEL, then I'd be happy to receive a PR for this.

[skayliu]

Hi,@saig0, I'm trying to define the Script Tasks with Headers like below, Is this ok?

"language" stick to "feel" "inlineScript" stick this key to evaluated in the Zeebe broker itself. "resultVariable" stick this key to set evaluated result output

Bpmn.createExecutableProcess(PROCESS_ID)
                .startEvent()
                .scriptTask(
                    "scriptTaskId",
                    b ->
                        b.zeebeJobType("type")
                            .zeebeTaskHeader("language", "feel")
                            .zeebeTaskHeader("inlineScript", "today()")
                            .zeebeTaskHeader("resultVariable", "resultVariable"))
                .endEvent("end")
                .done()

[saig0]

@skayliu not exactly. From the implementation, a script task would be similar to a business rule task.

By default, the task is implemented as a job worker with a job type. But the task can switch the "implementation". If other properties are set then the task behaves differently.

If a business rule task has an extension element with a reference to a DMN decision (i.e. zeebe:calledDecision) then the business rule task evaluates a DMN instead. See BusinessRuleTaskTransformer and BusinessRuleTaskProcessor.

We could apply the same for the script task. If the script task has an extension element zeebe:script then it evaluates the FEEL expression (attribute expression) and stores the result in the variable (attribute resultVariable).

The expression language doesn't need to be set because it will always be FEEL.

[skayliu]

Hi, @saig0, I'd like to take this one, I'll need to make two PR, one for the bpmn model api and another for the engine.

[saig0]

@skayliu sounds good. :+1: Go for it. :rocket: