Skript-Aktionen

Grundlagen

Serverseitige Skript-Aktionen sind eines der mächtigsten Werkzeuge in CURSOR-BPM, um individuelle Aktionen zu definieren.

Eine Skript-Aktion kann auf alle Prozess-Variablen zugreifen, über Hilfsklassen (z. B. WorkSpaceScriptUtils, ProcessUtils, ScriptUtils) Daten im CRM lesen und schreiben und neue Prozess-Variablen erzeugen, die in späteren Prozessschritten weiterverwendet werden können.

Eine Liste der verwendbaren Befehle und Funktionen sind in Einstiegsfunktionen BPM, Skript-Befehle und Skript-Konstanten aufgeführt.

Ausführungsrechte für Skript-Aktionen

Standardmäßig werden Skript-Aktionen mit den Rechten des zuletzt ausführenden Benutzers im Prozess ausgeführt.

Müssen Skript-Aktionen mit abweichenden Rechten laufen (z. B. Neuanlage von Datensätzen, für die der Mitarbeiter keine Berechtigung hat), kann in der Konfiguration der Skript-Aktion explizit ein anderer Benutzer angegeben werden.

Ausführen als technischer Benutzer

Im Feld „Ausführen als“ können Sie einen technischen Benutzer hinterlegen.
Voraussetzungen:

1. Es existiert ein Mitarbeiterdatensatz mit den gewünschten Rechten.

2. Dieser Mitarbeiter ist als technischer Benutzer gekennzeichnet (TechnicalUser.Employee = true).

Alternativ können Sie auch:

• eine Prozessvariable vom Typ Primärschlüssel verwenden (z. B. ${memberPk}), in der der PK des technischen Mitarbeiters steht,

• oder eine in der Prozessbibliothek verknüpfte globale Variable vom Typ Primärschlüssel.

Auswirkungen:

• Datenoperationen werden im CRM mit dem Kürzel des technischen Benutzers protokolliert (UpdateUser).

• E-Mails, die aus der Skript-Aktion heraus versendet werden, nutzen die E-Mail-Konfiguration dieses technischen Benutzers.
  → Die entsprechende E-Mail-Konfiguration muss im Mitarbeiterdatensatz hinterlegt sein.

Skript-Editor

Siehe hierzu den Artikel zum Abbildung von Logiken (Scripting).

Prozess-Variablen

Prozess-Variablen stehen dem Skript direkt unter dem Namen zur Verfügung, unter dem sie im Prozess definiert wurden.
Sie sind:

• im gesamten Prozess unter diesem Namen sichtbar,

• in allen Skript-Aktionen, UserTasks und in Sequenzflüssen mit Bedingungen nutzbar.

Beispiel: Übergabe von Variablen beim Prozessstart (Masken-Skript)

CODE

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

Die Variable var1 wurde beim Start als Parameter übergeben und ist im Groovy-Skript direkt verfügbar.
Alternativ kann sie über den Prozess-Kontext gelesen werden:

String v = ProcessUtils.getVariable("var1");

Beispiel: Zugriff in Skript 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);
}

// Neue Prozessvariable setzen
ProcessUtils.setVariable("var2", "value2");

var2 ist ab jetzt in allen nachfolgenden Prozessschritten verfügbar.

Beispiel: Zugriff in Skript Task 1

CODE

String v1 = ProcessUtils.getVariable("var1");
String v2 = ProcessUtils.getVariable("var2");

// var1 und var2 stehen auch direkt im Skript zur Verfügung
if (v1.equals(var1) && v2.equals(var2)) {
    // v1 und var1 sind identisch, ebenso v2 und var2
    ScriptUtils.info("var1 " + var1);
    ScriptUtils.info("var2 " + var2);
}

// Wichtig: var2 wird hier 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);

Wichtig:

• Lokale Variablen (z. B. var2 im Skript) überschreiben gleichnamige Prozessvariablen nur innerhalb des Skripts.

• Eine Änderung wird nur dann im Prozess „global“ sichtbar, wenn ProcessUtils.setVariable("var2", var2) aufgerufen wird.

Empfehlung: Prozess-Variablen vorab definieren

Damit:

• die Schreibweise von Variablennamen einheitlich bleibt und

• die Autovervollständigung im Skript-Editor greift,

sollten Sie Prozess-Variablen vorab in der Bibliothek definieren.

Reservierte Variablennamen

Einige Variablennamen sind bereits durch das System belegt und dürfen nicht für eigene Prozess-Variablen verwendet werden:

• 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

Sichtbarkeit von Variablen

Mit ProcessUtils.setVariable() definierte Variablen sind global im Prozess sichtbar:

• in allen nachfolgenden Skript-Aktionen,

• in UserTasks,

• in Sequenzflüssen (z. B. für Bedingungen).

Prozessvariablen können fast alle Datentypen annehmen, mit einer wichtigen Ausnahme:

• Objekte vom Typ IScriptingWorkSpace dürfen nicht als Prozessvariable verwendet werden.

Hintergrund

Ein IScriptingWorkSpace (z. B. ermittelt durch WorkSpaceScriptUtils.search()) ist nur in der aktuellen Skript-Aktion gültig. Im globalen Prozesskontext ist eine solche Variable leer.

Damit wird verhindert, dass prozessschrittübergreifende Schreibsperren im Workspace bestehen bleiben.

Weiterverarbeitung von Suchergebnissen

Wenn Sie Ergebnisse suchen und in mehreren Schritten lesend weiterverwenden möchten, nutzen Sie WorkSpaceScriptUtils.searchForRead(). So können Sie Daten ohne Schreibkontext (und ohne Sperren) auswerten.

Validierung

Für eine saubere Verarbeitung insbesondere im Zusammenhang mit Update-Konflikten zwischen Prozess- und CRM-Daten ist der korrekte Einsatz von WorkSpaceScriptUtils.saveEntry() wichtig.

Korrekte Verwendung von saveEntry

Das Ergebnis von saveEntry muss der verwendeten Container-Variable wieder zugewiesen werden:

CODE

container = WorkSpaceScriptUtils.saveEntry(workSpace, container);

Nur so ist sichergestellt, dass Sie mit dem aktualisierten Container weiterarbeiten.

Häufige Skriptausführung

Um unkontrollierte oder fehlerhafte Prozessabläufe zu erkennen, überwacht CURSOR-BPM, wie häufig dieselbe Skript-Aktion ausgeführt wird. Wird eine Skript-Aktion auffällig oft innerhalb kurzer Zeit durchlaufen, wird dies als Problem im Prozess-Log vermerkt.

Es gibt legitime Fälle, in denen eine hohe Ausführungsfrequenz erwünscht ist (z. B. Schleifen, Polling-Prozesse). Für solche Prozesse können Sie eine Anwendungsvariable definieren, über die Sie die Log-Schwelle für „zu häufige Ausführung“ anpassen.