Vorwort

Da ich seit einiger Zeit beruflich wieder sehr viel mit Camunda arbeite, dachte ich mir ich könnte hier mal eine kleine Serie zu diesem Thema starten. Dabei möchte ich mich weniger auf die Grundlagen von BPMN fokussieren, sondern eher kleine Beispiele für das alltägliche Arbeiten mit Camunda liefern.

Wer gerne mehr über das Thema BPMN wissen möchte, dem kann ich nur wärmstens das Buch „Praxishandbuch BPMN“ empfehlen. Darin wird mit sehr anschaulichen Beispielen erklärt, wie sich Geschäftsprozesse mithilfe von BPMN modellieren lassen.

Ich werde zu jedem Thema auch ein kleines Beispielprojekt erstellen. Diese findet ihr im folgenden Repository: https://bitbucket.org/pragtics/camunda-demos/

Camunda und Spring Boot

Seit Camunda vor einigen Jahren die Spring Boot Integration aus der Community übernommen hat, ist es super komfortabel geworden die Workflow Engine in eine Spring Boot Anwendung zu integrieren. Alles was wir dafür tun müssen, ist die entsprechende Abhängigkeiten zu unserem Projekt hinzuzufügen. Den Rest erledigt die Autokonfiguration für uns.

Camunda bietet drei verschieden Maven Artefakte dafür an:

  • camunda-bpm-spring-boot-starter: Dieses Projekt enthält nur die Workflow Engine an sich. Das genügt um Prozesse auszuführen, allerdings Fehlen hier sowohl die REST API als auch das Management Frontend.
  • camunda-bpm-spring-boot-starter-rest: Wie der Name schon vermuten lässt, enthält dieses Modul zusätzlich zur Engine noch die REST API von Camunda.
  • camunda-bpm-spring-boot-starter-webapp: Hier ist zusätzlich zur Engine noch das Management Frontend integriert, welches wir später verwenden können um die laufenden Prozesse zu verwalten.

Für unser Beispiel gehen wir einfach mal davon aus, dass wir sowohl die REST API für die Kommunikation mit der Außenwelt, als auch das Management Frontend benötigen. Dafür müssen wir also die folgenden Abhängigkeiten in unserer POM definieren:

<dependency>
    <groupId>org.camunda.bpm.springboot</groupId>
    <artifactId>camunda-bpm-spring-boot-starter-webapp</artifactId>
    <version>3.2.1</version>
</dependency>
<dependency>
    <groupId>org.camunda.bpm.springboot</groupId>
    <artifactId>camunda-bpm-spring-boot-starter-rest</artifactId>
    <version>3.2.1</version>
</dependency>

Camunda benötigt für die eigene Datenhaltung noch eine Datenbankverbindung. Für die ersten Gehversuche verwenden wir hier die H2 Datenbank, da diese von Spring automatisch konfiguriert wird, wenn der Treiber im Classpath vorhanden ist. Deshalb fügen wir jetzt noch die folgende Abhängigkeit hinzu:

<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <version>1.4.197</version>
</dependency>

Ich würde euch empfehlen die Spring Boot BOM zu verwenden um sicherzustellen, dass die Versionen aller Frameworks ordentlich zusammenpassen. Wie das geht ist hier beschrieben:

https://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-build-systems.html#using-boot-maven-parent-pom

Wie bei jeder Spring Boot Anwendung benötigen wir jetzt noch die Einstiegsklasse:

package de.pragtics.demos.camundaspringboot;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class);
    }
}

 

Außerdem ist es Sinnvoll einen Admin User für Camunda zu definieren, damit wir diesen nicht nach jedem Neustart neu anlegen müssen. Dafür fügen wir einfach die folgenden Zeilen zu unserer application.yml hinzu.

camunda:
  bpm:
    admin-user:
      id: admin
      password: admin

Dadurch legt Camunda beim Start automatisch einen User mit dem Namen „admin“ und dem Passwort „admin“ an.

Wenn wir jetzt unsere Anwendung starten, sehen wir schon dass der Start deutlich länger dauert als bei einer leere Spring Boot Anwendung. Das liegt daran, das die Workflow Engine direkt mit gestartet wird und dabei auch gleich die Datenbank initialisiert wird.

Sobald die Anwendung vollständig gestartet ist, können wir über die URL http://localhost:8080 das Management Frontend öffnen. Dort können wir uns mit den konfigurierten Logindaten anmelden. Danach sollten wir auf der folgenden Seite landen:

Das Management-Frontend von Camunda ist in die folgenden drei Bereiche aufgeteilt, welche wir von hier erreichen können:

  • Im Bereich „Admin“ geht es um die technische Aspekte der Workflow Engine, den größten Teil nimmt hier die Benutzerverwaltung mit Benutzern, Gruppen und Rechten ein.
  • Das Cockpit bietet eine Übersicht über alle Prozesse die von der Engine verwaltet werden. Man kann laufende Prozessinstanzen einsehen und manipulieren, oder neue Prozessmodelle hochladen.
  • Sollte bei der Ausführung eines Prozesses ein UserTask erstellt werden, der von einem Benutzer manuell bearbeitet werden muss, wird dieser in der Tasklist angezeigt. Hier können auch einfache Formulare für das Bearbeiten dieser Aufgaben hinterlegt werden.

 

Damit sind wir auch schon fertig. Die Workflow Engine läuft und wir können damit beginnen unseren ersten Prozess zu modellieren und zu deployen. Den Code zu diesem Beitrag findet ihr wie immer bei Bitbucket: https://bitbucket.org/pragtics/camunda-demos/src/master/camunda-spring-boot/