Das Teilen liegt in der Natur von Microservice Architekturen. Business Prozesse machen aber selten halt an den Microservice Grenzen. In diesem Vortrag wird besprochen wie mit Commands und Events die Umsetzung von Business Prozessen beherrscht werden kann, so dass schlussendlich ein konsistenter Zustand erreicht wird. Und wie mit Fällen und Aufgaben die Benutzer dabei involviert werden und ihnen damit die Übersicht über die verteilten Prozesse ermöglicht wird.

1. Commands & Events –
Divide and Conquer in
Microservice Architekturen
Beat Winistörfer, IT Architekt
Quelle: https://www.flickr.com/photos/nicola_s/20141007433

2. Aufteilen liegt im Wesen jeder
Microservice Architektur
Microservice Architektur
Komplexe Anwendungssoftware als Suite von kleinen,
unabhängigen Services mit eigener Datenhaltung.
12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 2
Quelle: http://insureblog.blogspot.com/2011/06/ode-to-rube-goldberg.htmlQuelle: https://martinfowler.com/articles/microservices.html
Aber nicht alle
Anforderungen
machen an der
Grenze der
Microservices
halt…

3. Das CAP Theorem von Eric Brewer
Ein verteiltes System kann nur 2 der folgenden 3
Eigenschaften erfüllen
1. Konsistenz
2. Verfügbarkeit
3. Ausfalltoleranz
12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 3
Quelle: https://www.compact.nl/en/articles/big-data-too-big-to-ignore-2/
BASE Prinzip
Basically Available
Soft State,
Eventual Consistency
BASE

4. BASE Transaktion als Abfolge von Statusänderungen in Microservices
12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 4
Basically Available
Asynchrone Kommunikation überbrückt
Verfügbarkeitsprobleme. Auftrag entgegen
nehmen, Antwort später…
Softstate
Zustand in dem ein Teil der Microservices im
neuen Zustand und ein Teil noch im alten Zustand
sind.
Eventual Consistent
Schlussendlich erreichen alle involvierten
Microservices einen konsistenten Zustand oder
über Kompensationen wieder den
Ausgangszustand.

5. Den Unterschied zwischen "eventual consistent" und "eventuell konsistent"
macht verlässliche Kommunikation
12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 5
Statusänderung und sich daraus ergebende
Kommunikation müssen eine Einheit bilden
• ACID Transaktion garantiert At-Least-Once
Delivery beim Producer
− Message-Tabellen & Hintergrund Versandjob
− Kafka Transaktion
(eigene Änderung & Kommunikation)
• Asynchrone Kommunikationsinfrastruktur
muss ebenfalls At-Least-Once Delivery
garantieren
• Consumer muss Idempotenz bei der
Verarbeitung garantieren.

6. Commands & Events
• Kommunikationen aus Statusänderungen lassen sich grob in 2 Kategorien unterteilen
• Events: Benachrichtigungen aus der Vergangenheit über einen bestimmten Vorfall
− Empfänger aus Sicht Produzent irrelevant. Benachrichtigung durch Konsumenten unüblich
− Mehrere Empfänger durchaus üblich, ändert sich über die Zeit
− Kein Empfänger oft zulässig (Broadcast von Änderungen bspw.), kann aber auch ein
Problem sein (bspw. Dokument Eingang um den sich niemand kümmert).
− Normalerweise nur ein Produzent
• Commands: in Zukunft zu erledigende Aufträge
− Produzent hat eine klare Erwartung, muss aber die konkrete Umsetzung nicht kennen.
Benachrichtigung über Erledigung gängig.
− Normalerweise genau ein Empfänger aber durchaus mehrere Produzenten
− Kein Empfänger unzulässig (Fehler)
12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 6
Beispiele:
➢ Änderungs-Events
➢ Dokument-Eingang
➢ Prozess Abschluss
➢ Online Schadenmeldung
➢ …
Beispiele:
➢ Änderung durchführen
➢ Visum einholen
➢ Zahlung auslösen
➢ Dokument versenden
➢ …

