Die System-Skriptsprache wird u. a. im Workflow-Management verwendet, um z. B. eine Vorbedingung oder Übergangsbedingung zu formulieren oder um Bearbeiter zu ermitteln, die nicht in einer Workflowrolle zusammengefasst sind.

Die Workflow-Engine unterstützt sowohl die eigene System-Skriptsprache als auch JavaScript, um komplexe Zusammenhänge auszudrücken. In dieser Dokumentation erhalten Sie ausführliche Informationen zu den einzelnen Workflow-Funktionen der System-Skriptsprache. Workflow-Funktionen sind Funktionen, deren Verwendungskontext eine Aktivitätsdefinition voraussetzen. Workflow-Funktionen, die das Vorhandensein einer Aktivität voraussetzen, können nicht in Übergangsbedingungen verwendet werden, da zum Zeitpunkt der Auswertung der Übergangsbedingung die Aktivität noch nicht erzeugt ist. Beispiele von Workflow-Funktionen sind setActivityWorkDuration und setActivityPriority, die beim Erzeugen einer Workflow-Aktivität die Bearbeitungsdauer bzw. Priorität bestimmen.

Die Beispiele in diesem Dokument dienen dem Verständnis dafür, wie die Funktionen und Befehle der System-Skriptsprache verwendet werden können. Um die Beispiele in anderen Verwendungskontexten einzusetzen, müssen sie ggf. angepasst werden. Dieses Dokument umfasst auch Beispiele für Funktionen, die nicht Bestandteil der System-Skriptsprache sind. In diesem Fall weisen die Beispiele auf Möglichkeiten hin, wie mithilfe der System-Skriptsprache die gleiche oder eine ähnliche Funktionalität erreicht werden kann.

Zielgruppe

Die Zielgruppe dieses Dokuments besteht aus Entwicklern und technischen Beratern, die Workflows bei Kunden erstellen oder anpassen, sowie Kunden, die eigene Workflows verwalten.

Für dieses Dokument wird das Verständnis des für den Benutzer sichtbaren Funktionsumfangs des Workflow-Managements vorausgesetzt. Weiterhin sollte der Leser zum Verständnis der System-Skriptsprache grundlegende Kenntnisse in SQL oder einer beliebigen Programmiersprache haben.

Begriffsbestimmung

• Aktivitätsdefinition – Aktivitätsdefinitionen legen fest, ob beim Auftreten eines bestimmten Ereignisses eine Aktivität erzeugt werden soll und welche Merkmale diese Aktivität haben soll. Eine Aktivitätsdefinition muss aktiviert sein. Wenn das der Fall ist, dann erzeugt die Workflow-Engine beim Auftreten des dort angegebenen Ereignisses eine neue Aktivität, sofern die Übergangs- und Vorbedingung erfüllt sind. Alle für die Aktivität notwendigen Daten werden aus der Aktivitätsdefinition berechnet. Die Aktivitätsdefinition stellt somit die Vorlage für die aus ihr erzeugten Aktivitäten dar. Aktivitätsdefinitionen sind unabhängig von der OLTP-Datenbank und dem System, in dem sie erfasst wurden, da sie weder System- noch OLTP-spezifische Daten enthalten. Aktivitätsdefinitionen werden in der Repository-Datenbank abgelegt.
• Deklarationen – Deklarationen sind Skripte in den Prozessdefinitionen und Aktivitätsdefinitionen, die Methoden zur Verfügung stellen, welche beim Erzeugen von Aktivitäten, bei Statuswechseln und bei der Eingabe von bestimmten Parameterwerten aufgerufen werden. Durch Anpassung der Deklarationen lassen sich die Eigenschaften von Prozessen und Aktivitäten flexibel festlegen. Deklarationen werden in einer Skriptsprache erfasst.
• GUID – GUID ist die Abkürzung für Globally Unique Identifier und entspricht einem „Global eindeutigen Bezeichner”. Eine GUID ist eine 128-Bit Zahl, die nach dem Schema der Open Software Foundation (OSF) für verteilte Berechnungen (Distributed Computing Environment, DCE) berechnet wurde. Sie enthält u. a. die IP-Adresse der erzeugenden Rechner, eine Zeit-Komponente und eine Zufalls-Komponente. So können zwei unabhängige Rechner ohne Synchonisation immer unterschiedliche GUIDs berechnen. In Comarch ERP Enterprise werden GUIDs als Java-Byte-Arrays der Länge 16 repräsentiert und vor allem als kompakte Primär- und Fremdschlüssel in Business Objects verwendet.
• System-Skriptsprache – Terme, Bedingungen, Befehle, Funktionen und Deklarationen werden verwendet, um komplexe Zusammenhänge auszudrücken. Alle diese Ausdrücke sind Teil einer gemeinsamen Skriptsprache, die System-Skriptsprache genannt wird. Die Syntax der System-Skriptsprache lehnt sich an SQL, Pascal und Java an. Die System-Skriptsprache wird u. a. im Workflow-Management verwendet, um z. B. eine Vorbedingung oder Übergangsbedingung zu formulieren oder um Bearbeiter zu ermitteln, die nicht in einer Workflowrolle zusammengefasst sind.
• Workflow-Engine – Zusammen mit dem Ereignisdienst koordiniert und überwacht die Workflow-Engine die Ausführung von Workflows. Die Workflow-Engine wird in jedem System auf dem Message-Server ausgeführt.

