Vor einiger Zeit haben wir bereits über unsere Arbeit an einem Prototyp für ein CCM-Cockpit berichtet. In diesem Blogpost möchten wir die Lösung vorstellen, die in Zusammenarbeit mit der Gebäudeversicherung Bern und der Ajila AG entstanden ist.
Ausgangslage
Die Problemstellung, die wir bereits im Blogpost zum Prototypen beschrieben haben, hat sich nicht geändert. Hier noch einmal zur Erinnerung:
Die Gebäudeversicherung Bern ist vor einiger Zeit mit folgender Problemstellung an uns herangetreten: Um zu bestimmen, in welcher Form ihre Kundinnen und Kunden ein Dokument (z.B. eine Rechnung) erhalten, hat sie ein ausgeklügeltes System. Einige Dokumente sollen elektronisch übermittelt werden, andere per Post und wieder andere als elektronische Rechnung. Man spricht hier abstrakt von Ausgabekanälen. Beim Betrieb dieses Systems weiss die Gebäudeversicherung teilweise nicht, ob alle Dokumente an die richtigen Ausgabekanäle weitergeleitet wurden.
Ein Dokument durchläuft von seiner Erzeugung bis zu einem Ausgabekanal drei Subsysteme:
- SAP erzeugt das Dokument.
- Das Customer Communication Management System (CCM) bereitet das Dokument auf und leitet es an den entsprechenden Ausgabekanal weiter.
- Der Ausgabekanal empfängt das Dokument.
Nun möchten wir ein Dokument auf seinem Weg durch diese drei Subsysteme verfolgen, diese Daten aggregieren und so ein Dashboard für den Betrieb erstellen, damit auf einen Blick ersichtlich ist, ob alle Dokumente im richtigen Ausgabekanal gelandet sind.
Herausforderungen
Es stellte sich heraus, dass es bei diesem Produkt mehrere Herausforderungen gab:
- Die einzelnen Ausgabekanäle liegen auf unterschiedlichen Systemen. Es musste also eine Architektur gefunden werden, die in der Lage ist, Daten aus all diesen unterschiedlichen Systemen abzugreifen und zusammenzuführen.
- Es sollte auf einen Blick erkennbar sein, ob Dokumente korrekt verarbeitet werden. Gleichzeitig muss es möglich sein, einzelne Dokumente für Analysen zu verfolgen. Darüber hinaus müssen die beiden Anwendungsfälle Tagesverarbeitung (mit einigen hundert Dokumenten) und Verarbeitung der Jahresrechnungen (mit hunderttausenden Dokumenten) mit der gleichen Oberfläche behandelt werden können.
- Bei der Verarbeitung der Jahresrechnungen werden mehrere hunderttausend Dokumente erzeugt. Jedes einzelne Dokument muss durch die Pipeline verfolgt werden, was in kurzer Zeit zu mehr als 1 Million Ereignissen führt. Das System muss in der Lage sein, diese Datenmengen zu verarbeiten, ohne die Performance der Jahresrechnung zu beeinträchtigen.
Umsetzung
Das Produkt wurde in zwei Phasen mit jeweils mehreren Iterationen implementiert. In der ersten Phase wurde die Basisversion des Cockpits entwickelt, in der zweiten Phase erfolgte die Anpassung und Stabilisierung, nachdem das Cockpit einige Zeit im Einsatz war.
Konzeptionell wurden Kontrollpunkte an verschiedenen Stellen der Dokumentenpipeline eingeführt. Kontrollpunkte sind beispielsweise die Erstellung eines Dokuments in SAP, die Aufbereitung der PDF-Datei oder die Empfangsbestätigung der Druckerei. Jedes Mal, wenn ein erzeugtes Dokument einen Kontrollpunkt passiert, wird ein Event erzeugt. Somit ist bekannt, welche Dokumente die Pipeline wie durchlaufen haben.
Da nicht jedes Dokument alle Kontrollpunkte durchlaufen muss, wird für jedes Dokument bei der Erzeugung in SAP festgelegt, welche Kontrollpunkte es durchlaufen muss. Diese Information wird als Blueprint bezeichnet. Wenn für jeden Kontrollpunkt, der im Blueprint eines Dokuments aufgeführt ist, ein Event auftritt, hat das Dokument die Pipeline fehlerfrei durchlaufen.
Tritt für einen erwarteten Kontrollpunkt innerhalb eines bestimmten Zeitraums seit der Erzeugung kein Ereignis auf, gilt das Dokument als fehlerhaft.
Jeder Ausgabekanal hat seinen eigenen Kontrollpunkt. Für jeden Kontrollpunkt wurde ein kleines Programm entwickelt, das feststellen kann, ob ein Dokument den Kontrollpunkt passiert hat und in diesem Fall einen Event erzeugt. Diese Programme werden Agents genannt.
Um nun Auswertungen machen zu können, müssen alle diese Events irgendwo zentral gesammelt werden. Dazu bietet sich eine Messaging Queue an. Die Agents schreiben die Events in die Message Queue. Der Event Service, eine weitere Komponente des CCM Cockpits, liest die Events aus der Queue und speichert sie in einer relationalen Datenbank. Aus den Daten dieser Datenbank werden dann Auswertungen und Aggregationen für die Webansicht des CCM-Cockpits erstellt.
Cockpit-Ansicht
Die gesammelten Daten werden über eine Webansicht zur Verfügung gestellt.
Kernstück des CCM-Cockpits ist das Dashboard.
Im Cockpit werden die Events aggregiert dargestellt. So ist auf einen Blick ersichtlich, wie viele Dokumente die Pipeline erfolgreich und wie viele sie fehlerhaft durchlaufen haben, aber auch an welchen Kontrollpunkten Probleme auftraten.
Diese Ansicht wird hauptsächlich verwendet, um nach einer nächtlichen Tagesverarbeitung zu überprüfen, ob alles funktioniert hat. Die Ansicht bietet aber auch die Möglichkeit, den Zeitraum der Aggregation festzulegen. Dadurch kann sie auch für länger laufende Jahresverarbeitungen verwendet werden.
Für die Nachverfolgung von Dokumenten wurde eine Suchansicht erstellt, die es ermöglicht, Events nach verschiedenen Kriterien zu suchen und zu filtern und so Details zu einzelnen Dokumenten abzurufen.
Performanz
Während es für die Aggregations-Funktionalität ausreichend war, sinnvolle Indizes auf der Datenbank zu erstellen, war für das Schreiben der Menge an Events, die während der Jahresrechnung anfallen, eine tiefgreifendere Lösung erforderlich. Die einfache Lösung, eine Nachricht nach der anderen aus der Message Queue zu lesen und in die Datenbank zu schreiben, brachte die Datenbank-Engine schnell an ihre Grenzen. Durch das Batching mehrerer Nachrichten konnte dieses Problem gelöst werden. Dies kann jedoch schnell zu Speichermangel und damit zu Stabilitätsproblemen führen.
Wir haben uns schliesslich für einen Ansatz mit zwei Queues entschieden. In der ersten Queue befinden sich die einzelnen Events als Messages. In der zweiten Queue enthält eine einzelne Message mehrere Events. Auf diese Weise können wir einfach "Batching" betreiben und die so erzeugten Messages direkt in die Datenbank schreiben.
Das würden wir anders machen
Wieder einmal hat sich gezeigt, wie wertvoll es ist, so schnell wie möglich in Produktion zu gehen. Obwohl wir ständig Einblick in das laufende Produkt hatten und dieses auch immer auf ein Testsystem ausgeliefert haben, sind wir recht spät mit produktiven Daten in das Produktivsystem gestartet. Es stellte sich heraus, dass es einige Probleme gab, die wir nicht vorhergesehen hatten. Das hat dazu geführt, dass das System nach der ersten Phase noch einige Probleme hatte. Rückblickend wäre es wichtig gewesen, noch früher in ein Produktivsystem zu gehen, um das System unter realen Bedingungen testen zu können.
Fazit
Mit dem CCM-Cockpit durften wir das Monitoring einer Dokumente-Pipeline aufbauen und vieles lernen. Am Ende entstand ein Produkt, welches die Gebäudeversicherung Bern im täglichen Betrieb unterstützt. Wir möchten uns bei der Gebäudeversicherung Bern und bei Ajila für die gute Zusammenarbeit bedanken. Es het gfägt!
Projekt Details
- Auftraggeber: Gebäudeversicherung Bern
- Technologien: Kotlin, Spring Boot, Vue, Microsoft SQL RabbitMQ.
- Beteiligte Firmen: Gebäudeversicherung Bern, Ajila AG und re:thinc GmbH
