Geschäftsprozesse in einer Microservice-Welt

Bei der Neuentwicklung eines modernen Softwaresystems wird dessen Architektur in der Regel auf Basis verteilter Systeme modelliert. Die Granularität der Systemverteilung kann dabei von einzelnen Komponenten über Subsysteme auf Basis von Microservices bis hin zu Serverless Computing in der Cloud reichen. Basierend auf den fachlichen Anforderungen werden Domänen gebildet, Datenstrukturen geplant, modelliert und auf die Domänen verteilt. Dabei kommen gängige Methoden wie das Domain-driven Design (DDD) zum Einsatz, die die Planung unterstützen und die Entscheidungsfindung erleichtern. Was passiert, wenn ein größerer Geschäftsprozess modelliert werden soll, der sich über mehrere Domänen erstreckt? Werden die Domänengrenzen neu gezogen? Werden die Datenstrukturen neu verteilt? Was passiert, wenn mehrere Geschäftsprozesse geplant werden, die gleichzeitig verschiedene Domänen nutzen?

Hier haben sich in den letzten Jahren zwei Ansätze herauskristallisiert, die in den gängigen Foren und Auditorien zum Teil kontrovers diskutiert werden.

Die Ansätze werden bezeichnet als:

• Orchestrierung von Geschäftsprozessen und
• Choreographie von Geschäftsprozessen bezeichnet.

In diesem Blog-Beitrag werde ich die beiden Ansätze näher beschreiben, Vor- und Nachteile auflisten und anonymisierte Fallbeispiele aus verschiedenen realen Projekten der letzten Jahre beschreiben.

Ziel ist es, einen neutralen Überblick über die Modellierung von Geschäftsprozessen in verteilten Systemen zu geben, ohne eine Wertung abzugeben.

Szenario

Im Projekt VuP (Vertrieb und Produktion von Gütern) der Firma Hersteller AG sind wir in einer frühen Phase als Lösungsarchitekt in das Projekt eingebunden und sollen als Schnittstelle zwischen dem Kunden, den Anforderungsmanagern und dem Entwicklungsteam fungieren. Durch das Enterprise-Architecture-Management (EAM) der Firma Hersteller AG wurde bereits vorgegeben, dass das Projekt VuP auf einer verteilten Architektur mit einem Web-Frontend realisiert werden soll. Die Systemarchitektur besteht dabei aus dem Web-Client, einem Backend mit Geschäftslogik auf Basis von Microservices und einer SQL-Datenbank. Die Anforderungsmanager übergeben uns einen modellierten und vom Kunden bereits abgenommenen Geschäftsprozess mit der Bitte, die fachlichen Domänen zu planen und den Prozess abzubilden.

Geschäftsprozess “Verkauf und Versand von Produkten”

Das folgende Modell stellt eine vereinfachte Form des Geschäftsprozesses “Verkauf und Versand von Produkten” dar und basiert auf einem einfach gehaltenen BPMN-Modell.

Microservices

Als Grundlage für das weitere Verständnis dieses Artikels folgt eine kurze Beschreibung, was Microservices sind. Einen tieferen Einstieg bietet zu “Microservices für nichttechnische Leute”.

Microservices sind Architekturmuster, bei dem eine Anwendung aus unabhängigen Diensten besteht, die kleine Aufgaben erledigen, wobei “klein” immer eine Projektdefinition ist. Diese Dienste kommunizieren beispielsweise entkoppelt (asynchron) miteinander und tauschen im Idealfall nur die nötigsten Informationen aus. Im besten Fall wissen sie nichts voneinander, sondern senden nur Nachrichten. Wer sich für die Nachrichten interessiert, hört sie ab.

Zusammengefasst lautet die Vorgabe für die Planung eines Microservices: “Erledige nur eine Aufgabe und erledige sie gut”.

Im Folgenden wird der Einfachheit halber der Begriff “Service” verwendet.

Domain-driven Design