Workflow-Funktionen

Workflow-Funktionen sind Funktionen, deren Verwendungskontext eine Aktivitätsdefinition voraussetzen. Workflow-Funktionen, die das Vorhandensein einer Aktivität voraussetzen, können nicht in Übergangsbedingungen verwendet werden, da zum Zeitpunkt der Auswertung der Übergangsbedingung die Aktivität noch nicht erzeugt ist. Dieses Dokument teilt die Workflow-Funktionen in folgenden Gruppen auf:

• Funktionen für Prozesse (Process functions)
• Funktionen für Aktivitäten (Activity functions)
• Funktionen für Bearbeiter (Editor functions)
• Funktionen für Aktivitätsergebnisse (Activity results functions)
• Funktionen für E-Mail-Nachrichten und E-Mail-Knoten (E-Mail functions)
• Funktionen für Service-Knoten (Service node functions)
• Funktionen für Webservice-Knoten
• Befehle für dynamische Indikatoren (Dynamic indicator commands)
• Funktionen für Cockpit-Anwendungen (Cockpit functions)

Funktionen für Prozesse (Process functions)

Zu den Funktionen für Prozesse gehören sowohl Befehle, welche die Eigenschaften des zu erzeugenden Prozesses festlegen, als auch Funktionen, um Eigenschaften abzufragen, die sich mithilfe der vorgegebenen Prozessparameter nur schlecht abfragen lassen:

• abortProcess
• processOwner
• setProcessWorkDuration

abortProcess

Folgendes Beispiel stammt aus dem Startknoten einer Prozessdefinition. Beim Löschen einer Instanz des Business Objects com.cisag.app.inventory.obj.UnitOnhandbricht die Prozesserzeugung ab, wenn nicht sämtliche Stellplätze des Lagerplatzes leer sind. Diese Prüfung wurde nicht nur aus Platzgründen aus der Übergangsbedingung in die Funktion createverlagert. Die Verlagerung vermeidet auch einen unnötigen Datenbankzugriff, wenn die Übergangsbedingung aufgrund weiterer Kriterien den Wert falsebesitzt.

function create()
{
/* if the storage location has more UnitOnhand then the location is not empty */
if (cast(Number, getResultList("SELECT COUNT(*) FROM com.cisag.app.inventory.obj.UnitOnhand uoh WHERE uoh:storageLocation = ?", 
list(parameters.oldObject:storageLocation), 1)[0][0]) > 0) {
abortProcess();
}
}

processOwner

var owners := processOwner();
for (u as Guid : owners) {
echo(userName(u));
}

Beispiel: processOwner

Folgendes Beispiel aus der Aktivitätsdefinition help.processOwner gibt die Guids aller Prozessverantwortlichen zurück.

