Erstellung einer Workflow-basierten Applikation mit Bonita

In meinem Blogbeitrag „Wie entwerfe ich eine Workflow-basierte Applikation?“ habe ich vorgestellt, welche grundlegenden Schritte notwendig sind, um eine Workflow-basierte Applikation zu konzipieren. Die Erarbeitung von Geschäftsobjekten, die Definition der Organisationsstruktur sowie die Modellierung des Workflows lassen sich sehr gut bei Nutzung der Open Source BPM Software Bonita von Bonitasoft umsetzen – was in diesem Blogbeitrag beschrieben wird.

Wer selbst „Hand anlegen“ möchte, um das ein oder andere auszuprobieren, der findet am Ende des Beitrags einige nützliche Links zum Download und zu Informationsquellen für die ersten Schritte. Die nachfolgenden Beschreibungen dienen dazu, die grundlegende Vorgehensweise bei der Nutzung von Bonita aufzuzeigen und welche Unterstützung man von einem solchen Tool erhält. Ziel ist es nicht, eine exakte Beschreibung jedes einzelnen „Klicks“ in Bonita wiederzugeben.

Um den Entwurf und die Umsetzung einer Workflow-basierten Applikation vorzustellen, verwenden wir ein einfaches Beispiel: Wir setzen eine Lösung um, mit der Dienstleister einen Leistungsnachweis für ein Projekt als PDF Datei einreichen können und dieser von einem Projektleiter geprüft und ggf. freigegeben wird. Der Projektleiter kann entscheiden, ob eine weitere Freigabe durch den zuständigen Projektmanager notwendig ist, um den Leistungsnachweis final freizugeben.

Wir starten mit der Definition der Daten, die wir für den Workflow benötigen. In Bonita ist dies das Business Data Model, das wir nach der Erstellung eines neuen Projektes in Bonita Studio (dies ist die lokale Entwicklungsumgebung) als erstes anlegen.

Zunächst benötigen wir ein Business Object für den Leistungsnachweis. Relevante Attribute sind:

• Der Dienstleister
• Das Projekt, für das Stunden eingereicht werden
• Der betroffene Monat
• Das betroffene Jahr
• Den Dateinamen des Leistungsnachweises (die Datei wird nicht in der Datenbank abgespeichert)
• Ein Feedback, das dem Dienstleister gegeben werden kann
• Ein Kennzeichen, ob die erste Freigabe erteilt wurde
• Die Benutzer ID des ersten Freigebers (zur Vereinfachung in der Darstellung)
• Der Name des ersten Freigebers
• Der Zeitstempel der ersten Freigabe
• Ein Kennzeichen, ob eine zweite Freigabe erteilt wurde
• Die Benutzer ID des zweiten Freigebers
• Der Name des zweiten Freigebers (zur Vereinfachung in der Darstellung)
• Der Zeitstempel der zweiten Freigabe

Zu den Attributen wird jeweils der Typ definiert (String, Boolean, Long, …) und man legt fest, ob es sich um ein Pflichtattribut handelt.

Da der Workflow basierend auf dem Projekt des eingereichten Leistungsnachweises ermitteln soll, wer für die Freigabe zuständig ist, legen wir noch ein Business Object für das Projekt an. Die Attribute hierfür sind:

• Der Projektname
• Die Benutzer ID des Projektleiters
• Die Benutzer ID des Projektmanagers

Das Ganze könnte dann in Bonita wie folgt aussehen (mit Attributnamen auf Englisch):

Damit haben wir den ersten Entwurf des Datenmodells erstellt. Mit diesem Modell speichern wir, welcher Dienstleister für welchen Monat und welches Projekt einen Leistungsnachweis eingestellt hat und wer ggf. zu welchem Zeitpunkt Freigaben erteilt hat.

Das Business Object Project dient der Verwaltung der Stammdaten der Projekte, zu denen Stunden eingereicht werden können. Hier interessieren uns die beiden Rollen Projektleiter und Projektmanager, die nachher die Freigaben erteilen sollen.