Domain-driven Design (DDD) ist ein Ansatz zur Modellierung von Softwaresystemen. Er basiert auf der Zerlegung von Teilsystemen (Domänen) auf Basis der Fachlichkeit. Die Fachlichkeit und die Fachlogik stehen im Mittelpunkt der Modellierung.

Domänenschnitt

Wie eingangs beschrieben, gibt es verschiedene Ansätze für den Zuschnitt von Domänen. Am bekanntesten ist das Domain-driven Design. Leider erlauben es reale Kunden und Projekte nicht immer, perfekt nach Lehrbuch zu arbeiten, so dass hier manchmal interessante Konstrukte entstehen. Dazu gehören zum Beispiel lange, fast philosophische Diskussionen über Domänenschnitte auf Architektenebene. Manchmal wird aber auch nach der Anzahl der Teams oder nach dem Interesse oder “Gefühl” des Product-Owners geplant.

In unserem VuP-Projekt ergeben sich am Ende der Planung folgende vier Bereiche:

Orchestrierung von Geschäftsprozessen

Der Begriff Orchestrierung stammt aus dem Musikkonzert. Dort sitzen viele Musiker, die nur eine Aufgabe haben: ihr Instrument zur richtigen Zeit zu spielen. Im Mittelpunkt steht der Dirigent, der den Takt und die Geschwindigkeit vorgibt. Von seinem Können hängt alles ab.

Bei der Orchestrierung von Geschäftsprozessen wird das System nach diesem Ansatz realisiert. Die einzelnen Services warten auf die Anweisungen eines orchestrierenden (steuernden) Services. Die anderen Services kennen sich nicht und wissen auch nicht, wann sie etwas zu tun haben.

Der zentrale Service modelliert und steuert den Geschäftsprozess. Wie der Prozess im Detail umgesetzt wird, hängt vom Projekt ab. Es ist möglich, den Prozess selbst zu entwickeln oder eine Workflow-Engine einzusetzen und den Prozess “nur” zu modellieren. Der Einsatz einer Workflow-Engine ist dann von Vorteil, wenn die Prozesse komplexer werden und Berechtigungen und Eskalationen abgebildet werden müssen. Viele Systeme bringen diese Funktionen bereits mit, so dass das Verhältnis zwischen Programmierung und Konfiguration zugunsten der Konfiguration ausfällt. Auch die Verwaltung unterschiedlicher Versionen eines Prozesses wird über eine solche Workflow-Engine abgebildet. Damit ist die Änderung eines Prozesses während des produktiven Einsatzes gemeint. Die Workflow-Engine definiert, wie sich aktuelle Prozessinstanzen verhalten, wenn z.B. Prozessschritte hinzugefügt oder geändert werden.

Eine Instanz des Prozesses, beispielsweise die Bestellung 4711 des Kunden Müller, wird zentral von der Workflow Engine des orchestrierenden Services gesteuert. Die einzelnen Services werden über ihre Aktionen informiert und mit Daten versorgt. Die Teilverarbeitung findet in den einzelnen Services statt, die vom orchestrierenden Service überwacht werden. Anschließend werden die Daten wieder an die Zentrale zurückgesendet.

Choreographie von Geschäftsprozessen

Der Begriff Choreographie ist an ein Ballett-Ensemble angelehnt. Hier sitzen im Vorfeld alle Beteiligten (Tänzer, Designer, Musiker) zusammen, planen und proben gemeinsam eine Choreographie. Dabei weiß jeder, was er zu tun hat, vor allem, wann er etwas zu tun hat. Dies bedeutet, der Tänzer kennt seine Vorgänger und seine Nachfolger, weiß, wo er zu stehen hat und wann sein Einsatz ist. Hier hängt alles vom Können aller Beteiligten ab.

Bei der Choreographie von Geschäftsprozessen wird das System nach diesem Ansatz realisiert. Der Geschäftsprozess wird zum Zeitpunkt der Modellierung in Teilprozesse zerlegt, die dann auf die einzelnen Domänen verteilt werden. Dadurch kennen die Services sich gegenseitig, zumindest den Vorgänger, der ihm Daten liefert und den Nachfolger, an den er Daten liefern muss. Jeder weiß genau, wann er was zu tun hat, es gibt keine zentrale Steuerung. Auch hier muss die Umsetzung des Teilprozesses im Detail entschieden werden, jeder Service kann dies selbst entscheiden. Natürlich sollte dem Anwender ein zentrales Bild gezeigt werden.

