Zum Inhalt

Aktivitäten zuweisen

Zuweisung von Aktivitäten zu Prozessschritten

Bisher wurde dem Geschäftsprozess nur Bearbeiter und Datenelemente zugewiesen. Dies kann durchaus hilfreich sein, um einen ersten Eindruck des Geschäftsprozesses zu bekommen (analog Rapid Prototyping). Für einen echten Produktiveinsatz müssen jedoch Aktivitäten bzw. Services in den Prozess integriert werden. Hierzu dient das Activity Repository (Tab, links oben) in dem alle für dieVerwendung in Geschäftsprozessen zur Verfügung stehenden Komponenten, Funktionen und Services aufgelistet sind.

Um eine Aktivität zu integrieren, wird diese angewählt und per Drag & Drop aus dem Activity Repository heraus auf den entsprechenden Prozessschritt gezogen.

  1. Prozessschritt „Urlaubsantrag ausfüllen": Hier wird ein User-Formular vom Antragssteller ausgefüllt.
    de.aristaflow.form.Form aus dem Activity Respository wählen User Form anklicken, Maustaste gedrückt halten, auf den Prozessschritt ziehen und Maustaste loslassen.
    Es öffnet sich automatisch ein Wizard, der Sie durch die weiteren Schritte führt: Im Feld Node Description kann für den Prozessschritt eine genauere Beschreibung der auszuführenden Tätigkeit hinterlegt werden. Diese wird zur Ausführungszeit dem Bearbeiter des einzelnen Schrittes angezeigt. Ebenso kann auch hier direkt eine Bearbeiterzuordnungsregel über Staff Assignment Rule angegeben werden. Durch Klicken von Next gelangt man zu der im folgenden Screenshot gezeigten Wizardseite. Hier haben Sie einen Überblick über die zu lesenden („Input Parameters") und schreibenden („Output Parameters") Parameter. Die nachfolgende Wizardseite dient dem automatischen Verschalten von Aktivitäten mit dem Datenfluss. Es werden automatisch diejenigen Datenelemente (bereits mit dem Knoten verbundene markiert mit „*") ausgewählt/angezeigt, die mit den Parametern der Aktivität kompatibel sind. Im hier gezeigten Fall bestehen bereits alle Datenelemente, so dass der Wizard sofort mit Finish beendet werden kann.

  2. Prozessschritt „Urlaubsantrag prüfen": de.aristaflow.form.Form User Form User Form (analog zu Schritt a, den zugewiesenen Bearbeiter Staff Assignment Rule  „NodePerforming--OrgPositonID"nicht ändern). In diesem Schritt wird der Parameter „Entscheidung" geschrieben, also über den Urlaubsantrag entschieden.

  3. Prozessentscheidung (1. XOR Verzweigung) „genehmigt /abgelehnt":
    Hierbei handelt es sich um eine Verzweigungsaktivität mit der von einfachen Verzweigungsentscheidungen bis hin zu komplexen Geschäftsregeln (Business Rules) jegliche Form von Verzweigungs-entscheidungen definiert werden können.
    de.aristaflow.rules.XOR XOR Predicate XOR Predicate. Bei Genehmigung wird der obere Zweig, bei Ablehnung der untere durchlaufen. Dafür wird der Parameter „Entscheidung" gelesen und bei true auf den oberen Zweig („genehmigt"), bei false auf den unteren („abgelehnt") gemappt.
    Nach der allgemeinen Einführungsseite gelangt man über zweimaliges Drücken von Next zu der im Folgenden gezeigten Wizardseite. Hier können die Parameter definiert werden, die für eine Verzweigungsentscheidung herangezogen werden können. Da der Prozessschritt bereits eine eingehende Datenkante besitzt, wird hierzu automatisch ein kompatibler Parameter angelegt. Bei dem Ausgabeparameter „Decision" handelt es sich um einen Systemparameter, der bei dieser Aktivität immer vorhanden ist. Sie können ihn hier ignorieren. Auf der nächsten Wizardseite werden die Dimensionen der „Entscheidung" festgelegt. Durch Selektion des Textfeldes neben Dimension 1 und anschließendem Doppelklick auf Variables „Entscheidung" wird die erste Dimension der Verzweigungsentscheidung angelegt. Da es sich im vorliegenden Beispiel um eine einfache Auswertung eines bool'schen Wertes handelt, genügt die angelegte Dimension bereits. Auf der nächsten Seite werden die Prädikate und die Werte für die angelegte Dimension angegeben. Wie aus dem Screenshot ersichtlich, berechnet der XOR-Wizard automatisch, welche möglichen Werte noch nicht berücksichtigt wurden. Im hier gezeigten Fall wurde bisher nur der Fall „Entscheidung" = true abgedeckt. Um den Wert „Entscheidung" = false anzulegen wird über den Button Add Predicate ein neues Prädikat hinzugefügt und der Wert false gewählt. Alternativ können die fehlenden Werte auch über den Button Add all automatisch hinzugefügt werden. Der Wizard bestätigt sofort, dass alle Werte abgedeckt wurden. Auf der nächsten Wizard-Seite müssen den Prädikaten Entscheidungs-IDs zugewiesen werden. Hierzu selektiert man „Entscheidung" = true und wählt Add Auto (rechts Mitte) um eine automatische ID anzulegen oder man gibt im Textfeld eine eigene ID an und wählt Set. Wir wählen eine eigene ID und nennen diese „genehmigt". Analog „Entscheidung" = false setzen wir auf ID „abgelehnt". Die folgende Seite zeigt die erstellte Verzweigungsentscheidung nochmals im Überblick. Im nächsten Schritt werden die Verzweigungs-IDs mit den ausgehenden Kanten des XOR-Entscheidungsknotens verknüpft. Hierzu wird die Verzweigungs-ID „genehmigt" der Kante mit dem Zielknoten „Genehmigung erhalten" und die ID „abgelehnt" der Kante mit dem Zielknoten „Antrag ändern?" zugewiesen. Im letzten Schritt des Wizards werden die angelegten Parameter mit dem über den bereits bekannten Mapping-Dialog mit dem Datenfluss verbunden. Bei dem Output-Parameter Decision handelt es sich um einen Systemparameter, der nach Ausführung der Verzweigungsentscheidung den Wert der Entscheidung enthält. Hier wird gespeichert, welche Kante (Edge 0 oder Edge 1) genommen wird. Da diese intern verwendet wird, brauchen wir uns darum nicht kümmern und lassen es auf \<NEW DATALEMENT>, also vom System neu generieren. Über Finish wird der Wizard beendet. An den ausgehenden Kontrollflusskanten des Verzweigungsknotens ist nun zu erkennen, bei welchem Entscheidungswert welcher Zweig genommen wird. Außerdem erkennt man aus den blauen und grünen Symbolen rechts unter den Knoten, dass Agents bzw. Aktivitäten und bei „Urlaubsantrag ausfüllen" auch schon eine Beschreibung hinterlegt wurde.

  4. Prozessschritt „Genehmigung erhalten":
    de.aristaflow.form.Form User Form User Form (analog zu Schritt a, hier als Bearbeiter „InstanceInitiator-AgentID" lassen). Bei Genehmigung wird der Antragssteller „Meier" hier über seinen genehmigten Urlaub informiert.

  5. Prozessschritt „Urlaubskonto aktualisieren":
    de.aristaflow.form.Form User Form User Form (analog zu Schritt a, den zugewiesenen Bearbeiter Sachbearbeiter „Schmidt" nicht ändern). Der Sachbearbeiter aktualisiert das Urlaubskonto. Dazu liest er die Daten „Antragssteller", „Urlaubsbeginn" und „Urlaubsende".

  6. Prozessschritt „Urlaubsantrag ändern? ": de.aristaflow.form.Form User Form User Form (analog zu Schritt a, als Bearbeiter „InstanceInitiator-AgentID" lassen). Bei Ablehnung kann der Antragssteller „Meier" die Urlaubsdaten ändern und einen neuen Urlaub beantragen. In diesem Schritt entscheidet er, ob er einen neuen Antrag stellen möchte oder nicht. Hier wird der Parameter „neuerAntrag" geschrieben.

  7. Prozessentscheidung (2. XOR Verzweigung) „Neuer Antrag?":
    de.aristaflow.rules.XOR XOR Predicate
    XOR Predicate Hier haben wir zwei Parameter; „Entscheidung" und „neuerAntrag". Diese werden gebraucht, um zu entscheiden, ob der Prozess beendet oder der Graph noch mal durchlaufen wird. Wenn die „Entscheidung" = true ist, wird der Parameter „neuerAntrag" nicht mehr benötigt und der Prozess wird automatisch beendet. Diesen Fall mappen wir auf den „Nein" Zweig, also „neuer Antrag?" -> Nein. Nur der Fall „Entscheidung" = false und „neuer Antrag" = true wird auf den Zweig „ja" gemappt, d.h. „neuer Antrag?" -> Ja. Wir nehmen „Entscheidung" als erste Dimension: -> Doppelklick auf „Entscheidung", „neuerAntrag" als zweite Dimension: ->Klick auf Add dimension. -> Doppelklick auf „neuerAntrag" -> Next. Nun alle möglichen Prädikate beider Dimensionen anlegen. 1. Dimension wird schon angezeigt. Wir fügen automatisch die noch fehlenden Prädikate hinzu -> Klick auf Add all Wählen der zweiten Dimension aus Combo Box rechts oben -> Klick auf Add all. Im nächsten Schritt legen wir die Entscheidungs-IDs fest. Wir sehen alle möglichen Kombinationen von Prädikaten. Nur der Fall „Entscheidung"= false mit „neuerAntrag" = true wird auf Entscheidungs-ID „ja" abgebildet. Alle anderen Fälle werden auf die Entscheidungs-ID „nein" gesetzt. Die nächste Wizardseite dient nur zur Übersicht. Zum Schluss werden die Entscheidungs-IDs mit den ausgehenden Kanten verknüpft. Dazu Entscheidungs-ID „ja" mit der Kante Edge code: 1 verbinden, Entscheidungs-ID „nein" mit der Kante Edge code: 0, die zum Ende führt.

Mit dem Zuweisen der Aktivitäten zu den Knoten ist die Prozessmodellierung abgeschlossen.

Im nächsten Schritt folgt das Deployment des Prozesses auf den Server.

Ergebnis der gesamten Prozessmodellierung: