Mit dem Releasewechsel auf Bonita 7 sind einige Neuerungen eingeführt worden. Dabei handelt es sich um grundlegende, konzeptionelle Erweiterungen, die auch unabhängig von dem konkreten System interessant sind. Erfreulicherweise funktionieren sämtliche mit Bonita 6 erstellte Prozesse nach wie vor, so dass auch alle Beispielprozesse aus dem BPMS-Buch unverändert weiter verwendet werden können. Im Folgenden werden die Neuerungen kurz im Überblick beschrieben. In einem zweiten Beitrag werden sie anhand des im Buch zur Einführung verwendeten Angebotsprozesses erläutert.
Die wichtigsten Neuerungen in Bonita 7 sind:
- Business-Objekte auf Grundlage eines prozessübergreifenden Business-Daten-Modells
- Contracts (Verträge) zur losen Kopplung der Benutzungsoberfläche
- Nutzung des REST-API zur Anbindung der Benutzungsoberfläche
- UI-Designer (Oberflächen-Editor) auf Basis der Web-Frameworks AngularJS und Bootstrap
- Applications (Anwendungen), die unabhängig vom Bonita-Prozessportal genutzt werden können.
Business-Objekte
Bei einem Business-Objekt handelt es sich um einen Datensatz, wie z. B. die Daten eines Kunden oder eines Auftrags. Diese Daten können in Prozessen angelegt oder bearbeitet werden. Bislang wurden die von einem Benutzer eingegebenen Daten in Prozessvariablen der jeweiligen Prozessinstanz gespeichert. Auf die Werte dieser Prozessvariablen kann in jeder Aktivität der Prozessinstanz zugegriffen werden. Allerdings existieren sie nur innerhalb der Prozessinstanz und stehen nach ihrer Beendigung nicht mehr zur Verfügung. Möchte man die Daten auch außerhalb und nach Abschluss der Prozessinstanz verfügbar machen, so muss der Prozess die Werte der Variablen in eine Datenbank schreiben. Hierzu stehen Datenbank-Konnektoren zur Verfügung. Die Prozessentwickler müssen sich selbst um eine geeignete Datenbankstruktur kümmern und die erforderlichen SQL-Skripte schreiben. Werden die Daten in der Datenbank von einer anderen Anwendung geändert, so bekommt der Prozess nichts davon mit.
Bei Business-Objekten ist dies anders, sie stehen auch über einzelne Prozessinstanzen hinaus zur Verfügung. Hierzu erstellt man zunächst unabhängig von einem einzelnen Prozess ein Business-Daten-Modell. Dies enthält die für ein Business-Objekt, wie z. B. einen Kunden, benötigten Attribute mit ihren Datentypen. Auch komplexe Strukturen, wie z. B. Listen oder Referenzen auf andere Objekte sind möglich. Bonita generiert hierfür die Tabellenstrukturen in einer Datenbank, einige Standardabfragen zur Suche nach Objekten und Java-Klassen, mit denen in einem Prozess auf die Objekte zugegriffen werden kann.
Im Prozessmodell müssen dann jeweils Business-Variablen für die zu verwendenden Typen von Business-Objekten angelegt werden. Mit Hilfe der von Bonita generierten Java-Klassen und Zugriffsmethoden können im Prozess Attributwerte gelesen und geändert werden. Mit den Business-Variablen kann somit ganz ähnlich umgegangen werden wie mit herkömmlichen Prozessvariablen. Allerdings werten die Werte jeweils direkt aus der Datenbank gelesen bzw. dort hineingeschrieben, ohne dass sich der Prozessentwickler darum kümmern muss.
Contracts
Waren der bisherige Formular-Designer und die Benutzungsoberfläche recht eng mit dem BPM-System integriert, so sind diese nun nur noch lose gekoppelt. Der Vorteil: Es wird erleichert, Oberflächen mit ganz anderen Technologien zu entwickeln und diese z. B. auch in externe Anwendungen auszulagern. Das hat andererseits zur Folge, dass man z. B. im neuen UI-Designer weniger gut unterstützt wird. So konnte man im alten Formular-Designer etwa die zur Verfügung stehenden Prozessvariablen einfach aus einer Liste auswählen. Durch die lose Kopplung steht diese Information nicht mehr direkt zur Verfügung.
Damit sichergestellt werden kann, dass das zu einem Arbeitsschritt gehörende Formular auch die benötigten Daten zurückliefert, muss man für jeden Benutzertask einen Contract anlegen, d. h. einen Vertrag, der angibt, welche Daten von dem Formular zurückgeliefert werden müssen. In der Regel handelt es sich bei einem solchen Vertrag um einen Ausschnitt aus dem Business-Daten-Modell, der lediglich die Attribute enthält, deren Werte von dem Formular zurückgeliefert werden müssen. Hält das Formular den Vertrag nicht ein, so wird eine Fehlermeldung zurückgeliefert. Anhand des Contracts wissen die Formular-Entwickler genau, welche Daten gesendet werden müssen.
Der Contract eines Formulars kann aus dem Business-Daten-Modell generiert werden, wobei man die Attribute, die in dem betreffenden Task nicht benötigt werden, einfach herauslöscht. Dabei werden auch die notwendigen Skripte und Operationen generiert, mit denen die vom Formular zurückgelieferten Werte in die Business-Objekte geschrieben werden. Diese Skripte und Operationen lassen sich anschließend manuell bearbeiten. Spätere Änderungen des Datenmodells oder der Contracts werden nicht automatisch berücksichtigt, sie erfordern manuelle Anpassungen.
REST-API
Bei dem REST-API handelt es sich um eine Programmierschnittstelle (Application Programming Interface, API) zum BPM-System. REST (Representational State Transfer) ermöglicht es, die unterschiedlichen Ressourcen wie Prozesse, Prozessinstanzen, Tasks usw. jeweils über eine URL zu erreichen, ihre Werte abzufragen und zu ändern, Prozesse zu starten usw. Das REST-API von Bonita ist nicht neu. Damit ist es möglich, andere Anwendungen zu programmieren, die auf das BPMS zuzugreifen.
Neu ist in Bonita 7, dass das REST-API auch zur Kommunikation der Benutzungsoberfläche mit der Process Engine verwendet wird. So werden die in einem Formular anzuzeigenden Daten per REST-Aufruf vom BPMS angefordert. Schickt man ein Formular – etwa mittels eines „OK“-Button – ab, so werden die Formular-Daten ebenfalls mittels eines REST-Aufrufs übermittelt. Bei diesem Aufruf prüft das BPMS, ob der Contract des betreffenden Tasks eingehalten worden ist, d. h. ob alle geforderten Daten geliefert worden sind.
Die Nutzung des API für die Oberflächenanbindung bietet eine hohe Flexibilität. So können Daten an einen Tasks nicht nur bei seinem Start übergeben werden. Man kann man auch während der Formular-Bearbeitung weitere Daten anfordern, z. B. in Form einer Suche, deren Ergebnis direkt im selben Formular angezeigt werden soll. Zudem kann man die Standard-Bonita-Oberfläche durch eine ganz andere Oberfläche ersetzen, die auch auf einer komplett anderen Technologie basieren kann. Aus Sicht der Process Engine ist es egal, woher die REST-Aufrufe stammen.
UI-Designer
Mit Hilfe des neuen UI-Designers kann man Formulare und Webseiten für eine Benutzungsoberfläche erstellen, die auf HTML, JavaScript und CSS (Casscading Style Sheets) basiert. Dabei kommen die Frameworks AngularJS und Bootstrap zum Einsatz. AngularJS erleichtert die Entwicklung interaktiver Webanwendungen. Bootstrap bietet Gestaltungsvorlagen und ermöglicht ein responsives Webdesign, d. h. die Seitendarstellung wirdn automatisch an das jeweilige Endgerät, wie z. B. PC, Tablet oder Smartphone angepasst.
Der UI-Editor, der komplett im Browser läuft, bietet wie der bisherige Formular-Editor die Möglichkeit, verschiedene Interaktionselemente auszuwählen und im Formular zu platzieren. Aufgrund der losen Kopplung ist es aber nicht mehr möglich, direkt auf die im Prozess verfügbaren Variablen zuzugreifen. Die Daten müssen vielmehr über REST-Aufrufe abgerufen und im Formular mit Hilfe von AngularJS-Ausdrücken u. ä. verarbeitet werden. Für die mit dem BPMS ausgetauschten Daten wird das JSON-Format verwendet.
Man kann sich von Bonita Formulare für den Prozess-Start und die einzelnen Benutzertasks generieren lassen. Hierbei werden für die im jeweiligen Contract festgelegten Attribute geeignete Eingabe-Elemente erzeugt und die notwendigen Adressen und Einträge zum Zugriff auf die Business-Objekte und zur Rückgabe der eingetragenen Werte angelegt. Das generierte Formular kann dann weiter bearbeitet werden. In der Regel dürfte dies auch erforderlich sein. Auch hier müssen spätere Änderungen in Datenstrukturen und Contract ggf. manuell nachgezogen werden, da bei einer Neugenerierung des Formulars sämtliche durchgeführten Anpassungen verloren gehen würden.
Die Konfiguration der Eingabefelder und anderer Interaktionselemente ist nicht ganz einfach. Recht schnell gelangt man an den Punkt, wo man sich etwas genauer mit JavaScript und AngularJS auseinandersetzen muss. Auf der anderen Seite bietet die neue Oberfläche sehr viel Flexibilität. So kann man eigene Interaktionselemente mit beliebigem Verhalten entwickeln und praktisch jegliche denkbare Oberflächenfunktionalität programmieren – vorausgesetzt man hat Oberflächenprogrammierer mit den entsprechenden Kenntnissen zur Verfügung.
Immerhin kann auch ein Prozessentwickler ohne diese Kenntnisse mit Hilfe des UI-Designers zumindest ganz einfache Formulare erstellen, die z. B. in einem Prototyp eingesetzt werden können. Verläuft der Test des Prozesses erfolgreich, so kann man im zweiten Schritt die aufwändigere Weiterentwicklung zu einer gut bedienbaren Oberfläche vornehmen.
Applications
Häufig geht man bei einem BPMS davon aus, dass die Prozessbeteiligten ein Prozessportal nutzen, bei dem sie die jeweils anstehenden Aufgaben aus einer Taskliste auswählen und das zugehörige Formular öffnen. In vielen Fällen ist dies jedoch nicht die geeignete Oberfläche. So wird man etwa einem Kunden auf einer Website keine Taskliste anzeigen, sondern eine Übersicht über seine Bestellungen mit dem jeweiligen Bearbeitungsstand.
Mit dem UI-Designer kann man auch Webseiten für derartige „Applications“ (Anwendungen) entwickeln. Hierbei kann man u. a. die für das Business-Daten-Modell generierten Datenbank-Abfragen verwenden und über einen REST-Aufruf etwa alle Bestellungen mit dem Status „offen“ anfordern. Ebenso kann man aus einer solchen Anwendung heraus den nächsten Schritt einer wartenden Prozessinstanz anstoßen oder einen Prozess neu starten.
Eine solche, aus ein oder mehreren Webseiten bestehende Anwendung, kann auf dem Bonita-Server laufen. Jede Anwendung verfügt über eine eigene URL, über die sie direkt aufgerufen werden kann. Bonita überprüft dabei, ob die notwendigen Benutzerrechte vorhanden sind.
Fazit
Mit der Version 7 geht Bonita einen großen Schritt hin zu einer Entwicklungsplattform für prozessorientierte Komplett-Anwendungen. Mit der separaten Datenhaltung für Business-Objekte, der losen Kopplung zwischen Oberfläche und BPMS und der frameworkbasierten Weboberfläche geht die Plattform weit über ein klassisches Workflow-System hinaus. Erkauft werden die neuen Möglichkeiten mit einer höheren Komplexität und einer Vielfalt verschiedener Technologien. Das Erlernen der Prozessentwicklung mit Bonita wird schwieriger, und es dürfte nicht sehr viele Entwickler geben, die in allen verwendete Technologien (Java, Groovy, JavaScript, AngularJS etc.) gleichermaßen versiert sind. Meist wird man daher gemischte Teams bilden müssen, in denen alle benötigten Qualifikationen vorhanden sind.
Der UI-Designer ist noch nicht sehr benutzerfreundlich. Es ist vor allem zu Beginn recht mühsam, herauszufinden, welche Angaben in welchem Format gemacht werden müssen, um ein bestimmtes Ziel zu erreichen. Hilfreich sind hierbei das von Bonita bereitgestellte Video-Tutorial und das einführende Beispiel in der Dokumentation – wobei leider einige Details nicht genauso funktionierten wie dort beschrieben.
Zum Beitrag „Business-Objekte, Verträge und Web-basierte Formulare in einem Beispielprozess“.