Eine Instanz des Prozesses, beispielsweise die Bestellung 4712 vom Kunden Meyer, wird von dem ersten Service angelegt, mit Daten angereichert und an den nächsten Service übergeben. Jeder Teilprozess wird dabei in dem jeweiligen Service gestartet, ausgeführt und wieder beendet. Jeder weitere nachfolgende Service startet seinen eigenen, vollkommen unabhängigen Teilprozess.

Fallbeispiel “Erweiterung”

Das Projekt VuP wird im ersten Meilenstein umgesetzt und läuft erfolgreich an. Nach einiger Zeit gibt es die ersten Kundenreklamationen, weil die Produkte in schlechtem Zustand beim Kunden ankommen. Das Unternehmen beschließt, den Geschäftsprozess um einen eigenen Prozess “Verpackung” zu erweitern, der wiederum aus einzelnen Teilprozessen besteht.

Derzeit sieht der Prozessausschnitt wie folgt aus:

Zukünftig wird vor der Auslieferung und der Übergabe an die Faktura noch der Prozess Verpackung aufgerufen:

Eine Orchestrierungslösung besteht aus den folgenden Schritten:

• Eine neue Domäne Verpackung wird als Service implementiert.
• Der Geschäftsprozess im Orchestrierungsdienst wird erweitert, so dass der neue Prozess technisch implementiert ist.
• Die Kommunikation zwischen Packaging und Orchestrierung wird eingerichtet.

Eine Lösung im Bereich Choreographie besteht aus den folgenden Schritten:

• Eine neue Domäne Verpackung als Service wird implementiert.
• Der Service "Verpackung" kennt seinen Vorgänger "Produktion" und seine Nachfolger "Kunde" und "Faktura".
• Die Kommunikation zwischen allen beteiligten Services wird eingerichtet
• Der rote Pfeil in der Abbildung zeigt einen Fehler, der erst nach dem Go-Live bemerkt wurde: Es wurde vergessen, die Verbindung zwischen Produktion und Faktura zu trennen, so dass der Kunde zwei Rechnungen pro Bestellung erhielt. Ein Versand wurde aus dem neuen Verpackungsservice angestoßen. Ein weiterer Versand erfolgte aus dem alten Produktions-Service.

Fallbeispiel “Status”

Das Projekt VuP wird in einem weiteren Meilenstein umgesetzt und startet erfolgreich mit der neuen Version. Aus den Erfahrungen des Tagesgeschäfts erkennt das Unternehmen, dass manchmal Änderungen des Kunden an seinem Auftrag nachgezogen werden müssen. Daher werden folgende zwei abhängige Anforderungen an das Projekt übergeben:

• Die Produktion darf Bestellungen nur korrigieren, wenn die Faktura diese noch nicht freigegeben hat!
• Die Faktura darf Aufträge nur freigeben, wenn diese nicht gleichzeitig wieder zur Korrektur in der Produktion sind!

Wir haben hier also eine bidirektionale Abhängigkeit zwischen zwei Teilprozessen, die wie folgt einfach dargestellt ist.

Eine Orchestrierungslösung besteht aus folgenden Schritten:

• Der Geschäftsprozess wird um eine Statuskontrolle ähnlich der Abbildung erweitert. Dies bedeutet, dass nach dem Öffnen des Prozesses durch einen Bearbeiter der Prozess für andere Abteilungen gesperrt werden muss.
• Da der Prozess zentral verwaltet wird, kann hier der Status für alle Benutzer, die Zugriff auf den Prozess haben, sichtbar dargestellt werden, beispielsweise “In Bearbeitung in der Abteilung Faktura”.

Eine Lösung im Bereich Choreographie besteht aus folgenden Schritten:

