Workflow-Attribute lassen sich auf einem System mit der Versionierungsstufe 7 und der Verwendung als Produktiv-Testsystem oder Produktivsystem erfassen. Dazu ist keine Programmierung und sind keine Programmierkenntnisse notwendig. Ähnlich wie ein benutzerdefiniertes Attribut wird auch ein Workflow-Attribut mithilfe eines Business Objects gespeichert, das mit dem Typ Managed Supplement klassifiziert ist.

Ein Managed Supplement mit benutzerdefinierten Attributen besitzt die Verwendung Standard und ein Managed Supplement mit Workflow-Attributen besitzt die Verwendung Workflow. Sie können beliebig viele solcher Workflow-Supplements erfassen. Workflow-Attribute auf mehrere Workflow-Supplements zu verteilen hat den Vorteil, dass wenn eine Aktivität Workflow-Attribute zum ersten Mal speichert und dadurch eine neue Instanz des Workflow-Supplements erzeugt, Workflow-Attribute, die zu anderen Workflow-Supplements gehören, nicht mit Standardwerten vorbelegt werden. Zu viele Workflow-Supplements für dasselbe Business Object zu erfassen, könnte die Leistung des Systems vermindern, da zusammen mit dem Business Object auch dessen Supplements von der Datenbank geladen werden. Wenn Workflow-Attribute für unterschiedliche Workflow-Prozesse im selben Workflow-Supplement erfasst sind, ist es von Vorteil, wenn jeder Workflow-Prozess über ein Workflow-Attribut verfügt, dessen Standardwert darauf hinweist, ob eine Prozessinstanz den Workflow-Attributen Werte zugewiesen hat oder nicht.

Ein Beispiel für ein solches Workflow-Attribut ist der Genehmigungsstatus eines Beschaffungsauftrags. Eine leere Zeichenkette bedeutet, dass noch kein Genehmigungsprozess für den Beschaffungsauftrag gestartet wurde. Startet der Benutzer den Genehmigungsprozess, dann sollte der Startknoten dem Workflow-Attribut einen Wert ungleich dem Standardwert zuweisen, wie z. B. In Prüfung. Anstatt einer Zeichenkette könnte der Genehmigungsstatus auch mit numerischen Werten abgebildet werden. In diesem Fall würde der Standardwert 0 bedeuten, dass noch kein Genehmigungsprozess für den Beschaffungsauftrag existiert, und der Wert 1 könnte bedeuten, dass sich der Beschaffungsauftrag in Prüfung befindet.

Workflow-Attribute können zu anpassbaren Anwendungen hinzugefügt und angezeigt werden, vorausgesetzt das Managed Supplement gehört zur Objektsicht der Anwendung. Anders als ein benutzerdefiniertes Attribut ist ein Workflow-Attribut nicht editierbar, weder in der Anwendung noch über den Import. Nur Aktivitätsdefinitionen können Workflow-Attributen einen Wert zuweisen. Somit gibt es eine klare Trennung der Zuständigkeiten zwischen den benutzerdefinierten Attributen und den Workflow-Attributen.

Zu den Funktionen für Workflow-Attribute gehören:

• getOrCreateSupplement
• getSupplement
• putSupplement

Allgemeine Informationen zu den OLTP-Funktionen der System-Skriptsprache erhalten Sie im Artikel System-Skriptsprache: OLTP-Funktionen.

getOrCreateSupplement

Folgendes Beispiel aus der Aktivitätsdefinition help.getOrCreateSupplement öffnet ein Supplement für einen Partner ohne Schreibsperre und gibt den Wert eines Workflow-Attributs zurück.

function create()
{
var p_partner := loadPartner(parameters.PARTNER);
var p_supplement := parameters.SUPPLEMENT;
var p_attribute := parameters.ATTRIBUTE;

var workflowAttributes := getOrCreateSupplement(p_partner, p_supplement, false);

result.IS_NULL := isNull(workflowAttributes);
if (not isNull(workflowAttributes))
result.VALUE := cast(String, workflowAttributes[p_attribute]);
}

Beispiel: Workflow-Attribute erfassen

Workflow-Attribute lassen sich zur Oberfläche anpassbarer Anwendungen hinzufügen. Im Gegensatz zu einem benutzerdefinierten Attribut kann ein Workflow-Attribut nur in einer Workflow-Aktivität geändert werden. Auf der Oberfläche einer Anwendung ist ein Workflow-Attribut nie eingabebereit.

Weitere Informationen zu den benutzerdefinierten Attributen und den Managed Supplements entnehmen Sie dem Hilfedokument Benutzerdefinierte Attribute.

Anwendung Benutzerdefinierte Attribute öffnen

Um Workflow-Attribute zu erfassen, öffnen Sie zunächst die Anwendung Benutzerdefinierte Attribute. Wird die Anwendung nicht im Benutzermenü angezeigt, dann können Sie stattdessen die Anwendung Entwicklungsobjekte öffnen und nach der Anwendung Benutzerdefinierte Attribute (ManagedSupplementMaintenance) suchen. Drücken Sie anschließend den Button Anwendung öffnen, der sich im Karteireiter Editor befindet.

In einem Kundensystem lässt sich die Anwendung Benutzerdefinierte Attribute auch im Desgnmodus einer anpassbaren Anwendung öffnen. Öffnen Sie zunächst eine beliebige anpassbare Anwendung und aktivieren Sie den Designmodus. Im andockbaren Fenster Designmodus wählen Sie den Karteireiter Attribute und selektieren Sie ein beliebiges Business Object in der Objektsicht der Anwendung. Es muss sich nicht um dasjenige Business Object handeln, für welches Sie Workflow-Attribute erfassen möchten. Drücken Sie anschließend den Button Benutzerdefinierte Attribute im Kopfbereich des Karteireiters.