Nun kommen wir zum nächsten Schritt und legen die Organisationsstruktur an – in Bonita Studio Organization genannt. Nach Vergabe eines Namens für die Organisation starten wir mit der Definition der Groups – dies sind die Einheiten der Organisation, die hierarchisch definiert werden können. Für unser Beispiel legen wir folgende Gruppen an:

• Marketing
• Marketing-Service als Subgroup von Marketing (hier werden User zugehörig sein, die Projekte für das Marketing durchführen)
• IT
• Marketing-IT als Subgroup der IT (hier werden User zugehörig sein, die aus IT-Sicht Projekte für das Marketing betreuen)

Darüber hinaus benötigen wir die Rollen, die wir im Tab Roles von Bonita Studio anlegen:

• ProjectLead (für die Projektleiter, die Leistungsnachweise als Erstes freigeben)
• ProjectManager (für Projektmanager, die ggf. eine finale Freigabe eines Leistungsnachweises erteilen)
• Supplier (für den Vertreter des Dienstleisters, der den Leistungsnachweis einreicht)

Das Ergebnis in Bonita sieht wie folgt aus:

Damit sind erst mal die benötigten Elemente der Organisationsstruktur für unser Beispiel definiert. Um das Beispiel später ausführen zu können, müssen noch User angelegt und den Gruppen und Rollen zugeordnet werden. Für unser Beispiel habe ich jeweils einen User für die Rollen Supplier, ProjectLead und ProjectManager angelegt.

(Mit dem Anlegen eines neuen Projektes in Bonita Studio wurde initial eine Organisation angelegt – die kann nach Anlage und Deployment der neuen Organisation einfach gelöscht werden.)

Nun beginnt das eigentliche Modellieren des Workflows – dazu legen wir in Bonita Studio ein neues Process Diagram an. Nun steht die erste Entscheidung hinsichtlich der Pools an. Wir gehen davon aus, dass die Engine nachher den kompletten Workflow steuert und verwenden daher genau einen Pool, dem wir den Namen TimesheetApprovalProcess geben. Als Lanes benötigen wir nun die beteiligten Rollen: zum einen haben wir den Supplier, der den Prozess initiieren wird und einen Leistungsnachweis zur Freigabe in den Workflow gibt. Die Freigabe wollen wir bei Bedarf 2-stufig gestalten und dies ausmodellieren, d.h. wir haben 2 weitere Lanes mit Approver1 und Approver2.

Die für die Lanes gewählten Namen verwenden wir auch, um auf Ebene des Pools die verschiedenen Verantwortlichen als Actors zu definieren und den Lanes zuzuweisen. D.h. Lane Supplier erhält als Zuordnung den Actor Supplier und so fort.

Nun müssen wir noch definieren, wer aus der Organisation als Actor Supplier, Approver1 und Approver2 agieren kann. Für Supplier haben wir eine gleichnamige Rolle definiert. Die erste Freigabe soll der Projektleiter machen, d.h. hier ordnen wir für den Actor Approver1 User mit der Rolle ProjectLead zu. Falls die zweite Freigabe erforderlich wird, führt diese der Projektmanager durch, d.h. Approver2 wird der Rolle ProjectManager zugeordnet. Diese Zuordnung sorgt dafür, dass nur User in der jeweiligen Rolle auch die Aufgaben in der Lane durchführen können.

In Bonita Studio kann diese Zuordnung ganz einfach konfiguriert werden: Im übergreifenden Actor mapping zum Projekt (über das Menü Server – Configure – Actor mapping) sind die definierten Actors aufgelistet, die auf Gruppen, Rollen oder einzelne User abgebildet werden können.

