Länderübergreifende Abfragen

Länderübergreifende Abfragen können auf vielfältige Weise implementiert werden. Im Folgenden werden drei Pattern zur Umsetzung dargestellt.

Integration lokal gespeicherter fremder Daten

Fremde Länder lösen im allgemeinen Business Events aus. Als Reaktion hierauf werden für übergreifende Abfragen die benötigten fremden Daten lokal gespeichert. Die Implementierung kann dann in den unter CQRS beschriebenen Ausbaustufen erfolgen.

Wichtig ist hierbei, die Kopplung zwischen den Bausteinen zu beachten. Dementsprechend ist zu überlegen, ob übergreifende Abfragen besser in einer Geschäftsprozesskomponente zu implementieren sind. Wir werden dies weiter unten für Reports aufgreifen.

Orchestrierung auf Serviceebene

Mithilfe des sogenannten API Composition-Patterns können die Query-Services der einzelnen Länder ebenfalls zusammengeschlossen werden, um Aggregat-übergreifende Abfragen zu implementieren. Jeder Service kann dabei beispielsweise nach CQRS-Muster implementiert werden. Die folgende Abbildung zeigt das Pattern:

Hier ist die Kopplung zwischen den Ländern behoben.

Wichtig hierbei ist, dass dieses Pattern folgende Nachteile mit sich bringt, die gegen die Einfachheit der Implementierung gehalten werden müssen:

• Die Gefahr von Timeouts ist deutlich höher als bei der Variante der lokalen Speicherung.
• Es kann nur eine einfache Abfragesemantik implementiert werden.

Sammler

Im Kontext des Reportings wird das vorherige Pattern dahingehend erweitert, dass über einen Service die Daten einzelner Länder gelesen und in der GP-Komponente persistiert werden.

Um der Problematik der Timeouts zu entgehen, wird dieser "Sammler"-Service als Command Service implementiert. Die Daten werden nun über einen einfachen Query Service der GP-Komponente aus der Datenbank gelesen.

Dieses Sammeln kann auch über einen Workflow erfolgen. Dies kann sinnvoll sein, wenn die Daten noch transformiert und konvertiert werden müssen.

Auch hier werden die Daten über einen einfachen Query Service der GP-Komponente aus der Datenbank gelesen.

Speziell für das Reporting wird ein Report durch die Geschäftsprozesskomponente bereitgestellt, die den Report erstellen / bereitstellen soll, da strukturell beispielsweise kein Unterschied bzgl. der Orchestrierung zu Workflows besteht. In den Ländern sind die Bestandsdaten der CS 3.0-Bausteine persistiert. Reports arbeiten häufig landübergreifend, um übergreifende Auswertungen o.ä. zu fahren.

Zur Umsetzung wird ein Service in der GP-Komponente, die den Report erstellen soll, als ProcessService implementiert. Dieser soll maximal stabil sein, sammelt und aggregiert die Daten per ETL-Prozess als Workflow. Dabei gibt es die folgenden Phasen:

• Sammeln der Daten
• Transformieren
• Report erstellen