Wenn Sie die Anwendung Benutzerdefinierte Attribute über den Designmodus einer anpassbaren Anwendung öffnen, sind die Felder vorbelegt. Die Vorbelegung spielt für das Erfassen der Workflow-Attribute keine Rolle.

Workflow-Supplement anlegen

In der Anwendung Benutzerdefinierte Attribute drücken Sie den Button [Neu]. Im Aktionsdialog „Managed Supplement erzeugen“ geben Sie das Business Object an, für das Sie Workflow-Attribute erfassen möchten. Als Verwendung wählen Sie Workflow aus. Die Felder Managed Supplement und Bezeichnung werden mit Vorschlagswerten vorbelegt. Sie können die Vorschlagswerte ändern, z. B. wenn Sie die Workflow-Attribute, die von einer Prozessdefinition oder einer Menge von Prozessdefinitionen verwendet werden, in einem eigenen Supplement speichern möchten. Geben Sie ein vorhandenes Workflow-Supplment an, dann werden die neuen Workflow-Attribute diesem hinzugefügt.

Wenn Sie Ihre Angaben mit [OK] bestätigen, wird automatisch eine Entwicklungsaufgabe erzeugt. Das Business Object und die Objektsicht des Workflow-Supplements werden ggf. erzeugt und der Entwicklungsaufgabe zugeordnet. Die Identifikation (Nummer) der Entwicklungsaufgabe wird in der Toolbar der Anwendung „Benutzerdefinierte Attribute“ angezeigt.

Solange Sie die Entwicklungsaufgabe nicht aktiviert haben, können Sie das Erfassen abbrechen und rückgängig machen. Öffnen Sie dazu die Entwicklungsaufgabe und lassen sich im Karteireiter Entwicklungsobjekte die zugeordneten Entwicklungsobjekte anzeigen. Öffnen Sie zuerst die Objektsicht. In der Anwendung Entwicklungsobjekte entfernen Sie die Objektsicht aus der Aufgabe. Danach öffnen Sie auch das in der Entwicklungsaufgabe angezeigte Business Object und entfernen es aus der Entwicklungsaufgabe. Aktualisieren Sie die Anzeige der Entwicklungsobjekte in der Anwendung Entwicklungsaufgaben. Nachdem Sie alle Entwicklungsobjekte aus der Aufgabe entfernt haben, löschen Sie die Entwicklungsaufgabe.

Workflow-Attribute erfassen

Nachdem Sie im Aktionsdialog Managed Supplement erzeugen Ihre Angaben mit [OK] bestätigt haben, erfassen Sie die neuen Workflow-Attribute mithilfe des Positionseditors.

Weitere Informationen zu den benutzerdefinierten Attributen und den unterstützten Datentypen entnehmen Sie dem Hilfedokument Benutzerdefinierte Attribute.

Entwicklungsaufgabe aktivieren

Nachdem Sie alle Workflow-Attribute erfasst haben, öffnen Sie die Anwendung Cockpit: Produktivsystem-Entwicklungsobjekte und lassen sich die gesperrten Entwicklungsaufgaben anzeigen. Führen Sie die Aktion [Entwicklungsaufgaben aktivieren…] durch. Wenn im Aktionsdialog die Entwicklungsaufgabe mit dem Workflow-Supplement und den Workflow-Attributen angezeigt wird, drücken Sie den Button [Sofort].

Die Aktion löst zwei aufeinander folgende Neustarts des Systems aus, um die neuen Workflow-Attribute zu installieren.

Nach der Installation stehen die Workflow-Attribute uneingeschränkt zur Verfügung und können z. B. in Aktivitätsdefinitionen verwendet werden.

Weitere Informationen zum Aktivieren der Entwicklungsaufgabe und zum Transportieren und Installieren des Workflow-Supplements auf einem Zielsystem (Kunden-Produktivsystem) entnehmen Sie dem Hilferdokument Cockpit: Produktivsystem-Entwicklungsobjekte.

getSupplement

Folgendes Beispiel aus der Aktivitätsdefinition help.getSupplement öffnet ein Supplement für einen Partner und gibt den Wert eines Workflow-Attributs zurück. Existiert kein Supplement für das Business Object, wird der Wert null zurückgegeben.

function create()
{
var p_partner := loadPartner(parameters.PARTNER);
var p_supplement := parameters.SUPPLEMENT;
var p_attribute := parameters.ATTRIBUTE;

var workflowAttributes := getSupplement(p_partner, p_supplement, false);

result.IS_NULL := isNull(workflowAttributes);
if (not isNull(workflowAttributes))
result.VALUE := cast(String, workflowAttributes[p_attribute]);
}

putSupplement

Folgendes Beispiel aus der Aktivitätsdefinition help.putSupplement öffnet die Workflow-Attribute eines Partners und ändert den Wert eines Attributs.

function create()
{
var p_partner := loadPartner(parameters.PARTNER);
var p_supplement := parameters.SUPPLEMENT;
var p_attribute := parameters.ATTRIBUTE;
var r_putSupplement := false;

var workflowAttributes := getOrCreateSupplement(p_partner, p_supplement, true);
result.IS_NULL_GET := isNull(workflowAttributes);

if (cast(Boolean, first(workflowAttributes, false)))

{
var attributeValue := cast(String, workflowAttributes[p_attribute]);
result.OLD_VALUE := attributeValue;
workflowAttributes[p_attribute] := parameters.VALUE;
r_putSupplement := putSupplement(workflowAttributes);
result.IS_NULL_SET := isNull(r_putSupplement);
workflowAttributes := getSupplement(p_partner, p_supplement);
result.NEW_VALUE := cast(String, workflowAttributes[p_attribute]);
}
}

Beispiel: Workflow-Attribute in Genehmigungsprozessen

Genehmigungsstatus in einem Workflow-Attribut speichern

Genehmigungsprozesse sind ein wichtiges Aufgabengebiet von Workflow-Attributen. Ist der aktuelle Genehmigungsstatus nicht in einem Workflow-Attribut gespeichert, ist die individuelle Validierung, die das Freigeben eines nicht genehmigten Auftrags verhindert, sehr komplex und aufwendig zu erfassen. Wird der Genehmigungsstatus in einem Workflow-Attribut gespeichert, braucht ein einfach gestalteter Genehmigungsprozess nur diesen einzigen Status zu prüfen.

Je nach Beschaffenheit des Genehmigungsprozesses sind weitere Bedingungen möglich, wie z. B. die Berücksichtigung von Kostenstellen und periodenbezogenen Schwellenwerten (die ebenfalls als Workflow-Attribute abgebildet werden können).

Der Einfachheit und Übersichtlichkeit halber gehen wird in diesem Beispiel auf solche organisationsspezischen Anforderungen nicht näher eingegangen. Stattdessen wird ein einfacher Genehmigungsprozess mit folgenden Werten für den Genehmigungsstatus erfasst, die in einem Workflow-Attribut status gespeichert werden:

• Leere Zeichenkette (Standardwert) – Es wurde noch kein Genehmigungsprozess gestartet.
• IN_APPROVAL – Ein Genehmigungsprozess wurde gestartet, der noch nicht erledigt ist bzw. für den noch kein Ergebnis vorliegt.
• APPROVED – Der Beschaffungsauftrag wurde im letzten Genehmigungsprozess genehmigt.
• REJECTED – Der Beschaffungsauftrag wurde im letzten Genehmigungsprozess abgelehnt.
• WITHDRAWN – Der Antragssteller (Auslöser) hat den Genehmigungsprozess zurückgezogen.
• INVALID – Der letzte Prüfprozess wurde mit einem Fehler beendet.

Freigabe nicht genehmigter Beschaffungsaufträge unterbinden

Eine individuelle Prüfung soll die Freigabe eines Beschaffungsauftrags in den folgenden Fällen verhindern:

• Der Beschaffungsauftrag verwendet eine Art mit dem Eröffnungsstatus Erfasst. (Ist der Eröffnungsstatus Freigegeben, wäre es ohnehin nicht möglich, die Freigabe zu unterbinden.)
• Der Nettobetrag übersteigt 1.000 Währungseinheiten in der 1. Hauswährung und der Beschaffungsauftrag besitzt nicht den Gehnmigungsstatus APPROVED.

Zunächst erfassen Sie für den Hook Contract des Beschaffungsauftrags (com.cisag.app.purchasing.order.hook.log.PurchaseOrder) eine individuelle Prüfung, die die Freigabe nicht genehmigter Beschaffungsaufträge unterbindet. Die Objektsicht persistent enthält die in der Datenbank persistent gespeicherten Werte des Beschaffungsauftrags. Die Objektsicht current enthält die zu prüfenden Werte.

Um herauszufinden, welche Attribute Sie prüfen können, öffnen Sie die Objektsicht für den Beschaffungsauftrag (com.cisag.app.purchasing.order.model.PurchaseOrder) in der Anwendung Objektschema anzeigen. Der Karteireiter Attribute zeigt die Attribute und der Karteireiter Beziehungen die Beziehungen der Objektsicht an. Ist die Beziehung vom Typ Objektsicht, können Sie in der Regel nicht persistent gespeicherte Attribute in der referenzierten Objektsicht prüfen. Eine Bezeichnung vom Typ Business Object zeigt aber auf ein persistent gespeichertes Business Object.

Danach erfassen Sie folgende individuelle Prüfung:

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