Damit haben wir die Verbindung zu der im vorherigen Schritt erstellten Organisationsstruktur hergestellt. Nun stellen wir eine Verbindung zum im ersten Schritt erstellten Datenmodell her. Für den Pool definieren wir Pool variables. Das können zum einen die Geschäftsobjekte (Business variables) sein, die wir dauerhaft speichern wollen. Oder wir definieren Process variables, die wir nur während des Workflow Ablaufs benötigen und danach verwerfen. Für unser Beispiel benötigen wir das Geschäftsobjekt Timesheet aus dem Business Data Model. Dazu legen wir eine Business variable timesheet basierend auf der Definition im Business Data Model an. Dateien werden bei der Nutzung von Bonita als Elemente an den Workflow gehängt. D.h. wir definieren für den Pool ein Element unter Documents – Bonita bezeichnet dies als Anhang zum Prozess. Weiterhin definieren wir eine Process variable approval2Required, mit der festgehalten wird, wenn der erste Freigeber entscheidet, dass eine zweite Freigabe notwendig ist.

Nun modellieren wir den Ablauf des Workflows. Der Supplier startet den Workflow, d.h. in dessen Lane ist der Start Event, den wir mit StartTimesheetApproval bezeichnen. Die erste Aufgabe lautet Submit Timesheet, in dem der Dienstleister einige Angaben zum Timesheet erstellt (u.a. für welchen Monat und welches Projekt) und den zugehörigen Leistungsnachweis hochlädt. D.h. es handelt sich um eine Aufgabe vom Typ Human.

Nächste Aufgabe ist die Prüfung des Leistungsnachweises durch den Approver1 – d.h. wir legen dort die nächste Aufgabe ebenso vom Typ Human an.

Der weitere Ablauf ist abhängig von der Entscheidung bei der Prüfung des Leistungsnachweises, d.h. wir benötigen nun ein exklusives Gateway. Wenn der Leistungsnachweis freigegeben wurde, erhält der Einreicher eine Mitteilung über den Service Task Send approval notification. Danach ist der Workflow abgeschlossen und endet im Zustand approved.

Wurde der Leistungsnachweis nicht freigegeben (not approved), gibt es wieder 2 Varianten. Entweder wurde der Leistungsnachweis abgelehnt (rejected) oder er muss durch den Approver2 freigegeben werden. Im Fall „abgelehnt“ erhält der Einreicher über einen Service eine Information über die Ablehnung. Der Workflow endet im Status Rejected.

Anderenfalls folgt die Aufgabe Approve timesheet durch den Approver2. Hier modellieren wir ebenso 2 mögliche Entscheidungen, d.h. entweder wird der Leistungsnachweis genehmigt oder nicht. In beiden Fällen werden wieder die Services zur Benachrichtigung des Einreichers genutzt.

Der Ablauf sollte nun also wie folgt aussehen:

Mit den kleinen roten Markierungen zeigt Bonita, dass hier noch etwas zu tun ist. Bei den exklusiven Gateways muss immer ein Default Ausgang vorhanden sein. Das werden wir gleich erledigen, wenn wir den Prozessablauf nochmal schrittweise durchgehen und bei den Aufgaben u.a. definieren, welche Daten der Aufgabe zur Verfügung gestellt werden.

Starten wir mit der Aufgabe Submit timesheet. In Bonita Studio werden im Tab Execution die wichtigsten Elemente einer Aufgabe festgelegt. Im Abschnitt Contract definieren wir die Daten, die in der Aufgabe genutzt oder geändert werden. Dort fügen wir das Business Object Timesheet hinzu und wählen die Attribute aus, die wir tatsächlich benötigen. Das Feedback und die Approval Attribute benötigen wir nicht, der Rest wird selektiert. Ebenso nutzen wir die Option, dass Bonita automatisch die Methoden zum Speichern der geänderten Daten generiert. Ebenso müssen wir die Definition des Dokuments für den Leistungsnachweis hinzufügen.

Der Zwischenstand sieht nun so aus:

