Camunda javascript set variable

Script tasks

A script task is used to model the evaluation of a script; for example, a script written in Groovy, JavaScript, or Python.

Camunda Platform 8 supports alternative task implementations for the script task. To use your own implementation for a script task, see the job worker implementation section below. The sections before this job worker implementation apply to the FEEL expression implementation only.

When the process instance arrives at a script task, the integrated FEEL Scala engine evaluates the script task FEEL expression. Once the FEEL expression is evaluated successfully, the process instance continues.

If the FEEL expression evaluation is unsuccessful, an incident is raised at the script task. When the incident is resolved, the script task is evaluated again.

Defining a script task​

To define a script task with an inline FEEL expression, use the zeebe:script extension element. In the zeebe:script extension element, perform the following steps:

1. Define the FEEL expression inside the expression attribute.
2. Define the name of process variable in the resultVariable attribute. This variable will store the result of the FEEL expression evaluation.

Variable mappings​

By default, the variable defined by resultVariable is merged into the process instance. This behavior can be customized by defining an output mapping at the script task.

All variables in scope of the script task are available to the FEEL engine when the FEEL expression in the script task is evaluated. Input mappings can be used to transform the variables into a format accepted by the FEEL expression.

Input mappings are applied on activating the script task (or when an incident at the script task is resolved) before the FEEL expression evaluation. When an incident is resolved at the script task, the input mappings are applied again before evaluating the FEEL expression. This can affect the result of the FEEL expression evaluation.

For more information about this topic, visit the documentation about input and output variable mappings.

Job worker implementation​

When the job worker implementation is used, script tasks behave exactly like service tasks. Both task types are based on jobs and job workers. The differences between these task types are the visual representation (i.e. the task marker) and the semantics for the model.

When a process instance enters a script task using a job worker implementation, it creates a corresponding job and waits for its completion. A job worker should request jobs of this job type and process them. When the job is complete, the process instance continues.

Jobs for script tasks are not processed by Zeebe itself. To process them, provide a job worker.

Defining a job worker script task​

A script task must define a job type the same way a service task does. It specifies the type of job workers should subscribe to (e.g. script ).

Use task headers to pass static parameters to the job worker (e.g. the script to evaluate). The community extension Zeebe Script Worker requires certain attributes to be set in the task headers.

Define variable mappings the same way a service task does to transform the variables passed to the job worker, or to customize how the variables of the job merge.

Additional resources​

Review the Zeebe Script Worker. This is a community extension that provides a job worker to evaluate scripts. You can run it, or use it as a blueprint for your own job worker.

XML representation​

A script task with a custom header:

bpmn:scriptTask id="calculate-sum" name="Calculate sum"> bpmn:extensionElements> zeebe:taskDefinition type="script" /> zeebe:taskHeaders> zeebe:header key="language" value="javascript" /> zeebe:header key="script" value="a + b" /> zeebe:taskHeaders> bpmn:extensionElements> bpmn:scriptTask> 

A script task with an inline FEEL expression:

bpmn:scriptTask id="calculate-sum" name="Calculate sum"> bpmn:extensionElements> zeebe:script expression="=a + b" resultVariable="sum" /> bpmn:extensionElements> bpmn:scriptTask> 

References​

Источник

Script Task

A Script Task is an automated activity. When a process execution arrives at the Script Task, the corresponding script is executed.

A Script Task is defined by specifying the script and the scriptFormat.

  sum = 0 for ( i in inputArray ) 

The value of the scriptFormat attribute must be a name that is compatible with JSR-223 (Scripting for the Java Platform). If you want to use a (JSR-223 compatible) scripting engine, you need to to add the corresponding jar to the classpath and use the appropriate name.

The script source code has to be added as the text content of the script child element. Alternatively, the source code can be specified as an expression or external resource. For more information on the possible ways of providing the script source code please see the corresponding section of the User Guide.

For general information about scripting in the process engine, please see the Scripting section of the User Guide.

Supported Script Languages

Camunda Platform should work with most of the JSR-223 compatible script engine implementations. We test integration for Groovy, JavaScript, JRuby and Jython. See the Third Party Dependencies section of the User Guide for more details.

Variables in Scripts

All process variables that are accessible through the execution that arrives in the Script Task can be used within the script. In the example below, the script variable inputArray is in fact a process variable (an array of integers).

 sum = 0 for ( i in inputArray ) 

It’s also possible to set process variables in a script. Variables can be set by using the setVariable(. ) methods provided by the VariableScope interface:

Enabling auto-storing of Script Variables

By setting the property autoStoreScriptVariables to true in the process engine configuration, the process engine will automatically store all global script variables as process variables. This was the default behavior in Camunda Platform 7.0 and 7.1 but it only reliably works for the Groovy scripting language (see the Set autoStoreScriptVariables section of the Migration Guide for more information).

To use this feature, you have to

• set autoStoreScriptVariables to true in the process engine configuration
• prefix all script variables that should not be stored as script variables using the def keyword: def sum = 0 . In this case the variable sum will not be stored as process variable.

Groovy-Support only

The configuration flag autoStoreScriptVariables is only supported for Groovy Script Tasks. If enabled for other script languages, it is not guaranteed which variables will be exported by the script engine. For example, Ruby will not export any of the script variables at all.

Note: the following names are reserved and cannot be used as variable names: out , out:print , lang:import , context , elcontext .

Script Results

The return value of a Script Task can be assigned to a previously existing or to a new process variable by specifying the process variable name as a literal value for the camunda:resultVariable attribute of a Script Task definition. Any existing value for a specific process variable will be overwritten by the result value of the script execution. When a result variable name is not specified, the script result value gets ignored.

In the above example, the result of the script execution (the value of the resolved expression # ) is set to the process variable named myVar after the script completes.

Result variables and multi-instance

Note that when you use camunda:resultVariable in a multi-instance construct, for example in a multi-instance subprocess, the result variable is overwritten every time the task completes, which may appear as random behavior. See camunda:resultVariable for details.

Camunda Extensions

Attributes	camunda:asyncBefore, camunda:asyncAfter, camunda:exclusive, camunda:jobPriority, camunda:resultVariable, camunda:resource
Extension Elements	camunda:failedJobRetryTimeCycle, camunda:inputOutput
Constraints	The camunda:exclusive attribute is only evaluated if the attribute camunda:asyncBefore or camunda:asyncAfter is set to true

On this Page:

We are looking for talented people.

Check out our open positions.

camunda.org and docs.camunda.org are part of Camunda Platform | Built by camunda and contributors — Privacy Statement — camunda Services GmbH © 2023

The content on this site is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Источник