function validateHeader(
persistent as DataView(com.cisag.app.purchasing.order.model.PurchaseOrder),
current as DataView(com.cisag.app.purchasing.order.model.PurchaseOrder))
{
/* do not validate PO in creation mode */
if (isNull(persistent))
return;

/* do not validate PO that was relased on creation */
if (current->Type:creationStatus <> Status.ORDER_ENTERED)
return;

/* do not validate PO unless net value exceeds threshold */
if (current:totalValues.netValueDomestic.amount1 <= 1000)
return;

/* get workflow supplement with approval attributes */
var approval := getByPrimaryKey(CisObject(com.cisag.app.purchasing.obj.PurchaseOrderWorkflowApproval), current:guid);

/* prevent release of PO unless approved */
if (approval.status <> "APPROVED" and (persistent:status = Status.ORDER_ENTERED and current:status = Status.ORDER_RELEASED))
sendMessage(current:number, "PUR001", list(current->Type:code, current:number));

Die erste Bedingung erlaubt dem Benutzer, einen neuen Beschaffungsauftrag ohne Prüfungen zu speichern. Die zweite Bedingung erlaubt jegliche Änderungen und Statuswechsel für Beschaffungsaufträge, die eine Art mit dem Eröffnungsstatus Freigegeben verwenden. Die dritte Bedingung erlaubt Änderungen und Statuswechsel, wenn der Gesamtnettobetrag 1.000 Währungseinheiten in der ersten Hauswährung nicht übersteigt.

Danach wird das Workflow-Supplement mithilfe der Funktion getByPrimaryKey geöffnet. Da ein Supplement den gleichen Primärschlüssel wie das Business Object besitzt, öffnen Sie das Workflow-Supplement über die Guid des Beschaffungsauftrags.

Die darauf folgende Bedingung prüft, ob der Beschaffungsauftrag vom Status Erfasst in den Status Freigegeben überführt wird. Ist dies der Fall und der Beschaffungsauftrag besitzt nicht den Genehmigungsstatus APPROVED, dann wird die Freigabe verhindert und die Fehlermeldung PUR001 angezeigt.

Der Beschaffungsauftrag besitzt ein Attribut mit den Namen statusBackup. Dieses Attribut wird verwendet, wenn der Beschaffungsauftrag mehr Positionen besitzt, als in einer Datenbanktransaktion gespeichert werden können, d. h. wenn die Anzahl der Positionen die Blockgröße übersteigt. Ein solcher Beschaffungsauftrag muss blockweise freigegeben werden. Beim Freigeben der Positionen des ersten Blocks wird der Beschaffungsauftrag in den Status Ungültig überführt. Im Attribut statusBackup wird der künftige Status und im Attribut invalidOrderReason die Ursache für den ungültigen Status festgehalten. Erst mit der Freigabe der Positionen des letzten Blocks wird der Beschaffungsauftrag in den Zielstatus Freigegeben überführt. Um sicherzustellen, dass entweder keine oder alle Positionen freigegeben werden und der Beschaffungsauftrag nach einer versuchten Freigabe nicht den Status Ungültig erhält, fügen Sie der individuellen Prüfung eine weitere Bedingung hinzu:

/* prevent release of PO unless approved (block size exceeded) */
if (approval.status <> "APPROVED" and (persistent:status = Status.ORDER_ENTERED and current:status = Status.ORDER_INVALID and current:statusBackup = Status.ORDER_RELEASED and current:invalidReason = Reason.CHANGE_HEADER_STATUS))
sendMessage(current:number, "PUR001", list(current->Type:code, current:number));
}

Eine solche Bedingung ist nur für Belegtypen erforderlich, die ein Attribut mit dem Namen statusBackup besitzen.

Genehmigungsprozess über das Kontextmenü starten

Um den Genehmigungsprozess über das Kontextmenü des Beschaffungsauftrags starten zu können, geben Sie im Startknoten des Genehmigungsprozesses ein Ereignis vom Typ Benutzeraktion für den Beschaffungsauftrag (com.cisag.app.purchasing.obj.PurchaseOrder) ein.

Sollte der Genehmigungsprozess nicht sofort im Kontextmenü unter Prozess starten angezeigt werden, dann melden Sie sich vom System ab und wieder an.

Um zu verhindern, dass ein Genehmigungsprozess für einen Beschaffungsauftrag gestartet wird, der ohne Genehmigung freigegeben werden darf, geben Sie eine ähnliche Übergangsbedingung wie in der individuellen Prüfung an. Ist die Übergangsbedingung nicht erfüllt, dann ist der Prozess im Kontextmenü nicht auswählbar. Mithilfe der Funktion indexOf stellen Sie sicher, dass ein Genehmigungsprozess nur für Beschaffungsaufträge mit dem Genehmigungsstatus REJECTED, WITHDRAWN oder INVALID gestartet werden kann. Auch wenn der Genehmigungsstatus den Standardwert (leere Zeichenkette) besitzt, kann ein Genehmigungsprozess gestartet werden, da in diesem Fall die Funktion indexOf den Wert 0 und nicht -1 zurückgibt.

parameters.object->Type:creationStatus = 1 /* ORDER_ENTERED */ and parameters.object:totalValues.netValueDomestic.amount1 > 1000 and indexOf("REJECTED|WITHDRAWN|INVALID", getByPrimaryKey(CisObject(com.cisag.app.purchasing.obj.PurchaseOrderWorkflowApproval), parameters.object:guid):status) >= 0

Im Startknoten ändern Sie mithilfe der Funktion putSupplement den Genehmigungsstatus des Beschaffungsauftrags auf IN_APPROVAL. Somit können keine weiteren Genehmigungsprozesse gestartet werden. Konnte der genehmigungsstatus nicht geändert werden, brechen Sie mithilfe des Befehls abortProzess die Prozesserzeugung ab. Zudem speichern Sie den Beschaffungsauftrag in der Prozessvariablen po, damit er in den weiteren Prozessschritten ausgewertet werden kann.

function create()
{
var putOK := false;
var approval := getOrCreateSupplement(parameters.object, "com.cisag.app.purchasing.obj.PurchaseOrderWorkflowApproval");
if (not isNull(approval))
{
approval.status := "IN_APPROVAL";
var putOK := putSupplement(approval);
}
if (not cast(Boolean, first(putOK, false)))
{ /* contingency handling if approval status update failed */
abortProcess();
}
process.po := parameters.object;
}

Der Name des Benutzers, der den Prozess startet, wird bei einer Benutzeraktion automatisch in process.Initiatorgespeichert. Auch wird der Beschaffungsauftrag dem Startknoten (und somit dem Prozess) automatisch zugeordnet, damit alle Genehmigungsprozesse eines Beschaffungsauftrags über das Kontextmenü abgefragt werden können.

Freigabe bei Sonderberechtigung immer erlauben