7. Prozessmodellierung und Verantwortlichkeit
Command oder Event?
Command – Auftraggeber bleibt in der Verantwortung
Der Auftraggeber bleibt in der Prozessverantwortung. Der Prozess ist erst abgeschlossen wenn
der Auftrag erledigt wurde, allfällige Konsequenzen aus einer nicht möglichen Verarbeitung des
Auftrags müssen vom Aufraggeber gezogen werden.
Event – Aprés moi le déluge… Verantwortlich für eine Verarbeitung ist der Konsument
Die Prozessverantwortung ist mit der Kommunikation der sich daraus ergebenden Events
wahrgenommen.
12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 7
Command Event
Event
Orchestrierung
Choreografie

8. Umsetzung von BASE Transaktionen als
orchestrierender Microservice (Saga Pattern)
12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 8
• BASE Transaktionen als Microservice
− dezentral, CI/CD
− Devops Verantwortlichkeit für Prozess
• Verschachtelbar (über Orchestrierung oder Choreografie), weitere Events integrierbar
• Deklarative Prozessdefinition
• Standard Schnittstellen für Überwachung und Administration
BASE Transaktion (Saga) Service
Service A Service B Service C
Client
Command
Command A Event A Command B Event B Command C Event C
Event
Btx Status
Admin ClientMonitoring Client
Auslösender Event
Event
Events

9. BTx @ Mobiliar
• Java Library für Command/Event Erstellung/Verarbeitung
− Standard Datenbanktabelle für Commands/Events
− Backgroundjob
− Monitoring/Admin REST Interface
• Java Library für BASE Transaktionen
− Standard Datenbanktabelle für Statusverwaltung
− Fluent API für Prozess Definition
− Backgroundjob
− Prozessvisualisierung Definition und Instanz über PlantUML
− Monitoring/Admin REST Interface
• Kommunikation
− Command Mapping auf REST
− Events über JMS via Publish/Subscribe Event Plattform auf Basis von Apache Camel
− Commands & Events neu auch über Kafka
12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 9

