Nov09
CQRS im Integrations-Szenario

Im letzten Blog Beitrag habe ich über das Architekturprinzip CQRS geschrieben. In diesem Artikel möchte ich mit einem fiktiven Praxisbeispiel zeigen, wie weit man mit CQRS gehen kann und wie CQRS bei der Integration von Anwendungen helfen kann.

Szenario

Man stelle sich einen großen Konzern vor, der die Kundendaten in einem (teuren) SAP System (SAP Geschäftspartner) speichert und verwaltet.
Zusätzlich gibt es alte Legacy Anwendungen auf einem zOS System, die nachts im Batch massenhaft Daten verarbeiten und dabei die Kundendaten benötigen.
Desweiteren gibt es ein Online-Portal auf das Kunden, Makler und Kooperationspartner über Web-Browser oder von mobilen Endgeräten zugreifen. Auch hier werden die Kundendaten benötigt.

Es muss eine Integrationslösung gefunden werden, mit der die Legacy-Anwendungen und das Online-Portal auf die Kunden-Daten im SAP Geschäftspartner zugreifen können. Dabei sind besondere nicht funktionale Anforderungen zu berücksichtigen.
Verfügbarkeit, flexible Skalierung und Sicherheit sind beim Online-Portal besonders wichtig. Das Portal soll 24*7, im Internet, verfügbar sein. Die Last steigt dabei nicht planbar durch immer neue Kooperationspartner und eine steigende Anzahl mobiler Endgeräte stetig.
Für die Legacy-Anwendungen spielt Zugriffs-Performance auf die Kundendaten eine besonders wichtige Rolle, da das Batch-Fenster zeitlich begrenzt ist und Massendaten verarbeitet werden. Zudem hatten die Altsysteme bisher eine eigene Datenbank mit den Kundendaten und sind auf lokale Datenzugriffe ausgelegt.

Lösungsansätze

Der klassische Lösungsansatz ist die Bereitstellung eines Service, der die Kundendaten vom SAP liefert. Dazu wird ein Web Service implementiert, der auf das SAP System zugreift und der von den anderen Systemen aufgerufen werden kann.
Bei diesem Ansatz sind allerdings eine Reihe von Problemen zu lösen.

Zum SAP System müssten extrem performante Zugriffswege bereit gestellt werden. Die alten Legacy Systeme müssen aufwendig angepasst werden und einen remote Zugriff auf SAP bzw. auf den Web Service implementieren. SAP muss hoch verfügbar (24*7) sein, extrem gut skalieren und auch künftig einfach und schnell skalierbar sein um der nicht planbaren Last aus dem Web- und mobilen Umfeld gerecht zu werden. Zusätzlich entstehen potentielle Sicherheitslücken, da aus dem Internet auf Services von SAP zugegriffen wird.
Dieses Vorgehen würde teuer und aufwendig. Zum einen wegen der Anpassungen der Legacy Systeme, zum anderen wegen der Hardware Austattung der SAP Infrastruktur. Je nach Lizenz des SAP Systems werden auch die Lizenzen sehr teuer, wenn von so vielen unterschiedlichen Systemen und Usern auf SAP zugegriffen wird. Auch steigen die künftigen Kosten, da SAP mit dem Wachstum der Internetzugriffe mit wachsen muss. Die Gewährleistung der Sicherheit wird ebenso aufwendiger und teurer.
Da die verschiedenen Systeme (Legacy, SAP, Web-Portal) meist von verschiedenen Organisationseinheiten gewartet werden, entstehen auch Abstimmungsaufwände. SAP kann nicht einfach für Wartungsarbeiten und Releasewechsel runter gefahren werden, es muss immer in Abstimmung mit den Nutzern der Kundendaten erfolgen.

Der zweite Lösungsansatz ist die Bereitstellung von Replikats-Datenbanken auf dem zOS System für die Legacy-Anwendungen und in der DMZ für das Online-Portal. Jedes System greift nur auf das eigene Replikat zu. Die Replikate werden Nachts im Batch durch einen Replikats-Lauf erstellt. Dieser Ansatz führt zwar zu einer Entkopplung der drei Systeme, es stehen aber nach wie vor einige Probleme im Raum.

Der Batch auf dem zOS für die Massenverarbeitung kann erst starten, wenn der Replikats-Erstellungs-Batch abgeschlossen ist. Die Daten in den Replikaten sind nur tagesaktuell, was insbesondere im Online-Portal kritisch ist. Wenn dann auch noch Änderungen in die Replikate geschrieben werden, entsteht eine aufwendige Daten-Synchronisation.

Der dritte Lösungsansatz ist eine Mischung aus den beiden bisher genannten und dem Einsatz von CQRS. Diesen werde ich im folgenden vorstellen.

CQRS als Integrationslösung

CQRS-Integration

CQRS-Integration