Sie können die Freigabe eines nicht genehmigten Beschaffungsauftrags für Benutzer mit Sonderberechtigungen erlauben. Diese Möglichkeit ist z. B. dann nützlich, wenn ein Beschaffungsauftrag kurzfristig freigegeben werden soll und ein Genehmigungsprozess zu lange dauern würde oder wenn ein Fehler im Genehmigungsprozess sowohl die Genehmigung und somit auch die Freigabe verhindert. Die einfachste Umsetzung dieser Anforderung ist, eine Workflowrolle Head of Procurement zu erfassen und den Inhabern dieser Workflowrolle immer zu erlauben, einen Beschaffungsauftrag freizugeben. Dazu erweitern Sie die individuelle Prüfung um folgende Bedingung, bevor das Workflow-Supplement geöffnet wird:

/* do not validate PO for super users */
if (contains(resolveRole("HEAD_OF_PROCUREMENT"), environment.userGuid)
return;

Beschaffungsauftrag während der Prüfung schützen

Um zu verhindern, dass der Beschaffungsauftrag während der Prüfung geändert wird, erfassen Sie eine weitere Bedingung in der individuellen Prüfung.

/* prevent changes to PO during approval */
if (approval.status = "IN_APPROVAL")
sendMessage(current:number, "PUR002", list(current->Type:code, current:number));

Um den Prüfern zu erlauben, einen Beschaffungsauftrag mit dem Genehmigungsstatus IN_APPROVAL zu ändern, um z. B. Mengen anzupassen, Positionen zu löschen oder neue Positionen hinzuzufügen, erfassen Sie ein weiteres Workflow-Attribut process, das die Identifikation des letzten Genehmigungsprozesses enthält. In der Aktivitätsdefinition für den Startknoten weisen Sie dem Workflow-Attribut die Identifikation des aktuellen Prozesses zu:

approval.process := activity->Process:code;

Die vorherige Bedingung ergänzen Sie wie folgt:

/* prevent changes to PO during approval (except by editors) */
if (approval.status = "IN_APPROVAL" and not isEditor(approval.process, environment.userGuid)
sendMessage(current:number, "PUR002", list(current->Type:code, current:number));

Die benutzerdefinierte Funktion isEditor ermittelt mithilfe einer OQL-Abfrage, ob der Benutzer, für den der Beschaffungsauftrag gerade geprüft wird, eine offene Aufgabe vom Typ Entscheidungsknoten im verknüpften Genehmigungsprozess besitzt. Ist dies der Fall, gibt die Funktion den Wert true zurück, ansonsten false.

function isEditor(processId as String, userGuid as Guid) as Boolean
{
/* Returns true if userGuid has an open decision node belonging to processId */

var proc as CisObject(com.cisag.sys.workflow.obj.Process);
var OQL := "SELECT COUNT(*) FROM com.cisag.sys.workflow.obj.Workitem task JOIN com.cisag.sys.workflow.obj.Activity activity ON task:activityGuid = activity:guid JOIN com.cisag.sys.workflow.obj.Process process ON activity:process = process:guid WHERE task:userGuid = ? AND process:code = ? AND activity:type = 15 AND task:state in (20, 30, 40, 70)";

var params as Unknown[];
add(params, processId);
add(params, userGuid);
return cast(Number, getResultList(OQL, params, 1)[0][0]) > 0;
}

Eine alternative Lösung wäre, in der Funktion create des Entscheidungsknotens die Funktion putSupplement aufzurufen, um die Benutzernamen der Bearbeiter in einem neuen Workflow-Attribut zu speichern. Mit dieser Lösung könnten aber Prüfer, die ihre Aufhabe durch Weiterleitung oder eine Folgeaktion bei Zeitüberschreitung erhalten haben, den Beschaffungsauftrag nicht ändern.

Genehmigungsergebnis in Workflow-Attributen speichern

Im Genehmigungsprozess wird der Beschaffungsauftrag entweder genehmigt oder abgelehnt. Es handelt sich also um eine Entscheidung mit zwei Möglichkeiten. Für diesen Anwendungsfall wurde der Entscheidungsknoten implementiert. Der Entscheidungsknoten interpretiert den Status Erledigt als eine positive Entscheidung (genehmigt) und den Status Unbearbeitet erledigt als eine negative Entscheidung (abgelehnt). Ist in der Aktivitätsdefinition die Entscheidungsregel Konsens ausgewählt, dann endet die Aktivität, sobald mindestens ein Bearbeiter (Prüfer) eine Aufgabe unbearbeitet erledigt hat, d. h. den Beschaffungsauftrag abgelehnt hat.

Ist die Entscheidungsregel Mehrheit ausgewählt, dann endet die Aktivität, sobald mehr als die Hälfte der Bearbeiter die Aufgabe entweder erledigt oder unbearbeitet erledigt hat. Bei einer Pattsituation gilt der Beschaffungsauftrag als genehmigt. Verwendet die Prozessdefinition einen Ereignisknoten, ist es weder erforderlich noch sinnvoll, dass für jeden Prüfer eine eigene Aktivität erzeugt wird. Ein weiter Vorteil eines Entscheidungsknotens ist, dass die Entscheidung als Ergebnis der Aktivität bzw. des Prozesses automatisch eingetragen wird. Daher hinterlegen Sie in der Aktivitätsdefinition des Startknotens APPROVED als Ergebnis bei einer positiven Entscheidung und REJECTED als Ergebnis bei einer negativen Entscheidung. Auch wählen Sie Prozess und Aktivität im Feld Automatische Ergebniseintragung.

In der Aktivitätsdefinition für den Entscheidungsknoten speichern Sie das Genehmigungsergebnis im Workflow-Attribut status. Um die Nachvollziehbarkeit des Genehmigungsprozesses zu erhöhen, speichern Sie auch weitere Workflow-Attribute, um den Zeitpunkt der Genehmigung und den Namen des Benutzers, der den Beschaffungsauftrag genehmigt oder abgelehnt hat, festzuhalten. Als Genehmiger bzw. Ablehner gilt derjenige Benutzer, der mit dem Erledigen der Aufgabe auch die Aktivität erledigt hat. Dieser Benutzer befindet sich im Attribut completeUser der Aktivität und kann in der Funktion close abgefragt werden. Dieser Benutzer kann auch im darauf folgenden Knoten durch folgenden Ausdruck ermittelt werden:

process.previousStep:completeUser

Hat der darauf folgende Knoten mehr als eine eingehende Kante, dann enthält previousStep eine Liste der Vorgänger-Aktivitäten. Ist der Entscheidungsknoten die erste Vorgänger-Aktivität, kann der Benutzer wie folgt ermittelt werden:

process.previousStep[0]:completeUser

Auch speichern Sie den aktuellen Nettobetrag zum Zeitpunkt der Genehmigung bzw. Ablehnung in einem Workflow-Attribut.

function close(state as Number)
{
var putOK := false;
var approval := getOrCreateSupplement(process.po, "com.cisag.app.purchasing.obj.PurchaseOrderWorkflowApproval");
if (not isNull(approval))
{
var po := getByPrimaryKey(CisObject(com.cisag.app.purchasing.obj.PurchaseOrder), process.po);
approval.date := now();
approval.status := process.Result;
approval.amount := po:totalValues.netValueDomestic.amount1;
approval.approver := userName(activity:completeUser);
var putOK := putSupplement(approval);
}
}
if (not cast(Boolean, first(putOK, false)))
{ /* contingency handling if approval update failed */

}
}

Genehmigungsantrag zurücknehmen

Damit der Antragssteller einen gestellten Genehmigungsantrag zurücknehmen kann, wählen Sie auf dem Karteireiter Allgemeines der Prozessdefinition die Fähigkeit Erweitert für den Auslöser. Diese Fähigkeit erlaubt dem Antragssteller (Auslöser), den Prozess zu öffnen und die Aktion Unbearbeitet erledigen auszuführen. Durch diese Aktion werden der Prozess und alle offenen Aktivitäten und Aufgaben ebenfalls unbearbeitet erledigt.

Damit der Genehmigungsstatus nicht den Wert IN_APPROVAL nach dem Erledigen des Prozesses behält, prüfen Sie im Endknoten, ob ein Prüfergebnis für den Prozess vorliegt. Ist in process.Result kein Ergebnis eingetragen, dann rufen Sie putSupplement auf, um dem Genehmigungsstatus des Beschaffungsauftrags entweder eine leere Zeichenkette oder den Wert WITHDRAWN zuzuweisen.

function create()
{
if (process.Result = "")
{
var putOK := false;
var approval := getOrCreateSupplement(process.po, "com.cisag.app.purchasing.obj.PurchaseOrderWorkflowApproval");
if (not isNull(approval))
{
approval.status := "WITHDRAWN";
var putOK := putSupplement(approval);
}
}
if (not cast(Boolean, first(putOK, false)))
{ /* contingency handling if approval status update failed */

}
}

Prozessfehler behandeln

Entsteht im Prozess ein Fehler, dann wird der Prozess über den Fehlerknoten beendet. Damit der Genehmigungsstatus nicht den Wert IN_APPROVAL nach einem Prozessfehler behält, rufen Sie im Fehlerknoten putSupplement auf, um dem Genehmigungsstatus des Beschaffungsauftrags den Wert INVALID zuzuweisen.

function create()
{
var putOK := false;
var approval := getOrCreateSupplement(process.po, "com.cisag.app.purchasing.obj.PurchaseOrderWorkflowApproval");
if (not isNull(approval))
{
approval.status := "INVALID";
var putOK := putSupplement(approval);
}
if (not cast(Boolean, first(putOK, false)))
{ /* contingency handling if approval status update failed */

}
}

Genehmigten Beschaffungsauftrag freigeben

Die individuelle Prüfung erlaubt jedem Benutzer, einen genehmigten Beschaffungsauftrag freizugeben. Sie können auch der Prozessdefinition einen Serviceknoten hinzufügen, der sobald eine positive Entscheidung vorliegt, den Serviceknoten automatisch freigibt. Dazu erfassen Sie einen neuen Serviceknoten hinter dem Entscheidungsknoten. In der Aktivitätsdefinition für den Entscheidungsknoten erfassen Sie folgende Übergangsbedingung für die Kante zum Serviceknoten:

process.Result = "APPROVED"

In der Aktivitätsdefinition für den Serviceknoten hinterlegen Sie die Hintergrundanwendung Beschaffungsaufträge freigeben (com.cisag.app.purchasing.order.log.ReleaseOrders). Als Ausdruck für den Anwendungsparameter ConfirmWarnings geben Sie Folgendes an:

true

Als Ausdruck Feld für den Anwendungsparameter Orderkeys geben Sie Folgendes an:

list(createOrderKey(process.po:guid, ZERO_GUID))

In den Deklarationen geben Sie mithilfe des Befehls setJobQueue eine Warteschlange an, es sei denn Sie verwenden die in der Customizing-Funktion Workflow-Management hinterlegte Standard-Warteschlange. Die Hintergrundanwendung soll im Namen eines Benutzers ausgeführt werden, der Berechtigt ist, den Beschaffungsauftrag freizugeben. Falls jeder Benutzer berechtigt ist, einen Beschaffungsauftrag freizugeben und die individuelle Prüfung es nicht unterbindet, können Sie den Antragssteller (Auslöser) verwenden.

function create()
{
setJobUser(process.Initiator);
}

Genehmigten und freigegebenen Beschaffungsauftrag ändern

Einerseits muss ein freigegebener Beschaffungsauftrag geändert werden können, um z. B. geringfügige Preisänderungen oder Zusatzkosten-Positionen für eine evtl. Lieferung zu erfassen. Andererseits darf ein freigegebener Beschaffungsauftrag nicht beliebig geändert werden. Um beiden dieser Anforderungen gerecht zu werden, erfassen Sie ein Workflow-Attribut für den Gesamtnettobetrag zum Zeitpunkt der Genehmigung. Änderungen zu einem genehmigten und freigegebenen Beschaffungsauftrag sind innerhalb eines in der individuellen Prüfung festgelegten Toleranzschwellenwerts erlaubt.

/* prevent changes to approved PO (above threshold value) */
if (approval.status = "APPROVED" and approval.amount > 0)
if ((current:totalValues.netValueDomestic.amount1 – approval.amount) / approval.amount > 1.05) /* threshold 5 % */
sendMessage(current:number, "PUR003", list(current->Header->Type:code, current->Header:number));

Erfassen Sie auch in der Funktion validateDetail Prüfungen, die das Hinzufügen neuer Positionen zu einem genehmigten Beschaffungsauftrag unterbindet.

function validateDetail(
persistent as DataView(com.cisag.app.purchasing.order.model.PurchaseOrderDetail),
current as DataView(com.cisag.app.purchasing.order.model.PurchaseOrderDetail))
{
/* get workflow supplement with approval attributes */
var approval := getByPrimaryKey(CisObject(com.cisag.app.purchasing.obj.PurchaseOrderWorkflowApproval), current:header);

/* prevent entry of new line items of approved PO */
if (approval.status = "APPROVED" and isNull(persistent))
sendMessage(current:number, "PUR004", list(current->Header->Type:code, current->Header:number));
}

Nach Bedarf können Sie das Erfassen neuer Positionen für bestimmte Artikel oder Artikelgruppen, wie z. B. Verrechnungsartikel, erlauben.

In der Funktion validateDetail können Sie auch Mengenänderungen unterbinden. Folgende Bedingung unterbindet eine Erhöhung der Menge:

/* prevent quantity increase of approved PO */
if (approval.status = "APPROVED" and not isNull(persistent))
if (current:totalQuantity.amount > persistent:totalQuantity.amount)
sendMessage(current:number, "PUR005", list(current->Header->Type:code, current->Header:number));

Genehmigten und freigegebenen Beschaffungsauftrag sperren

Um auch größere Änderungen an einem genehmigten und freigegebenen Beschaffungsauftrag durchführen zu können, muss der Benutzer den Beschaffungsauftrag zuerst sperren. Im Status Gesperrt sollen jegliche Änderungen erlaubt sein. Um eine erneute Genehmigung eines gesperrten Beschaffungsauftrags zu erzwingen, erweitern Sie die Bedingung in der individuellen Prüfung um den Statuswechsel von Gesperrt auf Freigegeben.

/* prevent release of PO unless approved */
if (approval.status <> "APPROVED" and ((persistent:status = Status.ORDER_ENTERED or persistent:status = Status.ORDER_HELD) and current:status = Status.ORDER_RELEASED))
sendMessage(current:number, "PUR001", list(current->Type:code, current:number));

/* prevent release of blocked PO unless approved */
if (approval.status <> "APPROVED" and ((persistent:status = Status.ORDER_HELD or persistent:status = Status.ORDER_HELD) and current:status = Status.ORDER_INVALID and current:statusBackup = Status.ORDER_RELEASED and current:invalidReason = Reason.CHANGE_HEADER_STATUS))
sendMessage(current:number, "PUR001", list(current->Type:code, current:number));

Auch ein Wechsel vom Status Storniert auf Freigegeben können Sie auf gleicher Art und Weise prüfen und unterbinden.

Wurde ein genehmigter und freigegebener Beschaffungsauftrag gesperrt, muss ein neuer Genehmigungsprozess gestartet und der Beschaffungsauftrag genehmigt werden, bevor der gesperrte Beschaffungsauftrag freigegeben werden kann. Daher erweitern Sie schließlich die Übergangsbedingung im Startknoten, damit der Genehmigungsprozess auch für gesperrte Beschaffungsaufträge über den Kontextmenü gestartet werden kann.

parameters.object->Type:creationStatus = 1 /* ORDER_ENTERED */ and parameters.object:totalValues.netValueDomestic.amount1 > 1000 and (indexOf("REJECTED|WITHDRAWN|INVALID", getByPrimaryKey(CisObject(com.cisag.app.purchasing.obj.PurchaseOrderWorkflowApproval), parameters.object:guid):status) >= 0 or parameters.object:status = ORDER_HELD)

Beispiel: Workflow-Attribute und Process Mining

Ein weiteres Beispiel für die fachliche Verwendung von Workflow-Attributen ist das Process Mining. Die Workflow-Attribute sind dafür konzipiert, um beim Erfassen und Ändern von Business Objects diese um weitere Informationen ergänzen zu können, die sowohl der Auswertung in Cockpit-Anwendungen als auch dem Process Mining in Comarch ERP Enterprise oder in externen Systemen dienen.

Ein Beispiel von Workflow-Attributen, die ein Business Object um weitere Informationen ergänzen, sind die Reaktions- und Resolvezeiten von Supportanfragen. Da in vielen Kontexten Managed Supplements eines Business Objects der Objektsicht automatisch hinzugefügt werden, können die Workflow-Attribute in Cockpit-Anwendungen uneingeschränkt ausgewertet werden, um z. B. die Einhaltung von Service Level Agreements zu überwachen.

Als Erstes erfassen Sie folgende Workflow-Attribute vom Typ Dezimalzahl:

• reactionTime
• resolveTime

Die Reaktionszeit legen Sie als die Anzahl der Stunden zwischen dem Erfassen der Supportanfrage und dem Erfassen des ersten nach außen Sichtbaren Texts durch einen Support-Mitarbeiter fest. Die Resolve-Zeit legen Sie als die Anzahl der Tage zwischen dem Erfassen und dem Erledigen der Supportanfrage fest. Bei der Berechnung sollen Zeiträume außerhalb der Öffnungszeiten des Support Centers nicht berücksichtigt werden. Ist das Support Center z. B. von 9–18 Uhr an Werktagen geöffnet, und ein Support-Mitarbeiter erfasst den ersten extern sichtbaren Text an einem Montag um 10 Uhr für eine am vorherigen Freitag um 17 Uhr erfasste Supportanfrage, dann solle eine Reaktionszeit von 2,00 Stunden berechnet werden.

Zunächst erfassen Sie eine Aktivitätsdefinition vom Typ Einzelaktivität, um die Reaktionszeit zu berechnen und im Workflow-Attribut reactionTime zu speichern. Die Aktivitätsdefinition erzeugt eine Aktivität für den Bearbeiter System, wenn ein interner Mitarbeiter einen extern sichtbaren Text erfasst bzw. die Sichtbarkeit eines vorhandenen Texts von intern auf extern ändert. Auf dem Karteireiter Ereignisse hinterlegen Sie die Aktivitätsdefinition für das das Ereignis Business Entity des Dependents com.cisag.app.internal.obj.SupportRequestText. Für den Subtyp Einfügen geben Sie folgende Übergangsbedingung an:

parameters.newObject:visibility = 3 /* PUBLIC */ and getByPrimaryKey(CisObject(com.cisag.app.general.obj.Partner), parameters.newObject:creator):type = 1 /* INTERNAL */

Für den Subtyp Ändern geben Sie folgende Übergangsbedingung an:

(parameters.newObject:visibility = 3 and parameters.oldObject:visibility <> 3) and getByPrimaryKey(CisObject(com.cisag.app.general.obj.Partner), parameters.object:creator):type = 1 /* INTERNAL */

In der Funktion create auf dem Karteireiter Deklarationen rufen Sie die Funktion getOrCreateSupplement auf, um die Workflow-Attribute des Workflow-Supplements com.pt.app.internal.obj.SupportRequestWorkflowSupplementabzufragen. Da es für dieses Beispiel eher unwichtig ist, ob andere Aktivitäten die Workflow-Attribute ändern, da jede Aktivität die gleiche Reaktionszeit berechnen würde, fordern Sie keine Schreibsperre an. Danach berechnen Sie die Reaktionszeit (falls diese nicht berechnet wurde) und weisen diese dem Workflow-Attribut reactionTime in der Hash-Tabelle zu. Schließlich rufen Sie putSupplement auf, um die Reaktionszeit auch im Workflow-Supplement zu speichern.

function create()
{
var workflowAttributes := getOrCreateSupplement(parameters.entity, "com.pt.app.internal.obj.SupportRequestWorkflowSupplement", false);
if (not isNull(workflowAttributes))
{
if (cast(Number, workflowAttributes.reactionTime) = 0)
workflowAttributes.reactionTime := supportHours(parameters.entity:updateInfo.createTime, parameters.newObject:create);
var success := putSupplement(workflowAttributes);
}
}

function supportHours(from as Timestamp, until as Timestamp) as Number
{
/* Custom algorithm for calculating the reaction time */
return hours(from, until);
}

In der Funktion supportHours können Sie Logik hinterlegen, um diejenige Zeiten von der Reaktionszeit abzuziehen, in der das Support Center geschlossen war. Beispielsweise könnten Sie einen Werkskalender für das Support Center erfassen und die Funktion workingDays verwenden oder eine passende Java-Methode (in JavaScript) aufrufen.

Die zweite Aktivitätsdefinition ist auch vom Typ Einzelaktivität. Sie berechnet und speichert die Resolve-Zeit, wenn eine Supportanfrage erledigt wird. Hierfür können Sie z. B. eine Ereignisdefinition vom Typ Ändern für das Business Entity com.cisag.app.internal.obj.SupportRequesterfassen:

parameters.newObject:status = 6 and parameters.oldObject:status <> 6 /* COMPLETED */

In der Funktion create auf dem Karteireiter Deklarationen rufen Sie die gleichen Funktionen getOrCreateSupplement und putSupplements wie in der vorherigen Aktivitätsdefinition auf, um die Resolve-Zeit zu berechnen und im Workflow-Attribut resolveTime zu speichern:

function create()
{
var workflowAttributes := getOrCreateSupplement(parameters.entity, "com.pt.app.internal.obj.SupportRequestWorkflowSupplement", false);
if (not isNull(workflowAttributes))
{
if (cast(Number, workflowAttributes.resolveTime) = 0)
workflowAttributes.resolveTime := supportDays(parameters.obje:updateInfo.createTime, now());
var success := putSupplement(workflowAttributes);
}
}

function supportDays(from as Timestamp, until as Timestamp) as Number
{

/* Custom algorithm for calculating the resolve time */
return days(from, until);
}