10. Processdefinition as Code, Visualisierung über PlantUML
12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 10
return BTxDefinition.newBuilder(OmsBtxState.class, OMS_BTX_DEFINITION_ID)
.while_("Verarbeitung EinlieferungEinheiten", OmsBtxState::isBtxWaitingForMoreEE)
.waitForEvent(JOIN_RUNNING_BTX_EVENT)
.activity(new FunctionActivity<>(SendVorbereitungActivity.ACTIVITY_NAME, sendVorbereitungAct
.waitForEvent(WAIT_FOR_VORBEREITUNG_CONSUMER)
.if_("Vorbereitung fehlerhaft",
(omsBtxState) -> isEinlieferActivityFehlerhaft(omsBtxState, WAIT_FOR_VORBEREITUNG_CON
.activity(new FunctionActivity<>(FailedVorbereitungActivity.ACTIVITY_NAME, failedVorbere
.endIf()
.activity(new FunctionActivity<>(SendFachdatenActivity.ACTIVITY_NAME, sendFachdatenActivity)
.waitForEvent(WAIT_FOR_FACHDATEN_CONSUMER)
.if_("Fachdaten fehlerhaft",
(omsBtxState) -> isEinlieferActivityFehlerhaft(omsBtxState, WAIT_FOR_FACHDATEN_CONSUM
.activity(new FunctionActivity<>(FailedFachdatenActivity.ACTIVITY_NAME, failedFachdatenA
.endIf()
.activity(new FunctionActivity<>(PrepareAufbereitungActivity.ACTIVITY_NAME, prepareAufbereit
.while_("Aufbereitung KorrespondenzInfoArten", OmsBtxState::isAufbereitungenPendent)
.activity(new FunctionActivity<>(SendAufbereitungActivity.ACTIVITY_NAME, sendAufberei
.waitForEvent(WAIT_FOR_AUFBEREITUNG_CONSUMER)
…

11. Andere BTx Implementationen…
12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 11
Service C
Service B
BASE Transaktion Service
Service A
Client
Command
Pollen für Commands
Event
Prozess Def.
Btx StatusAdmin ClientMonitoring Client
Auslösender Event
Event
Zeebe Cluster
Prozess
Definition
Start
BTx
Pollen für
Ende
• Open Source
• Prozessdefinitionen in BPMN (reduziert)
• Commands Pollen und Resultat (gRPC bidirektional)
• Zusätzliche Messages können integriert werden
Resultat "Event"
Messages
(Events)
Events

12. Andere BTx Implementationen…
12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 12
Simple Workflow Service
• Cloud basiert
• Optimiert für Inter Cloud Kommunikation (HTTP Polling)
• Keine Prozess Definitionen
• Message Integration über Signale
• Progress Meldungen der Worker Services mit Abbruch Option
Service C
Service B
BASE Transaktion Service
Service A
Client
Command
Resultat
"Event"
Event
Btx Status
Admin Client
Monitoring Client
Auslösender Event
Event
AWS SWF
Start
BTx
Pollen
Für
Decision Tasks
Pollen für Commands
Next
Decision
Progress
Signal
(Events)
Events

13. 12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 13
Und wo bleiben eigentlich die Benutzer?

14. Strategie: Fall basiertes Arbeiten
12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 14
BTx «Orchestrator»
Statusmodell
Command
Command
Aufruf
Fall Aktion
Command
Event
Command
Event
Fall
Prozess
Fallstatus
Prozess Prozess
Fall als Prozesskontext mit referenzierte Objekten
Fallstatus
Notiz Zugeordneter
Vertrag
Aufgabe
Fallstatus
Aufgabe
Fallstatus
Fall
eröffnet
Fall
abgeschlossen
Command
Wiedervorlage
(Aufgabe in Zukunft)
Aufgabe
Event
Fälle zum Bearbeiten von Kundenanliegen und internen Prozessen über alle Zugänge hinweg
Organisation der Arbeit über Zuweisung von Fällen und Aufgaben inkl. freidefinierbare Arbeitskörbe (persönlich & Team)
Standard Funktionalität für Freitextaufgaben, Aktionen, Notizen und eDossier für Dokumente.

15. Spezifischer Fall ServiceSpezifischer Fall Service
Dezentrale Fall Geschäftslogik & Bearbeitung,
zentrale, konsolidierte Übersicht für den Benutzer
29/30.11.2017Commands & Events – Divide and Conquer in Microservice Architekturen 15
ARO Service
Fällen und
Aufgaben erstellen
inkl. Links & Callbacks
Listen mit Links
Navigation über Link
Aufgaben Erledigen
über Callback
ARO Schreibtisch UI Spezifisches Fall UI
Fallzustände
Spezifischer Fall Orchestrierung
Service
Fallzustandslogik

16. Ereignisse als Historie für Fälle und Geschäftsobjekte
12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 16
Ereignis
Fall Geschäftsobjekt
erzeugt, verändert
referenziert
Benutzer
Input
Management
erzeugt

17. H
Ereignis Historien auf Geschäftsobjekt Übersichten und Fall UIs
12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 17
Event Verteilung Plattform
Geschäfts-
komponenteGeschäfts-
komponenteMicroservices
Ereignisse mit
Historien Info
Geschäftsvorfall
Protokollierung
H
Historie lesen
Infosicht Partner
H
Infosicht Vertrag
H
Fall UIs
Navigation auf
Ereignis
Kontext

18. 12.08.2019Commands & Events – Divide and Conquer in Microservice Architekturen 18
Q & A
beat.winistoerfer@mobi.ch