Der Lösungsansatz basiert auf einem Master-Slave Prinzip der Daten. Gemäß CQRS gibt es dabei eine Trennung in ein Write- und ein Read-Modell. Der Master hat das Write-Modell und liegt im SAP-System. Diese Daten sind führend. Zusätzlich gibt es je einen Slave auf dem zOS und in der DMZ mit einem Read-Modell, das read-only ist.
Schreibzugriffe (Commands) gehen immer auf den Master im SAP. Lesezugriffe (Queries) gehen an die Slaves. Dabei gehen Queries von den Legacy Systemen an den Slave auf zOS und Queries aus dem Online-Portal bzw. dem Internet an den Slave in der DMZ.

Erfolgt eine Änderung eines Datensatzes im Write-Modell des Masters, publiziert dieser ein Update-Event. Die Slaves aktualisieren darauf hin ihr Read-Modell.

Die Vorteile dabei sind:

  • Eine Entkopplung der Systeme (SAP kann unabhängig von den Nutzern des Web-Portals und den Legacy Systemen in die Wartung gehen und runter gefahren oder Erweitert werden)
  • SAP muss nicht mit dem Wachstum des Internet Portals mit wachsen (Kostenvorteil)
  • Die nicht funktionale Anforderungen werden gezielt pro Nutzungsszenario umgesetzt
    • nur der Slave in der DMZ ist 24*7 verfügbar, kann elastisch skalieren und spezielle Security Features umsetzen
    • Die Legacy Systeme haben mit den lokalen Datenzugriffen eine optimale Performance
  • Die Daten in den Slaves sind near time aktuell (fast real time, je nach Geschwindigkeit der Event Verarbeitung)
  • Das Read Modell kann, für optimierte Zugriffe, anderes sein als das Write Modell . Z.B. können die Daten im Read Modell des DMZ Slaves im JSON Format gespeichert werden, falls sie genau so durch die Internet Anwendungen benötigt werden. Damit spart man sich die Transformation in das JSON Format bei jeder einzelnen Query und muss sie nur noch beim Speichern der Daten in das Read Modell durch den Event Handler durchführen.
  • Daten, die Häufig benötigt werden, aber erst aus dem Write Modell berechnet werden müssen, können bereits durch den Event Handler beim speichern im Read Modell vorberechnet werden. So kann z.B. aus dem Geburtsdatum (das im Write Modell steht) das Alter berechnet und im Read Modell gespeichert werden. Ein jährliches Update Event, das das Alter neu berechnet ist dazu natürlich notwendig.

Es gibt aber auch eine Reihe von Herausforderungen, die gelöst werden müssen:

  • Die Update-Events müssen garantiert zugestellt und verarbeitet werden
  • Wenn Update-Events nicht verarbeitet oder zugestellt werden können, muss darauf reagiert und der Fehler behoben werden. Solange keine aktuellen Daten in den Slaves stehen, besteht eine Inkonsistenz der Daten zwischen Master und Slave
  • Es ist ein intensives Monitoring notwendig um die oben genannten Fehlersituationen erkennen und darauf reagieren zu können
  • Evtl. ist ein Automatismus notwendig, der den Start des Batch-Laufs auf dem Mainframe unterbindet, wenn es nicht verarbeitete Update-Events gibt und deshalb die Daten im zOS Slave nicht aktuell sind (z.B. wenn Events im Dead Letter Channel oder im Invalid Message Channel stehen)

Um den Master-Slave Mechanismus und die konkreten Technologien zu abstrahieren, wird ein Kunden-Daten-Services mit einer fachlichen Schnittstelle definiert. In der Service Implementierung kann dann entschieden werden, wohin die Anfragen geroutet werden. Schreibende Zugriffe gehen als asynchrones Command immer an das SAP, lesende Zugriffe als synchrone Query an einen Slave. Dabei ist es durchaus legitim, einen speziellen Service-Endpoint auf dem zOS, in der Technologie der Legacy-Systeme, zu implementieren um eine maximale Performance zu erreichen.

Durch die Abstraktion durch den Kunden-Daten-Service, sind die Systeme austauschbar und Anfragen können zu einem späteren Zeitpunkt, oder dynamisch, anders geroutet werden, ohne dass Nutzer etwas davon merken. So ist es z.B. möglich Queries direkt ins SAP anstatt in die DB auf zOS zu senden, wenn optimierte Zugriffswege vom Mainframe ins SAP implementiert wurden.

Fazit

Die Verteilung von Daten, um optimierte Zugriffswege zu implementieren und Kosten und Abhängigkeiten zu reduzieren, ist ein valider Weg. Die Prinzipien von CQRS helfen dabei, klare Verantwortlichkeiten zu haben und sich vor der Synchronisations-Hölle zu schützen. Die Abstraktion durch Services bettet das Prinzip sauber in eine SOA Landschaft ein und macht die Datenverteilung und Technologien für die Nutzer Transparent.

In einem späteren Artikel werde ich noch darauf eingehen, wie die Update Events, mit Hilfe von Event Sourcing und einem commit log, zwischen Master und Slave verteilt werden können.

Schreibe einen Kommentar

Anmelden um einen Kommentar abzugeben.

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*