function create()
{
const ProcessOwnerOrigin as valueSet(com.cisag.sys.workflow.ProcessOwnerOrigin);

var owners as Guid[];
var ownerNames as String;

var pd := getByBusinessKey("REPOSITORY", CisObject(com.cisag.sys.workflow.obj.ProcessDefinition), parameters.PROCESS_DEFINITION, parameters.ORIGIN);

if (definition->ProcessDefinition:processData.sourceOfOwner = ProcessOwnerOrigin.WORKFLOW_ROLE) {
if (not isNull(definition->ProcessDefinition:ownerRole))
owners := resolveRole(definition->ProcessDefinition:ownerRole);
}
else {
if (not isNull(definition->ProcessDefinition:owner))
owners := list(userGuid(definition->ProcessDefinition:owner));
}
for (u : owners) {
ownerNames := ownerNames + " " + userName(u);
}
result.OWNERS := trim(ownerNames);
}

setProcessWorkDuration

Funktionen für Aktivitäten (Activity functions)

Zu den Funktionen für Aktivitäten gehören vor allem Befehle, um die Eigenschaften der zu erzeugenden Aktivität festzulegen. Solche Befehle können nur in der Funktion createder Deklarationen verwendet werden.

• abort
• addAttachment
• formatDescription
• formatDescriptionHTML
• formatSubject
• primaryAttachment
• setActivityCategory
• setActivityPriority
• setActivityResult
• setActivityWorkDelay
• setActivityWorkDuration
• setSeriesDuration

abort

addAttachment

formatDescription

formatDescriptionHTML

Beispiel: Tabelle mit Hyperlinks in einer E-Mail-Nachricht

Folgendes Beispiel gibt die Artikelbezeichnung des Test-Artikels 10010 in allen aktiven Inhaltssprachen aus. Zunächst ermittelt die FunktiongetCisObjectListdie aktiven Inhaltssprachen. Danach wird der Test-Artikel einmal für jede aktive Inhaltssprache geöffnet, um die Bezeichnung in der jeweiligen Sprache zu ermitteln. Das Eregbnis wird als Zeile in einer HTML-Tabelle festgehalten. Mithilfe der Funktion getURL und eines Anchor-Tags in HTML wird die Artikelnummer als klickbarer Hyperlink in der Aktivitätsbezeichnung angezeigt.

function create()
{
/* item number of this example */
const ItemNumber := "10010";

/* get system and database names */
var systemName := getSystemName();
var databaseName := getDatabaseName();

/* get system and database Guid */
var system := getByBusinessKey("CONFIGURATION", CisObject(com.cisag.sys.configuration.obj.System), systemName, 1);
var database := getByBusinessKey("CONFIGURATION", CisObject(com.cisag.sys.configuration.obj.Database), system:guid, databaseName, 1);

/* query configuration database for active content languages */
var params as Unknown[];
add(params, database:guid);
add(params, 1); /* active version */
var activeLanguages := getCisObjectList("CONFIGURATION", "SELECT FROM com.cisag.sys.configuration.obj.DatabaseLanguage o WHERE o:databaseGuid = ? AND o:version = ?", params, 99);

/* build HTML table with one row for each content language */
var item as CisObject(com.cisag.app.general.obj.Item);
var url := getURL(loadItem(ItemNumber));
var htmlTable := "<table>" + char(13);
for (l as CisObject(com.cisag.sys.configuration.obj.DatabaseLanguage) : activeLanguages) {
setNLSContentLanguage(l:language);
item := loadItem(ItemNumber);
htmlTable := htmlTable + "<tr><td><a href=\"" + url + "\">" + item:number + "</a></td><td>" + l:language + "</td><td>" + item:description + "</td></tr>" + char(13);
echo(htmlTable);
}
htmlTable := htmlTable + "</table>";

/* format activity */
formatDescriptionHTML("table", htmlTable);
}

Um sich das Öffnen die beiden Business Objects Systemund Databasezu ersparen, könnte eine Aktivitätsdefinition des Typs Funktionsaufruf die Guid der Datenbank zurückgeben. Die Aktivitätsdefinition müsste in JavaScript erfasst werden und könnte wie folgt aussehen:

function create()
{
var db = Java.type('com.cisag.pgm.appserver.CisEnvironment').getInstance();
result.GUID = com.cisag.pgm.datatype.Guid.toHexString(db.getDatabaseGuid());
}

Die GUID wird über den Ergebnisparameter GUID zurückgegeben. Die Funktion createwürde würde dann wie folgt beginnen:

