Logistikprozesse mit Camunda automatisieren

Die Kooperation mit der Hochschule Augsburg startete im April in die nächste Runde. Doch wie gestaltet man ein Hochschulprojekt während des Corona-Lockdown? Wir entschieden uns als Team dafür, das Open Source-Projekt RemedyMatch zu unterstützen - eine Plattform, die sich auf die Verteilung von Hilfsmitteln fokussiert hat und im Rahmen des WirVsVirus-Hackathons entstanden ist.

Die Herausforderung bestand vor allem darin, flexibel auf die sich ändernden Rahmenbedingungen eingehen zu können. Außerdem musste die bestehende Plattform modular erweitert werden. Insgesamt entwickelten über zehn Personen an der Lösung, die bisher noch nicht in Berührung mit RemedyMatch gekommen waren.

Wir entschieden uns deshalb dafür, für die neue Logistik-Domäne einen eigenen Microservice zu implementieren und diesen in die bestehende Architektur einzubinden. Dabei kümmerten wir uns um sämtliche anfallenden Aufgaben im Rahmen der Entwicklung und des Prozessmanagements. Nach der Analyse der Logistikprozesse modellierten wir diese in BPMN und automatisierten sie mit Camunda.

Wir orientierten uns bei Technologie und Software-Architektur am bereits bestehenden Stack des RemedyMatch-Projekts. Wir setzten auf Spring Boot im Backend und nutzten das External-Task-Feature von Camunda, um unsere Service Tasks zu implementieren.

Technologische Rahmenbedingungen

Zum Start des Semesterprojekts gab es in der Architektur von RemedyMatch bereits sechs verschiedene Komponenten. Die für uns relevanten sind dabei der SSO-Server, die Process Engine und das Frontend:

• Server: Für die Authentifizierung setzt das Projekt auf Keycloak mit OpenID Connect. Für Spring Boot kann eine sehr komfortable Integration genutzt werden, sodass die Einbindung der Authentifizierung bereits nach wenigen Stunden umgesetzt war.
• Process Engine: Für die Automatisierung der in BPMN modellierten Prozesse wird die Process Engine Camunda genutzt. In der Architektur spielt Camunda eine wichtige Rolle für die Orchestrierung der einzelnen Microservices. Dabei wurde das External-Task-Feature verwendet, das es den einzelnen Service-Workern erlaubt, sich ihre Aufgaben direkt von der Engine zu holen und asynchron abzuarbeiten. \ \ Dieses Pattern führt zu einer besseren Skalierbarkeit der Anwendung und einer höheren Fehlertoleranz. Zum Einen können bei Bedarf weitere Service-Worker hinzugeschaltet werden, zum anderen können Fehler durch die Process Engine gesondert behandelt werden.
• Frontend: Dieser Teil der RemedyMatch-Plattform ist eine React-Anwendung. In einer idealen Microservice-Architektur existieren für jede Domäne einzelne Frontends, welche anschließend in einer Anwendung zusammengeführt werden. Mit zwei Frontend-Entwicklern macht dies jedoch wenig Sinn und so entschieden wir uns dafür, die Anforderungen unseres Logistik-Prozesses in die bestehende Frontend-Anwendung zu integrieren.
• Die weiteren Komponenten waren für unsere Domäne nicht entscheidend. Lediglich für das Abfragen der Bedarfs- bzw. Angebotsdaten musste eine Schnittstelle in den entsprechenden Service integriert werden. Wir hatten dadurch wenig Abhängigkeiten zu den anderen Entwicklern und konnten die Logistik-Lösung eigenständig implementieren.

Umsetzung des Logistikprozesses

Für die Umsetzung starteten wir mit einer fachlichen Analyse der Logistik-Domäne, in der zunächst die Abläufe etablierter Unternehmen näher betrachtet wurden. Für RemedyMatch überlegten wir uns dann ein Konzept, das wie folgt aufgebaut war:

1. Zunächst erhalten der Spender und der Empfänger der Hilfsmittel jeweils die Möglichkeit, sich selbst um den Transport zu kümmern .
2. Sollte sich keiner der beiden um den Transport kümmern können oder wollen, wird der Lieferauftrag für Dritte freigegeben .
3. Nutzer, die sich auf der Plattform als Logistiker registriert haben, können ausgewählte Lieferungen übernehmen.

Den Prozess selbst hatten wir in Camunda samt Test-Automatisierung in kurzer Zeit implementiert und konnten uns dadurch auf das Logistik-Backend konzentrieren. Für die REST-Calls nutzen wir den bekannten Feign-Client und für die Speicherung der Daten setzten wir auf Spring Data JPA. Dabei teilten wir die Anwendung in drei Ebenen:

• Infrastruktur: JPA-Repositories und Entity-Klassen
• Domain: Application-Services und Domain-Objekte
• API: Schnittstellen und Transfer-Objekte

Das Anlegen des Lieferauftrags implementierten wir mit einem External-Task-Worker, was es uns erlaubte, den neuen Microservice von der restlichen Anwendung zu entkoppeln. Um offene User-Tasks abzuschließen oder Nachrichten an den Prozess zu senden, stellten wir für die bestehende React-Anwendung REST-Aufrufe im Logistik-Service bereit. Dies ermöglicht es den Empfängern und Spendern der Hilfsmittel, die Lieferung eigenständig abzuwickeln.

Um die Zustellung durch externe Logistiker zu ermöglichen, entwickelten wir gemeinsam mit dem UI/UX-Team von RemedyMatch einen MVP für eine separate Anwendung und passten unseren BPMN-Prozess darauf an.

Insgesamt war es ein rundum gelungenes und lehrreiches Projekt, das vor allem durch das Engagement aller Beteiligten sehr viel Spaß gemacht hat.