Im Abschnitt Form definieren wir das User Interface für den Benutzer. Wenn man die Edit Funktion für die Target form klickt, generiert Bonita Studio eine UI basierend auf den im Tab Contract definierten Daten, wählt entsprechende Widgets und erzeugt Data Bindings. Wenn man will, werden auch Widgets für Attribute erzeugt, die man im Contract nicht ausgewählt hat und entsprechend als Read-only angezeigt werden können. Der UI Designer wird geöffnet und die generierte Form dargestellt. Als Erstes geben wir der Form den Namen submitTimesheetForm. Die Widgets für die Attribute „Supplier“ und „Timesheet Filename“ entfernen wir, weil der Name des Suppliers aus den Usernamen des Anwenders erzeugt und der Name der hochgeladenen Datei verwendet werden.

D.h. das erste einzugebende Attribut ist das Projekt. Generiert wurde ein normales Eingabefeld, wir wollen hier aber eine Auswahl der hinterlegten Projekte. Hierzu verändern wir das Input in ein Select Widget. Nun haben wir im Datenmodell eine Entität für Projekte angelegt, die die zugelassenen Projekte enthalten soll. Aus dieser Entität wollen wir die zulässigen Werte ermitteln. Hierzu legen wir im UI Designer eine neue Variable an, benennen diese projects vom Typ Business Data und wählen als Business Object Project. Anschließend werden vorkonfigurierte „find“ queries angeboten. Für unser Szenario reicht die einfache „find“ Methode, die alle Projekte zurückliefert.

Schließlich konfigurieren wir die Datenquelle des Widgets (die neue Variable projects) sowie den Attributname der anzuzeigenden Werte und des abzuspeichernden Wertes (projectName).

Zur Angabe des Monats und des Jahres wollen wir die Werte schon mal vorbelegen. Hierzu definieren wir eine Javascript Expression Variable formInput, in der wir die Ausgangswerte anhand des aktuellen Datums vorbelegen.

Nun wechseln wir noch in das Tab Operations. Dort sind bereits die Methoden aufgeführt, mit denen nach Durchführung der Aufgabe die Daten im Business Object aktualisiert werden. Hier müssen wir nun 2 Dinge ergänzen: Zum einen wollen wir anhand des Ausführenden der Aufgabe den Supplier setzen. Zum anderen wollen wir noch den Dateinamen des hochgeladenen Leistungsnachweises abspeichern. Hierzu ergänzen wir jeweils die vorgenerierten Methoden.

Beim Attribut Supplier nutzen wir das Code Template „processInitiatorUser“ und erstellen aus Vor-, Nachname und Jobtitle den Supplier Name. Für den Dateiname können wir aus den Vorlagen direkt das Documents Objekt selektieren und das Attribut für den Namen verwenden. Damit haben wir alle notwendigen Aktivitäten für die Aufgabe Submit timesheet abgeschlossen.

Für die Aufgabe Check timesheet müssen wir nun unter Execution ebenso die 3 Bereiche Contract, Form und Operations bearbeiten. Um zu steuern, ob eine 2. Freigabe erforderlich ist, fügen wir noch unter dem Tab Data eine Local variable approval2Required vom Typ Boolean ein.

Unter Contract fügen wir aus der Business Variable timesheet wieder nur jene Elemente hinzu, die wir für die Aufgabe benötigen. Wichtig ist die Angabe, dass wir die Business variable mit Action Edit hinzufügen, d.h. dass das bereits aus der vorherigen Aufgabe erzeugte Business Object angepasst wird (anstatt eine neues Objekt zu erzeugen). Darüber hinaus benötigen eine Boolean Variable für das Kennzeichen, ob ein zweites Approval gewünscht ist.

In der generierten Form können wir ein paar Anpassungen durchführen. Zum einen sollten alle Widgets zu Attributen, die nur read-only sind, entsprechend auf read-only gesetzt werden (bspw. Supplier und Project). Das Attribut Feedback sollte in ein Text Area Widget gewandelt werden, damit dort der Freigabe im Falle einer Ablehnung eine Begründung eingetragen werden kann. Die Checkbox für das zweite Approval kann noch dynamisiert werden: Wenn die Freigabe erteilt wird (Approval1), kann dieses Widget versteckt werden (Eigenschaft hidden abhängig vom Wert von approval1). Somit wird der fachlich sinnlose Fall vermieden, dass beide Optionen angeklickt werden. In der initial generierten UI fehlt auch noch der Zugriff auf den eingereichten Leistungsnachweis. Hierfür fügen wir ein Link Widget auf das Dokument ein – damit kann der User die Datei herunterladen und entsprechend prüfen.