• Hier müssen zwei Teilprozesse und damit zwei Services direkt miteinander kommunizieren.
• Die erste Möglichkeit ist, dass die Kommunikation weiterhin asynchron über Nachrichten erfolgt. Dabei besteht jedoch die Gefahr, dass beide Nutzer ihren Teilprozess gleichzeitig starten und die Statusmeldungen zu spät auf der anderen Seite eintreffen
• Die zweite Möglichkeit besteht darin, die Kommunikation in diesem Fall synchron ablaufen zu lassen. Die Dienste können sich dann direkt gegenseitig aufrufen und den Status übermitteln.

Fallbeispiel "Korrektur“

Das Projekt VuP wird in einem weiteren Meilenstein umgesetzt und startet erfolgreich mit der neuen Version. Die Fakturierung des Unternehmens stellt leider fest, dass der Vertrieb regelmäßig Fehler bei der Erfassung macht, aber auch die Qualität der Produktion nicht dem Standard entspricht. Es wird entschieden, dass die Fehler beim Verursacher behoben werden müssen und nicht ausschließlich in der Faktura. Das bedeutet, dass die Faktura nur noch Änderungen oder auch Stornierungen von Kunden erfasst und an die beiden Abteilungen zur Korrektur weiterleitet.

Eine Prozessanpassung könnte beispielsweise wie folgt aussehen:

Eine Orchestrierungslösung besteht aus folgenden Schritten:

• Der Geschäftsprozess wird um die Erfassung von Stornierungen und Korrekturen erweitert.
• Der Geschäftsprozess wird um zwei Teilprozesse erweitert, die unabhängig voneinander und gleichzeitig ablaufen können.
• Für die User der jeweiligen Fachabteilung werden Bearbeitungsdialoge erstellt, die den Teilprozess aus der jeweiligen Sicht abbilden.
• Am Ende der Teilprozesse werden diese wieder zentral zum Hauptprozess zusammengeführt und die Bearbeitung erfolgt wie gewohnt.
• Die Steuerung der Parallelität und das Zusammenführen der Teilprozesse übernimmt die Workflow-Engine.

Eine Lösung im Bereich Choreographie besteht aus folgenden Schritten:

• Die Domäne Faktura wird um die Erfassung von Stornierungen und Korrekturen erweitert.
• Die beiden beteiligten Services “Kunde” und “Produktion” müssen die Kommunikation mit der Faktura-Domäne anpassen und die Daten aus der Korrekturerfassung entgegennehmen.
• Da es sich um eine verteilte und asynchrone Kommunikation handelt, muss ein serviceübergreifender Schlüssel ausgetauscht werden, der die Prozessinstanz eindeutig identifiziert, etwa eine Transaktions-ID oder eine Vorgangs-ID.

• Am Ende der Teilprozesse muss ein Dienst auf die Daten der beiden anderen Dienste warten, bis von beiden eine Rückmeldung erfolgt ist, diese dann konsolidieren und weiterverarbeiten.

Zusammenfassung

Orchestrierung und Choreographie sind zwei großartige Architekturmuster, mit denen die Interaktion und Kommunikation zwischen verteilten Systemen gesteuert werden kann. Der richtige Einsatz muss in jedem Projekt neu überdacht werden. Es gibt leider keinen Ansatz, der für alles passt.

• Microservices sind eine Architekturentscheidung!
• Die Architektur sollte aus den Kundenanforderungen abgeleitet werden!
• Choreographie der Geschäftsprozesse ist sinnvoll!
• Orchestrierung von Geschäftsprozessen macht Sinn!
• Workflow-Systeme sind nicht schlecht!
• Zu Beginn eines Projektes sollten alle Aspekte diskutiert und mehrere Lösungsalternativen objektiv bewertet werden!
• Bei agilen Projekten in Sprints planen, aber den Marathon sehen!
• Schwarz-Weiß-Denken abschalten!

Ihr möchtet gern mehr über spannende Themen aus der adesso-Welt erfahren? Dann werft auch einen Blick in unsere bisher erschienenen Blog-Beiträge.