Skip to main content
Skip table of contents

Script task

Script task

Server-side script tasks are a powerful tool in CURSOR-BPM for defining the various actions.

A script task has access to all variables in the process. Data can be analyzed and new data in the CRM system can be manipulated via utility classes. Additionally, new process variables can be generated for later use.

Execution rights for script tasks

Script tasks are generally executed using the rights of the last executing user in the process.

An explicit rights assignment can be done if a script task must be executed with other rights. Use case scenario: the last executing employee has no rights assigned for the creation of new datasets and that is exactly what the script task is supposed to do. Select a technical user in the field Execute as in the configuration of the script task. Employee datasets with the required rights must be created and marked as technical users (entity field: TechnicalUser.Employee).

Figure: "Execute script action as"

Primary key variables (in the example ${memberPk}) of the process are also available for selection. The primary key of the technical employee must be stored in this variable. In addition, linked global variables of the type primary key are also available in the process library.

The data operations of the relevant script tasks are then saved with the token of the technical user (UpdateUser). Emails are similarly sent with the configuration of the technical user, which requires a relevant configuration in the employee dataset.

For your convenience, detailed documentation about auto completion is provided in the script editor:

Process variables

Process variables are available for the script under the name they were created in the process. They are available under that name throughout the process and can be used in all scripts (script task or user task) and in other locations, e.g. sequence flows with decisions.

Mask script
CODE
HashMap variables = new HashMap();
variables.put("var1", "value1");
startProcess("process", variables);

var1 is added to the process as a parameter at the start. It can be accessed directly in the Groovy script. Alternatively, it can also be read via ProcessUtils.getVariable() from the process context.

Script task 2
CODE
String value1 = var1; //var1 steht direkt im Skript zur Verfügung
String value1a = ProcessUtils.getVariable("var1");
if(value1.equals(value1a )) //value1 und value1a sind identisch
{
	ScriptUtils.info("value1: " + value1 + ", value1a: " + value1a);
}
ProcessUtils.setVariable("var2", "value2");

var2 is also available in the next script.

Script task 1
CODE
String v1 = ProcessUtils.getVariable("var1");
String v2 = ProcessUtils.getVariable("var2");

//var1 und var2 sind direkt im Skript verfügbar
if(v1.equals(var1) && v2.equals(var2)) 
{
	//v1 und var1 sind identisch, ebenso wie v2 und var2
	ScriptUtils.info("var1 " + var1);
	ScriptUtils.info("var2 " + var2);
}

//Wichtig: var2 wird lokal im Skript überdeckt
var2 = "neuer Wert"; 
//Wichtig: ohne das Setzen der Variable in den Prozess-Kontext ist die Änderung nach dem Prozess-Schritt nicht sichtbar
//ProcessUtils.setVariable("var2", var2);

You should always create variables in the process container beforehand to ensure that the correct notation of the variable is system-supported.

Please note that some variable names are reserved and can therefore not be used for your variable definition:

  • SessionConstants

  • START_USER, CURRENT_USER_PK, CURRENT_USER_SHORTCUT

  • eventName

  • entityName

  • container, container_New, container_Old

  • workSpace, positionInWorkSpace, changeInfo

  • insertConfig, copyConfig, relationCreateConfig

  • relationName, relationMetaData, relationAttributes

  • masterPk, slavePk, masterTable

  • containers_Add, containers_Remove

  • parameter

  • rightIdentifier

  • ProcessID

  • NewMail

Variable visibility

A call-up of ProcessUtils.setVariable() makes variables available across the entire process. They will be available in all subsequent script tasks, user tasks and sequence flows. Process variables can represent almost any data type with the exception of the IScriptingWorkSpace class. If an object of the IScriptingWorkSpace class is determined by the call-up of WorkSpaceScriptUtils.search(), then this can only be used in the current script task. This variable will remain empty in the global process. That will prevent the setting of any cross-process step write blocking. A further processing of the search results can only be done in read mode. That is offered by the WorkSpaceScriptUtils.searchForRead() method.

Find & replace

In order to easily replace texts in the script, the Find & replace dialog can be opened using the CTRL+F key combination.

Validation

It is important for the method WorkSpaceScriptUtils.saveEntry to be used correctly as part of the check for update conflicts between process and CRM data. The container variable used must be assigned to the result container.

CODE
container = WorkSpaceScriptUtils.saveEntry(workSpace, container)

You can also start the script validation via the button "Validating process scripts" in the toolbar. This check will be carried out automatically during the update to version 15.1. Any BPM scripts that need adjustment will be listed in the update log.

Auto complete

An auto complete function is available for entities and fields from the data model (just like for the methods).

Frequent script execution

To detect uncontrolled execution of processes, frequent execution of the same script action is reported as a problem in the process log

There are processes that require frequent execution. For this purpose, an application parameter can be created for this process in order to adjust the log threshold there.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.