Schließlich prüfen wir noch den Tab Operations: Ggf. überflüssige Mappings, die in der UI nicht verändert werden, können gelöscht werden. Die Daten des Freigebers müssen allerdings in den Methoden noch ergänzt werden. Die ID wird anhand der taskAssigneeId aus dem Execution Context gesetzt, der Name mit einem Code Template userById ermittelt und der Timestamp aus dem aktuellen Timestamp gesetzt.

Eine Besonderheit müssen wir bei dieser Aufgabe noch berücksichtigen: Die Aufgabe muss der richtigen Person zugeordnet werden, d.h. es soll die Rolle Projektleiter des zugehörigen Projektes sein. Hierfür müssen wir einen Actor Filter für die Aufgabe erstellen, der einen einzelnen User zurückliefert (Single User Filter). Mittels einer Query findByProjectName auf das Business Object Project kann mit dem Projektname aus dem Timesheet das Project Objekt ermittelt werden und von dort die ID des Projektleiters entnommen werden.

Nun kommen wir zu den beiden Gateways. Für beide Gateways müssen wir einen Default Ausgang definieren. Für Approval1 wählen wir den Ausgang approved. Für not approved definieren wir noch eine Bedingung – hierfür kann ein Skript hinterlegt werden, dass das Boolean Attribut approval1 im Business Object timesheet prüft. Für Approval 2 needed definieren wir den Fall, dass die zweite Freigabe gewünscht ist, als Default. Für den Fall rejected hinterlegen wir eine Bedingung auf das Attribut approval2Requested, das wir in dem vorherigen Task definiert haben.

Das Bearbeitungsschema setzt sich für die Aufgabe Approve timesheet fort. Im Tab Contract fügen wir aus dem Business Data Model alle relevanten Attribute von timesheet hinzu. In der generierten Form löschen wir ggf. nicht benötigte Attribute und setzen jene, deren Werte nur angezeigt werden sollen, auf read-only. Auch hier fügen wir das Link Widget für den Download des Leistungsnachweises hinzu. Unter Operations löschen wir nicht benötigte Zuweisungen für die read-only Attribute und ergänzen Methoden für das Speichern der Daten des zweiten Freigebers – dies wird analog zum ersten Freigeber umgesetzt.

Analog zur ersten Freigabe soll auch diese Aufgabe direkt dem Projektmanager des Projektes zugeordnet werden, zu dem der Leistungsnachweis eingereicht wurde. Dies erreichen wir wieder über die Definition eines Actor Filters, der anhand des Projektnamens die ID des Projektmanagers ermittelt.

Nun passen wir die Ausgänge des Gateways Approval2 an: approved definieren wir als Default, bei rejected definieren wir die Prüfung auf das Attribut approval2 in der Business variable timesheet.

Die Aufgabe Send approval notification ist ein Service – entsprechend gibt es hier keinen Contract und keine Form. Wir wollen für diesen Service konfigurieren, dass der Einreicher des Leistungsnachweises eine E-Mail mit der Information der Freigabe des Leistungsnachweises erhält. Hierzu müssen wir im Tab Connectors in einen E-Mail Connector konfigurieren. Initial sind noch keine Connectoren installiert – dies kann direkt in Bonita Studio nachgeholt werden. Für diesen Fall wählen wir den „Email“ Connector. Für diesen muss man die entsprechenden SMTP Parameter definieren. Für die E-Mail werden einige Angaben benötigt: die Absender E-Mail Adresse wird als fixer Wert eingetragen, die Empfänger E-Mail Adresse ermitteln wir per Skript vom User, der den Prozess gestartet hat.

