Einer der Vorteile des Einsatzes von BPMN ist der direkte Übergang von der Analyse über das Design direkt zur Implementierung der Lösung.
Ermöglicht wird dies durch die sogenannten BPMN-Engines. Eine BPMN-Engine ist eine Softwarekomponente, die ein gezeichnetes BPMN-Modell interpretieren kann. Sie bietet Werkzeuge für die Einbindung von Systemen, die für die Lösung der technischen Aufgaben eines Prozesses zuständig sind, sowie Unterstützung bei der Spezifikation und Bearbeitung von Benutzeraufgaben durch benutzerdefinierte Rollen. Wenn ein Kunde Geschäftsprozesse automatisieren und rationalisieren muss und nicht über ein größeres Informationssystem verfügt, um diese abzudecken, ist der Einsatz einer BPMN-Engine die optimale Lösung.
Auf dem Markt gibt es eine Reihe von BPMN-Implementierungen, die auf verschiedenen Technologien basieren und von unterschiedlicher Qualität sind. Siehe zum Beispiel den Vergleich: https://www.itcentralstation.com/categories/business-process-management. In der Vergangenheit haben wir jBPM verwendet, aber in den letzten Jahren sind wir auf die Lösung von Camunda umgestiegen, und wir sind wirklich begeistert davon.
Camunda ist ein Paket von Werkzeugen, das als Camunda-Plattform bezeichnet wird und Tätigkeiten abdeckt, die von der Prozessanalyse (DESIGN) über den Einsatz modellierter Prozesse als Teil von Informationssystemen (AUTOMATE) bis zur Optimierung ihrer Leistung (IMPROVE) reichen:
Die Camunda-Plattform ist wie üblich in einer kostenlosen Community-Version und einer kostenpflichtigen Enterprise-Version erhältlich.
In der vorherigen Abbildung habe ich die verschiedenen Tools farblich markiert:
- Rot ist auch in der Enterprise-Version enthalten.
- Orange ist auch in der Community-Version enthalten, allerdings mit eingeschränkter Funktionalität
- Grün ist auch in der Community-Version voll funktionsfähig
Das Tolle ist, dass die Community-Version so umfangreich, funktional und dokumentiert ist, dass wir damit schon mehrere Projekte erfolgreich umsetzen konnten.
In diesem Blog geht es um die Nutzung der Community-Version der Camunda-Plattform. Ich werde Sie einführen in:
- Camunda Modeler – Werkzeug zum Zeichnen von Prozessen
- Camunda Engine – Komponente für die Bereitstellung von gezeichneten Prozessen. Wir werden uns diese Komponente genauer ansehen:
- Empfohlenes Technologiepaket – womit können wir es mischen?
- Datenbanktransaktionen – wie es dazu kam
- Einsatzmöglichkeiten – welche verschiedenen Situationen können damit bewältigt werden?
- Hardware-Anforderungen – wie viel Eisen wird benötigt
- Camunda Cockpit – ein Werkzeug zur Überwachung der eingesetzten Prozesse
Ich werde die Aufgabenliste nicht vorstellen, da diese für den kommerziellen Einsatz zu schlicht ist und wir unsere eigene schönere Aufgabenliste mit Angular implementieren werden.
Camunda Modellierer
Camunda Modeler ist ein sehr schöner, voll funktionsfähiger BPMN-Editor. Er bietet alle Elemente des BPMN 2.0 Standards:
Die verschiedenen Teile des Camunda Modeler:
- A – Oben links befindet sich ein Panel mit den wichtigsten BPMN-Elementen (Ereignisse, Gates, Aufgaben, Unterprozesse, Datenobjekte, Pools,…)
- B – Rechts neben dem ausgewählten Element werden Symbole angezeigt, über die Sie die Auswahl treffen können:
- Fahren Sie fort, indem Sie das nächste Element auswählen – obere 2 Reihen von Symbolen – siehe angezeigtes Kontextmenü
- C – Bestimmen Sie den Typ des gezeichneten Elements – Schlüsselsymbol
- Element abbrechen – Papierkorbsymbol
- D – Im rechten Teil können Sie die Parameter des ausgewählten Elements eingeben
Im Camunda Modeler ist es möglich, BPMN-Modelle, die in anderen Analysewerkzeugen erstellt wurden, zu bearbeiten, sofern sie dem BPMN 2.0 Standard entsprechen.
Wir haben dies zum Beispiel erfolgreich mit dem weit verbreiteten Enterprise Architect getestet.
Neben der Speicherung in BPMN-Dateien können gezeichnete Modelle auch als Bilder exportiert werden, was eine praktische Funktion bei der Erstellung von Dokumentationen ist.
Camunda Engine – empfohlener Technologie-Stack
Die vom Hersteller empfohlenen Komponenten, die mit der BPMN-Engine arbeiten (der sogenannte Technologie-Stack), sind für die meisten Projekte mit mittleren Anforderungen ausreichend:
Die verschiedenen Schichten der Architektur:
Browser |
Camunda Tasklist – GUI for viewing user lists created within running process instances and Camunda Cockpit – an administrative GUI for monitoring the Camunda Process Engine and addressing incidents – are implemented as a web client that can be used from the following supported web browsers:
- Google Chrome
- Mozilla Firefox
- Internet Explorer 11
- Microsoft Edge
|
Camunda REST |
The interface implemented as a REST API provides services for:
- Managing instances of deployed processes
- Sending messages and signals to running process instances
- Allowing workers to process asynchronous tasks of processes
|
Camunda Engine |
Camunda Process Engine – the main component of the architecture – is implemented in Java. Supported Java versions:
- Oracle JDK 8+
- IBM JDK 8+
- OpenJDK 8+
|
Relational Database |
A relational database is used to persist the current state of individual process instances. Communication between the Process Engine and the database is done via the JDBC interface. Supported relational databases:
- Microsoft SQL Server 2012/2014/2016/2017
- MySQL 5.6/5.7
- MariaDB 10.0/ 10.2 / 10.3
- Oracle 11g / 12c / 18c /19c
- IBM DB2 10.5 / 11.1 (excluding IBM z/OS for all versions)
- PostreSQL 9.4 / 9.6 / 10.4 / 10.7 / 10.13 / 11.1 / 11.2
- Amazon Aurora PostreSQL compatible with PosgreSQL 9.6 / 10.4 / 10.7 / 10.13
- H2 1.4
|
Camunda Engine – Datenbanktransaktionen
Der in der relationalen Datenbank persistierte Zustand einer bestimmten Prozessinstanz wird in Datenbanktransaktionen geändert, die durch die Wartezustände des ausführenden Prozesses begrenzt sind. Zum Beispiel:
In diesem Prozess wird der persistierte Zustand des Prozesses geändert, wenn die Operationen aus der abgeschlossenen Benutzeraufgabe (Lieferadresse bereitstellen) erfolgreich ausgeführt werden
bis hin zum Timer (Warten bis zum nächsten Arbeitstag). Tritt innerhalb dieser Operationen eine Ausnahme auf, setzt der Prozesslauf die Bearbeitung dieser Ausnahme fort oder verbleibt im Fehlerzustand = Vorfall.
Wartezustände, die Transaktionen von dem Prozess trennen, auf den sie warten:
- Eine bestimmte Nachricht (adressiert an diese Prozessinstanz)
Modelliert durch BPM-Elemente: Empfangsaufgabe, Nachrichtenereignis, ereignisbasiertes Gateway,
- Ein spezifisches Signal (für eine bestimmte Gruppe von Instanzen)
Modelliert durch BPM-Elemente Signal Events, Event-based Gateway,
- Erledigung der Benutzeraufgabe durch den Benutzer
Modelliert durch das BPM-Element Benutzeraufgabe,
- Ablauf der angegebenen Zeit
Modelliert durch das BPM-Element Timer Event,
- Durchführung einer veröffentlichten Aufgabe
Modelliert durch BPM-Element: externe Aufgaben.
Transaktionen können auch durch BPMNelement-Parameter gesteuert werden, aber das würde den Rahmen dieses Blogs sprengen.
Camunda Engine – Einsatzmöglichkeiten
Abhängig von der Größe, der Architektur und den Anforderungen des Systems, auf dem die Camunda Engine eingesetzt werden soll, werden 3 Einsatzmöglichkeiten unterstützt:
Type |
Architecture |
Description |
Embedded |
|
The Process Engine is deployed as a library within the Java application. The Java application utilizes its services through the provided Java API. |
Standalone Process Engine server |
|
The Process Engine is deployed on a separate server. Applications from other servers use the Process Engine’s services as a network service. In such a deployment, the provided REST API interface can be utilized. A different communication layer can be built on top of it (e.g., SOAP WS, JMS, etc.) if necessary. |
Shared within the container |
|
The Process Engine is deployed as an application to an application server. Applications deployed on the server use the Process Engine’s services as application server services. Supported application servers:
- Apache Tomcat 7.0 / 8.0 / 9.0
- JBoss EAP 6.4 / 7.0 / 7.1 / 7.2
- Wildfly Application Server 10.1 / 11.0 / 12.0 / 13.0 / 14.0 / 15.0 / 16.0 / 17.0 / 18.0
- IBM WebSphere Application Server 8.5 / 9.0 (iba Enterprise Edition)
- Oracle WebLogic Server 12c (12R1,12R2) (iba Enterprise Edition)
|
Camunda Engine – Hardwareanforderungen
Faktoren, die die Hardwareanforderungen der Camunda Engine bestimmen:
|
FACTOR |
IMPACT |
#1 |
The average time between the start of process instances is necessary to estimate the number of process instances started per second. |
|
#2 |
Average runtime of a single process instance. In conjunction with factor #1, it determines the number of concurrently active process instances. |
|
#3 |
Number of concurrently accessing clients: The number of users working in parallel on user tasks and accessing external modules and systems. |
|
#4 |
History Level Configuration of the detail level recorded for executing process instances. |
|
Empfohlene Hardware-Konfigurationen je nach Bedarf:
Degree |
|
|
Low |
A small server is sufficient for most cases. Running fewer than 100 process instances per second. |
- 1-2 CPU
- 1-8 GB RAM
- 0,5-1GB HDD space
|
Medium |
Medium-sized server. Running more than 100 process instances per second. |
- 2-4 CPU
- 4-16 GB RAM
- 2GB HDD space
|
High |
Large server for extreme cases. |
- 4-64 CPU
- 16-128 GB RAM
- 4GB HDD space and more
|
Camunda Cockpit
Camunda Cockpit ist eine in Form eines Webclients implementierte Administrationsoberfläche, über die es möglich ist, laufende Prozessinstanzen zu überwachen und deren Vorfälle zu beheben.
Nach dem Einloggen in Camunda Cockpit wird eine allgemeine Übersicht über den Status der Camunda Engine angezeigt:
Zeigt die Anzahl der bereitgestellten Prozesse, der laufenden Instanzen, die aktuelle Anzahl der Vorfälle, d. h. der Instanzen von Prozessen, die in einem Fehlerzustand stecken, und die Anzahl der eingegebenen Benutzeraufträge an.
Wenn Sie „Laufende Prozessinstanzen“ (rot hervorgehoben) auswählen, erhalten Sie eine Aufschlüsselung der bereitgestellten Prozesse:
Bedeutung der Tabellenspalten:
- State = Zustand der Instanzen des Prozesses. Optionen:
- einige Instanzen befinden sich in einem Fehlerzustand
- es gibt keine Zwischenfälle in den Instanzen dieses Prozesses
- Vorfälle = Anzahl der Instanzen des Prozesses/Teilprozesses im Fehlerzustand = Vorfall
- Laufende Instanzen = Anzahl aller Instanzen des Prozesses. Instanzen, die sich in einem Fehlerzustand befinden, werden ebenfalls berücksichtigt.
- Name = Name des eingesetzten Prozesses oder Unterprozesses
Wenn Sie auf den Namen des ausgewählten Prozesses klicken, wird das Prozessmodell angezeigt:
Für Elemente, die als schwebend definiert sind (siehe Kapitel Datenbanktransaktionen), wird die
- die Zahl im blauen Kreis = die Anzahl der Instanzen dieses Prozesses, die in dem gegebenen Element warten,
- Zahl im roten Kreis = Anzahl der Instanzen dieses Prozesses, die einen Fehlerzustand in diesem Element erreicht haben = Instanzen
Handelt es sich bei dem Element um einen Unterprozess, sind diese Zahlen die Summe seiner Warteelemente.
Wir können uns darin einnisten und die Verteilung seiner Instanzen und Vorfälle im Detail sehen:
In der nachstehenden Tabelle sind diese Instanzen aufgeführt. Wenn Sie auf die ID der ausgewählten Instanz klicken, können Sie die aktuellen Werte der Prozessvariablen anzeigen, ihre Werte ändern und auf diese Weise Vorfälle beheben.