function create()
{
/* item number of this example */
const ItemNumber := "10010";


/* query configuration database for active content languages in the database */
var params as Unknown[];
add(params, @getDatabaseGuid().GUID;
add(params, 1); /* active version */
var activeLanguages := getCisObjectList("CONFIGURATION", "SELECT FROM com.cisag.sys.configuration.obj.DatabaseLanguage o WHERE o:databaseGuid = ? AND o:version = ?", params, 99);

formatSubject

primaryAttachment

setActivityCategory

setActivityPriority

setActivityResult

setActivityWorkDelay

setActivityWorkDuration

setSeriesDuration

Funktionen für Bearbeiter (Editor functions)

Zu den Funktionen für Bearbeiter gehören vor allem Funktionen, um die Bearbeiter mit Aufgaben eines bestimmten Status zu ermitteln. Diese Funktionen können z. B. verwendet werden, um Bearbeiter für eine Folgeaktion bei Zeitüberschreitung zu ermitteln:

• activeParticipants
• activeWorkers
• allParticipants
• allWorkers
• canceledWorkers
• closedWorkers
• currentParticipants
• currentWorkers
• doneWorkers
• forwardedWorkers
• overdueWorkers

activeParticipants

var users := activeParticipants();
for (u as Guid : users) {
echo(userName(u));
}

activeWorkers

var users := activeWorkers();
for (u as Guid : users) {
echo(userName(u));
}

allParticipants

var users := allParticipants();
for (u as Guid : users) {
echo(userName(u));
}

Beispiel: possibleParticipants

Folgendes Beispiel aus der Aktivitätsdefinition help.possibleParticipants gibt mögliche Bearbeiter aller Aktivitätsdefinitionen einer Prozessdefinition zurück.

function create()
{
const PerformerType as valueSet(com.cisag.sys.workflow.PerformerType);
const ProcessOwnerOrigin as valueSet(com.cisag.sys.workflow.ProcessOwnerOrigin);

var users as Guid[];
var userNames as String;

var pd := getByBusinessKey("REPOSITORY", CisObject(com.cisag.sys.workflow.obj.ProcessDefinition), parameters.PROCESS_DEFINITION, parameters.ORIGIN);
var OQL := "SELECT FROM com.cisag.sys.workflow.obj.ActivityDefinition ad WHERE ad:processDefinition = ?";
var adList := getCisObjectList("REPOSITORY", OQL, list(pd:guid), 100);

for (ad as CisObject(com.cisag.sys.workflow.obj.ActivityDefinition) : adList)
{
if (ad:data.performer.type = PerformerType.ROLE) {
users := union(users, resolveRole(ad:data.performer.guid));
}
if (ad:data.performer.type = PerformerType.USER) {
users := union(users, list(ad:data.performer.guid));
}
if (ad:data.performer.type = PerformerType.INITIATOR) {
users := union(users, list(userGuid("process.Initiator")));
}
if (ad:data.performer.type = PerformerType.OWNER) {
if (pd:processData.sourceOfOwner = ProcessOwnerOrigin.PROCESS_DEFINITION)
users := union(users, list(userGuid(pd:owner)));
if (pd:processData.sourceOfOwner = ProcessOwnerOrigin.WORKFLOW_ROLE)
users := union(users, resolveRole(pd:ownerRole));
}
}
for (u : users) {
userNames := userNames + " " + userName(u);
}
result.PARTICIPANTS := trim(userNames);
}

allWorkers

var users := activeWorkers();
for (u as Guid : users) {
echo(userName(u));
}

canceledWorkers

var users := canceledWorkers();
for (u as Guid : users) {
echo(userName(u));
}

closedWorkers

var users := closedWorkers();
for (u as Guid : users) {
echo(userName(u));
}

currentParticipants

var users := currentParticipants();
for (u as Guid : users) {
echo(userName(u));
}

currentWorkers

var users := currentWorkers();
for (u as Guid : users) {
echo(userName(u));
}

doneWorkers

var users := doneWorkers();
for (u as Guid : users) {
echo(userName(u));
}

forwardedWorkers

var users := forwardedWorkers();
for (u as Guid : users) {
echo(userName(u));
}

overdueWorkers

var users := overdueWorkers();
for (u as Guid : users) {
echo(userName(u));
}

Funktionen für Aktivitätsergebnisse (Activity results functions)

Die Funktionen für Aktivitätsergebnisse initialisieren die Elemente der Dialoge Aktivitätsergebnisse eingeben und Prozessparameter eingeben:

• formatEntityField
• formatSelectionField
• setResultFieldEditable
• setResultFieldVisible

formatEntityField

formatEntityField("partner", 
"com.cisag.app.sales:SalesOrderNumber.lt", 
hashMap(customerNumber := "10010", status:=2)

formatSelectionField

Beispiel: Benutzeraktion für ein Dependent

Ein Ereignis des Typs Benutzeraktion ist nur für Business Entitys möglich. Um einen Prozess auch für ein Dependent wie z. B. eine Vertriebsauftragsposition zu starten, wird das dynamische Auswahlfeld details mit der Nummer und Artikelbezeichnung der Vertriebsauftragspositionen initialisiert.

function applyDefaults()
{
/* initialize dynamic result field with line items */
var hm := new(HashMap);
var details := getCisObjectList("SELECT FROM com.cisag.app.sales.obj.SalesOrderDetail o WHERE o:header = ? ORDER BY o:number", list(parameters.object:guid), 100);
for (detail as CisObject(com.cisag.app.sales.obj.SalesOrderDetail) : details) {
hm[format(detail:number, "0")] := cast(String, detail:number) + " " + detail->Item:number + " " + detail->Item:description;
}
formatSelectionField("details", hm);
}

Folgende Übergangsbedingung deaktiviert die Benutzeraktion im Kontextmenü, wenn der Vertriebsauftrag keine Position besitzt:

parameters.object:detailCount > 0

setResultFieldEditable

setResultFieldVisible

Funktionen für E-Mail-Nachrichten und E-Mail-Knoten (E-Mail functions)

Mithilfe der Funktionen für E-Mail-Nachrichten und E-Mail-Knoten können Sie den E-Mail-Versand in diesen beiden Aktivitätstypen konfigurieren:

• addMailAttachment
• setMailLinkTarget
• setMailRecipientsBCC
• setMailRecipientsCC
• setMailRecipientsTo
• setMailReplyTo
• setMailSender
• setMailTemplate

addMailAttachment

setMailLinkTarget

setMailRecipientsBCC

setMailRecipientsCC

setMailRecipientsTo

setMailReplyTo

setMailSender

setMailTemplate

Funktionen für Service-Knoten (Service node functions)

Die Funktionen für Service-Knoten bieten Möglichkeiten, Aktivität mit einem Verarbeitungsauftrag als Bearbeiter zu konfigurieren:

• formatBatchJobResult
• formatBatchJobOutputResult
• getJobResults
• isJobToBeScheduled
• setJobName
• setJobQueue
• setJobServer
• setJobUser
• setJobVoucherTemplateOutputOptions
• setJobWaitFinish

formatBatchJobResult

formatBatchJobOutputResult

getJobResult

Beispiel: Generierte Inventurzählisten auswerten

Die Aktion CreateCountLists (45)der Hintergrundanwendung com.cisag.app.inventory.physical.log.PhysicalInventoryCountProcessing(Inventur-Aktionen veranlassen) gibt eine Liste mit den GUIDs der erzeugten Inventurzähllisten zurück:

{resultParmeters:CisParameterList:
{ResultNumberOfSuccessfulResults:1}
{ResultPhysicalInventoryCountListGuids:[[B@5570b91]}}

In einem Service-Knoten ruft die Funktion closedie Funktion getJobResultsauf, um die generierten Inventurzähllisten auszuwerten, und gibt die Identifikation der generierten Inventurzähllisten ins Protokoll aus.

function close(state as Number)
{
var rp as HashMap;
var clGenerated as Number;
var clGuids as Guid[];
var cl as CisObject(com.cisag.app.inventory.physical.obj.PhysicalInventoryCountList);

rp := cast(HashMap, getJobResult().resultParmeters);
clGenerated := cast(Number, rp.ResultNumberOfSuccessfulResults);
clGuids := cast(Guid[], rp.ResultPhysicalInventoryCountListGuids);

echo(format(clGenerated, "0") + " count list(s) generated:");
for (g : clGuids) {
cl := getByPrimaryKey(CisObject(com.cisag.app.inventory.physical.obj.PhysicalInventoryCountList), g);
echo(cl->PhysicalInventory->Type:code + "-" + cl->PhysicalInventory:number + " " + cl:number);
}
}

isJobToBeScheduled

setJobName

setJobQueue

setJobServer

setJobUser

setJobVoucherTemplateOutputOptions

setJobWaitFinish

Funktionen für Webservice-Knoten

Ein Webservice-Knoten bietet die Funktionalität für den Aufruf eines Webservices und für die Auswertung der Ergebnisse. Der Aufruf erfolgt durch die fest verknüpfte Hintergrundanwendung ServiceClient com.cisag.sys.workflow.webservices.log.ServiceClient.

Die Funktionen für Webservice-Knoten bieten Möglichkeiten, Aktivitäten des Typs Webservivce-Knoten zu konfigurieren:

• getServiceResponse
• parseJson
• parseXml

getServiceResponse

Folgendes Beispiel aus einer Aktivitätsdefinition vom Typ Webservice-Knoten fragt das Ergebnis promise aus dem Webservice ab. Beim Starten eines Workflow-Prozesses per Webservice besteht das promise aus der Guid der gestarteten Prozess-Instanz. Der Wert kann später verwendet werden, um den Status des Prozesses und das Ergebnis abzufragen.

function close(state as Number)
{
var response := parseJson(getServiceResponse());
if (size(response.errors) = 0) {
process.promise := response.promise;
}
}

parseJson

Folgendes Beispiel aus der Aktivitätsdefinition help.parseJson erzeugt eine Hash-Tabelle aus einer Zeichenkette in JavaScript Object Notation (JSON) und gibt die Hash-Tabelle auf der Konsole aus:

function create()
{
var p_text := parameters.TEXT;
var r_parsedText := parseJson(p_text);

echo(r_parsedText);
}

parseXml

Folgendes Beispiel aus der Aktivitätsdefinition help.parseXml gibt das Ergebnis der Funktion parseXml auf der Konsole aus:

function create()
{
var p_text := parameters.TEXT;
var p_pathExpression := parameters.PATH_EXPRESSION;
var r_parsedText := new(HashMap);

if (p_pathExpression = "")
r_parsedText := parseXml(p_text);
else
var r_parsedText := parseXml(p_text, p_pathExpression);

echo(r_parsedText);
}

Im nächsten Beispiel wird eine Exportdatei im XML-Format für den Partner JOB geparst:

<?xml version="1.0" encoding="UTF-8"?>
<semiramis xmlns="com.cisag.app.general.obj.Partner" xsi:schemaLocation="com.cisag.app.general.obj.Partner Partner.xsd" created="2020-07-09T17:18:43.616Z" locale="en-US-XMLSchemaCompliant" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" nlsMode="SINGLE_LANGUAGE" dateTimeMode="COMPACT">
<Partner xmlns="com.cisag.app.general.obj.Partner">
<number>JOB</number>
<type>INTERNAL</type>
<person>
<givenName>Max</givenName>
<middleNames>Headroom</middleNames>
<surname>JOB</surname>
<Salutation>
<name>200</name>
</Salutation>
</person>
<human>true</human>
</Partner>
</semiramis>

Wenn die Variable partner die Exportdatei enthält, dann gibt der Ausdruck parseXML(partner, "/semiramis/Partner/person/surname"}die Hash-Tabelle „{/semiramis/Partner/person/surname=[S=JOB]}“ zurück.

Befehle für dynamische Indikatoren (Dynamic indicator commands)

Ein Indikator repräsentiert eine technische oder eine betriebswirtschaftliche Kennzahl, deren Wert überwacht werden soll. Die System-Engine stellt bereits eine Reihe von Indikatoren zur Verfügung. Weitere dynamische Indikatoren können vom Benutzer selbst erfasst werden. Dynamische Indikatoren können von einem der folgenden Typen sein:

• Aggregationsindikator
• Zählerindikator
• Zahlindikator
• Statusindikator

Für Zähler- und Aggregationsindikatoren wird keine Aktivitätsdefinition beim Indikator angegeben. Jede beliebige Aktivitätsdefinition kann jedoch ein Ereignis für einen Zähler- oder Aggregationsindikator auslösen, wenn ein bestimmtes z. B. betriebswirtschaftliches Ereignis eintritt. Normalerweise hat diese Aktivitätsdefinition nur die Aufgabe, das Ereignis für den Indikator auszulösen. Vom Benutzer wird jedoch keine weitere Reaktion benötigt.

Mithilfe der beiden Befehle für dynamische Indikatoren können Sie Aggregations- und Zählerindikatoren auslösen:

• fireAggregatorIndicator
• fireCounterIndicator

Weitere Informationen zu den Indikatoren finden Sie in den Dokumentationen Einführung: Indikatoren und Dynamische Indikatoren.

fireAggregatorIndicator

fireCounterIndicator

Funktionsaufrufe für Zahl- und Statusindikatoren

Dynamische Indikatoren können von einem der folgenden Typen sein:

• Aggregationsindikator
• Zählerindikator
• Zahlindikator
• Statusindikator

Aggregationsindikatoren und Zählerindikatoren werden von den beiden Skript-Funktionen fireAggregatorIndicatorund fireCounterIndicatorausgelöst. Eine Aktivität, die durch ein bestimmtes Ereignis erzeugt wird, erhöht den Wert des dynamischen Indikators, d. h. sie funktionieren nach dem Push-Prinzip.

Zahlindikatoren und Statusindikatoren funktionieren dagegen nach dem Pull-Prinzip. Bei Bedarf ruft der auf dem Dashboard angezeigte dynamische Indikator die mit dem Indikator verknüpfte Aktivitätsdefinition des Typs Funktionsaufruf auf. Die Aktivitätsdefinition berechnet den Wert bzw. den Status und gibt ihn mithilfe eines Ergebnisparameters zurück. Bei einem Zahlindikator muss der Ergebnisparameter den Namen VALUE besitzen und vom Datentyp Zahl sein.

Eine Aktivitätsdefinition für einen Zahlindikator muss einen Ergebnisparameter des Datentyps Zeichenkette mit den Namen STATUS besitzen. Eine Aktivitätsdefinition für einen Statusindikator muss zwei Ergebnisparameter des Datentyps Zeichenkette besitzen. Der erste Ergebnisparameter übergibt den Status und muss den Namen STATE haben. Der zweite Ergebnisparameter übergibt eine Beschreibung des Statuswerts und muss den Namen DESCRIPTION haben.

Beispiel: Anzahl der heute gebuchten Wareneingänge

Folgende Deklarationen ermitteln die Anzahl der heute gebuchten Wareneingänge und gibt das Ergebnis über die Ergebnisvariable VALUE an den dynamischen Indikator zurück.

const OrderStatus as valueSet(com.cisag.app.general.OrderStatus);

function create()
{
/* Get time particles for OQL query */
var fromDate := today();
var fromYear := format(year(fromDate), "0000");
var fromMonth := format(month(fromDate), "00");
var fromDay := format(day(fromDate), "00");

/* Use default time zone ID of the system */
var timeZoneId := timeZoneId(fromDate);

/* create OQL statement */
var OQL :=
"SELECT COUNT(*) FROM com.cisag.app.purchasing.obj.ReceiptOfGoods o " +
"WHERE o:date >= toTimestamp('" + timeZoneId + "'" +
", " + fromYear + ", " + fromMonth + ", " + fromDay +
", 00, 00, 00, 0000) AND o:status = 3";

/* query the database */
var receiptsOfGoodsPostedToday := cast(Number, getResultList(OQL, list(), 1)[0][0]);

/* return the result */
result.VALUE := receiptsOfGoodsPostedToday;
}

Funktionen für Cockpit-Anwendungen (Cockpit functions)

Mithilfe der Funktion createFilter können Selektionsfelder einer Cockpit-Anwendung vorbelegt werden.

createFilter

Folgende Tabelle gibt einige der für Selektionsfelder in Cockpit-Anwendungen am häufigsten verwendeten Datentypen wider:

Weitere Informationen zu den einzelnen Datentypen entnehmen sie der Dokumentation Datentypen.