Schließlich wird der E-Mail Text erstellt, dessen Text unter Nutzung der Variablen dynamisch gestaltet werden kann. Ebenso kann der Leistungsnachweis als Anhang hinzugefügt werden.

Für diese Aufgabe führen wir die analoge Konfiguration wie für Send approval notification durch, passen aber den Text der E-Mail entsprechend an.

Damit sind wir nun durch den kompletten Prozess durch und wir können den Workflow (Organisation, Business Data Model, Processes) lokal deployen. Um den Workflow erstmalig durchführen zu können, fehlen noch Daten im Business Object Project. Hier gibt es nun verschiedene Möglichkeiten, initiale Daten in die zugehörige Tabelle zu bekommen. Zum einen könnte man schlichtweg im Hintergrund per Skript Daten in der Tabelle anlegen. Wir nutzen aber eine der Möglichkeiten über Bonita. Der einfachste Weg: Wir erstellen einen neuen Prozess, der selbst keine Aufgaben hat sondern nur einen Start und einen Ende Event. Für den Pool definieren wir eine Business variable vom Typ Project und implementieren eine Initialisierungsfunktion (init_project()), die mehrere Project Objekte erzeugt. Mit der Ausführung dieses Prozesses werden damit nur die in der Initialisierungsfunktion erzeugten Objekte in der Tabelle Project angelegt.

Natürlich könnte man auch einen anderen Prozess definieren, in dem ein Anwender über eine Form Daten für Projekte erfasst.

Nun können wir den ersten Workflow testen. Mit dem User in der Rolle Supplier starten wir eine Instanz des Prozesses.

Dadurch entsteht die erste Aufgabe in der ToDo Liste des Suppliers:

Mit der Übernahme der Aufgabe wird die Form zur Einreichung des Leistungsnachweises geöffnet:

Nach Auswahl des Projekts und dem Upload der Datei kann die Aufgabe abgeschlossen werden. Anhand des Projekts wird der Projektleiter ermittelt, der die Prüfung durchführen muss – für ihn wird eine entsprechende Aufgabe erzeugt, die er in seiner ToDo Liste sieht.

Mit der Übernahme der Aufgabe sieht die Form zur Prüfung des Leistungsnachweises wie folgt aus:

Er kann nun entscheiden, ob er freigibt, ein zweites Approval anfordert oder ablehnt. Wir spielen das Szenario durch, dass er eine zweite Freigabe anfordert, d.h. er wählt „Approval 2 Required“ aus und klickt „Submit“. Dadurch wird der Projektmanager zum Projekt ermittelt und ihm die nächste Aufgabe zur Freigabe zugeordnet. Nach Öffnen der Task sieht er diese Form:

Er sieht darin, wer die erste Prüfung vorgenommen hat und kann seinerseits entscheiden, den Leistungsnachweis freizugeben. Für unseren Durchlauf wird die Freigabe erteilt. Damit erhält der Einreicher abschließend eine E-Mail mit der Information zur Freigabe und der Prozess ist abgeschlossen.

Das Beispiel zeigt, wie sich selbst kleine Workflows sehr gut in eine Applikation umsetzen lassen und man mit Bonita recht schnell zum Ziel kommt (auch wenn oben viele Dinge einfach gehalten wurden und diese für eine produktive Version sicherlich anders umgesetzt würden – und es natürlich noch viele Optionen gibt, den Ablauf anders zu gestalten). Insbesondere ist die Durchgängigkeit von der Modellierung zur Umsetzung hervorzuheben. Die Geschäftsobjekte, die Organisationsstruktur mit den daran hängenden Verantwortlichkeiten sowie der Ablauf an sich lässt sich gut mit den Fachbereichen abstimmen.

Die Umsetzung auch von vermeintlich kleinen Prozessen ist effizient und sorgt bei den Prozessbeteiligten für Struktur und Nachvollziehbarkeit.

• Bonita Studio Installation
• Bonita Getting Started Tutorial
• Bonita Community Q&A