Die fünf wichtigsten Integrationsmuster

Daten sind wertvolle Unternehmens-Assets. Oft ist es jedoch schwierig, auf sie zuzugreifen, sie zu orchestrieren und zu interpretieren.

Die Übertragung von Daten zwischen verschiedenen Systemen erfolgt nicht immer in einem Standardformat. Bei der Datenintegration werden Daten agnostisch, sodass Zugriff und Verarbeitung problemlos möglich sind.

Damit Daten noch schneller und besser nutzbar werden, können Entwickler Datenintegrationsmuster verwenden und auf diese Weise den Integrationsprozess standardisieren.

Wie bei einem Wanderweg werden Muster basierend auf ihrer Verwendung entdeckt und festgelegt. Der Perfektionsgrad von Mustern ist sehr unterschiedlich. Doch Muster können abhängig davon, für welche Geschäftsanforderungen Lösungen erforderlich sind, optimiert oder angepasst werden. Sie können sich den geschäftlichen Anwendungsfall als Instanziierung des Musters vorstellen, das heißt, eine Nutzung des generischen Prozesses für die Datenbewegung und -bearbeitung.

Es gibt fünf Datenintegrationsmuster, die auf geschäftlichen Anwendungsfällen und cloudbasierten Integrationsmustern basieren.

Bei der Datenmigration werden Daten von einem System auf ein anderes übertragen. Eine Migration umfasst Folgendes: Ein Quellsystem, in dem sich die Daten vor der Ausführung befinden. Die Kriterien, die den Umfang der zu migrierenden Daten bestimmen. Eine Transformation, die der Datensatz durchläuft. Ein Zielsystem, in das die Daten eingefügt werden. Eine Fähigkeit, die Ergebnisse der Migration zu erfassen, um den Endzustand mit dem gewünschten Zustand zu vergleichen.

Datenmigration ist für alle Arten von Datensystemen von grundlegender Bedeutung. Wir verbringen sehr viel Zeit mit der Erstellung und Pflege von Daten. Migration ist wichtig, damit die Daten unabhängig von den Tools bleiben, mit denen diese Daten erstellt, angezeigt und verwaltet werden. Ohne Migration würden wir all die Daten, die wir gesammelt haben, beim Wechsel von Tools verlieren. Das wäre verheerend für unsere Produktivität in der digitalen Welt.

Datenmigration tritt unter anderem in folgenden Fällen auf: Bei der Umstellung von einem System auf ein anderes, bei der Umstellung auf eine andere oder neuere Instanz dieses Systems, beim Hochfahren eines neuen Systems in Ihrer aktuellen Infrastruktur, beim Sichern von Datensätzen, beim Hinzufügen von Knoten zu Datenbank-Clustern, beim Ersetzen von Datenbank-Hardware und beim Konsolidieren von Systemen.

Bei einem Broadcast, auch bekannt als „unidirektionale Eins-zu-viele-Synchronisierung“, werden Daten von einem einzelnen Quellsystem in Echtzeit (oder nahezu in Echtzeit) kontinuierlich an eine Vielzahl von Zielsystemen übertragen.

Wenn es notwendig ist, Daten zwischen mehreren Systemen über längere Zeiträume hinweg synchron zu halten, ist eines der folgenden Muster erforderlich: Broadcast, bidirektionale Synchronisierung oder Korrelation. Das Broadcast-Muster überträgt Daten genau wie das Migrationsmuster nur in eine Richtung, aus dem Quellsystem ins Zielsystem. Im Gegensatz zum Migrationsmuster ist das Broadcast-Muster transaktional.

Das bedeutet, dass die Logik der Nachrichtenprozessoren nicht für alle enthaltenen Elemente, sondern nur für vor Kurzem geänderte Elemente ausgeführt wird. Stellen Sie sich das Broadcast-Muster als Schiebefenster vor, das nur Elemente mit Feldwerten erfasst, die sich seit der letzten Broadcast-Ausführung geändert haben.

Ein weiterer großer Unterschied besteht im Design der Implementierung des Musters. Migrationen werden so optimiert, dass sie große Datenmengen und eine hohe Zahl von Datensätzen parallel verarbeiten und bei Fehlern ordnungsgemäß beendet werden können. Broadcast-Muster sind für eine schnelle Verarbeitung der Datensätze optimiert. Außerdem wird durch ihre hohe Zuverlässigkeit vermieden, dass kritische Daten während der Übertragung verloren gehen.

Das Broadcast-Muster ist äußerst wertvoll, wenn System B nahezu in Echtzeit Informationen benötigt, die aus System A stammen oder sich dort befinden. Zum Beispiel: Sie möchten ein Echtzeit-Reporting-Dashboard erstellen – ein Ziel mehrerer Broadcast-Anwendungen, das Echtzeit-Aktualisierungen über Vorgänge in mehreren Systemen erhält.

Sie möchten sofort mit der Erfüllung von Aufträgen beginnen, die aus Ihrem CRM-, E-Commerce- oder internen Tool stammen. Das Auftragsabwicklungssystem ist zentralisiert, und es spielt keine Rolle, über welchen Kanal der Auftrag eingegangen ist. Sie möchten alle 100 Minuten eine Benachrichtigung bezüglich der Temperatur Ihrer Dampfturbine an ein Überwachungssystem senden. Sie möchten eine Meldung an das Patientenverwaltungssystem einer Arztpraxis senden, wenn einer der Patienten dieser Arztpraxis in der Notaufnahme angemeldet wird. Es gibt unzählig viele Beispiele für Fälle, in denen Sie Daten von einem Quellsystem über das Broadcast-Muster an ein anderes übertragen möchten.

Ob das Broadcast-Muster angebracht ist, können Sie einfach anhand der folgenden Kriterien ermitteln:

• Muss System B in Echtzeit über das Ereignis informiert werden? – Ja
• Müssen Daten von A nach B automatisch ohne Mitarbeitereingriff übertragen werden? – Ja
• Muss System A erfahren, was mit dem Objekt in System B geschieht? – Nein

Die erste Frage hilft Ihnen dabei zu entscheiden, ob Sie das Migrationsmuster oder Broadcast verwenden sollten. Dies ist abhängig davon, ob eine Echtzeit-Übertragung der Daten notwendig ist. Für alles, was mindestens ungefähr jede Stunde benötigt wird, ist in der Regel das Broadcast-Muster optimal. Allerdings gibt es abhängig von der Datenmenge auch Ausnahmen.

Die zweite Frage schließt „On Demand“-Anwendungen aus. Broadcast-Muster werden normalerweise durch eine Push-Benachrichtigung oder einen geplanten Auftrag, also ohne Mitarbeitereingriffe, initiiert.

Mit der letzten Frage ermitteln Sie, ob Sie die beiden Datensätze vereinigen müssen, damit sie über zwei Systeme synchronisiert werden. Dies wird als bidirektionale Synchronisierung bezeichnet. Für unterschiedliche Anforderungen sind verschiedene Datenintegrationsmuster erforderlich. In Verbindung mit dem Broadcast-Muster ist jedoch eine sehr viel flexiblere Kopplung der Anwendungen möglich. Daher empfehlen wir die Verwendung von zwei Broadcast-Anwendungen statt einer bidirektional synchronisierten Anwendung.

Bei dem Datenintegrationsmuster der bidirektionalen Synchronisierung werden zwei Datensätze in zwei verschiedenen Systemen zusammengeführt. Sie fungieren dann als ein System, wobei jedoch die Notwendigkeit des Vorhandenseins verschiedener Datensätze berücksichtigt wird. Diese Art von Integrationsanforderung entsteht dadurch, dass mit verschiedenen Tools oder Systemen unterschiedliche Funktionen am selben Datensatz durchgeführt werden.

Sie könnten zum Beispiel ein System für den Auftragseingang und die Auftragsverwaltung haben und ein anderes für den Kundenservice. Es handelt sich möglicherweise um Best-of-Breed-Systeme, die beide wichtige Funktionen haben. Daher möchten Sie diese Systeme statt einer Suite verwenden, die beide Funktionen unterstützt und eine gemeinsame Datenbank hat. Wenn Sie für die gemeinsame Nutzung der Datensätze bidirektionale Synchronisierung nutzen, können Sie beide Systeme verwenden und gleichzeitig einen einheitlichen Echtzeit-Überblick über die Daten in beiden Systemen behalten.

Bidirektionale Synchronisierung kann sowohl eine befähigende als auch eine rettende Funktion haben. Dies ist abhängig von den Situationen, die für den Einsatz der bidirektionalen Synchronisierung sprechen. Wenn zwei oder mehr unabhängige und isolierte Darstellungen derselben Realität vorliegen, können Sie Ihre Prozesse mit bidirektionaler Synchronisierung optimieren.

Andererseits können Sie bidirektionale Synchronisierung verwenden, um von einer Suite von Produkten, die zwar miteinander kompatibel sind, deren einzelne Funktionen jedoch eventuell nicht optimal sind, zu einer Suite zu wechseln, die Sie manuell auswählen und zusammen über eine Integrationsplattform für Unternehmen wie die Anypoint Platform von MuleSoft integrieren.

Eine bidirektionale Synchronisierungsanwendung ist besonders dann von Vorteil, wenn Objektdarstellungen der Realität umfassend und konsistent sein müssen. Wenn Sie beispielsweise eine einheitliche Kundensicht benötigen, können Sie dies manuell erreichen. Dazu geben Sie allen Beteiligten Zugriff auf die Systeme, die eine Darstellung eines Kundenaspekts enthalten. Viel effektiver wäre es jedoch, wenn Sie auflisten, welche Felder für ein Kundenobjekt in welchen Systemen sichtbar sein sollen und welche Systeme verantwortlich sind.

In den meisten Unternehmenssystemen gibt es eine Möglichkeit zur Erweiterung von Objekten, sodass Sie die Datenstrukturen des Kundenobjekts entsprechend ändern können, um diese Felder einzubeziehen. Bei einer einfachen Lösung können Sie Integrationsanwendungen dann (über eine gemeinsame Integrationsplattform) als Punkt-zu-Punkt-Anwendungen erstellen. Wenn mehrere Systeme im Spiel sind, ist hierfür ein erweitertes Weiterleitungssystem wie Publish/Subscribe oder ein warteschlangenbasiertes Weiterleitungsmodell erforderlich.

Zum Beispiel sollte Verkäufern der Status einer Lieferung bekannt sein. Der Lagerort, an dem sich die Lieferung befindet, ist für sie jedoch nicht von Interesse. Ähnlich verhält es sich beim Lieferpersonal: Sie müssen den Namen des Kunden kennen, für den die Lieferung vorgesehen ist. Welchen Preis der Kunde bezahlt hat, ist für sie jedoch unbedeutend. Bei der bidirektionalen Synchronisierung haben beide Beteiligten eine ihren Bedürfnissen angepasste Echtzeit-Übersicht über denselben Kunden.

Das Datenintegrationsmuster der Korrelation ist ein Design, das die Schnittstelle zwischen zwei Datensätzen identifiziert und für diesen abgegrenzten Datensatz nur dann eine bidirektionale Synchronisierung ausführt, wenn dieses Element ursprünglich in beiden Systemen vorhanden war. Ähnlich wie beim bidirektionalen Muster die Vereinigung der abgegrenzten Datensätze synchronisiert wird, erfolgt bei der Korrelation eine Synchronisierung der Schnittstelle.

Im Fall des Korrelationsmusters wurden die in beiden Systemen vorhandenen Elemente möglicherweise in jedem dieser Systeme manuell erstellt. Zum Beispiel könnten zwei Verkaufsmitarbeiter denselben Kontakt in beiden CRM-Systemen eingeben. Oder die Elemente wurden im Rahmen einer anderen Integration in die Systeme aufgenommen. Für das Korrelationsmuster ist der Ursprung dieser Objekte unbedeutend. Die Synchronisierung erfolgt agnostisch, solange die Elemente in beiden Systemen vorhanden sind.

Das Datenintegrationsmuster der Korrelation ist nützlich für Fälle, in denen zwei Gruppen oder Systeme Daten nur dann gemeinsam nutzen möchten, wenn beide über Datensätze verfügen, die dieselben Elemente oder Personen in der Realität darstellen. Eine Krankenhausgruppe könnte zum Beispiel zwei Krankenhäuser in derselben Stadt haben. Möglicherweise möchten Sie die Daten für beide Krankenhäuser freigeben. Wenn ein Patient in einem der Krankenhäuser behandelt wird, liegen dann aktuelle Daten über in beiden Krankenhäusern erfolgte Behandlungen vor.

Für eine Integration in diesem Szenario könnten Sie entscheiden, zwei Integrationen nach dem Broadcast-Muster zu erstellen: eine von Krankenhaus A zu Krankenhaus B und eine von Krankenhaus B zu Krankenhaus A. Dadurch stellen Sie sicher, dass die Daten synchronisiert werden. Allerdings müssten Sie zwei Integrationsanwendungen verwalten.

Um nicht zwei Anwendungen verwalten zu müssen, können Sie das Muster der bidirektionalen Synchronisierung zwischen Krankenhaus A und Krankenhaus B verwenden. Zur Steigerung der Effizienz könnten Sie jedoch bei der Synchronisierung die Einbeziehung von Daten von solchen Patienten des Krankenhauses B ausschließen, die keine Beziehung zu Krankenhaus A haben. Dies könnten Sie ab dem Zeitpunkt der Erstellung der Patientenakte in Echtzeit ausführen. Das Korrelationsmuster ist wertvoll, da Objekte nur bidirektional synchronisiert werden, wenn die jeweiligen Informationen erforderlich sind, statt immer alle Datensätze in beide Richtungen zu übertragen.

Weil beim Datenintegrationsmuster der Korrelation die „unnötigen“ Daten herausgefiltert werden, eignet es sich besonders dann, wenn die Kosten zusätzlicher Daten ihren Nutzen übersteigen. Zum Beispiel wäre ein solcher Fall denkbar, wenn eine Universität, die zu einem größeren Hochschulsystem gehört, Berichte bezüglich aller Studierenden generieren möchte.

Studierende, die nicht an dieser Universität studiert haben, sollten wahrscheinlich nicht einbezogen werden. Möglicherweise möchten Sie jedoch die Module einbeziehen, die diese Studierenden an anderen Universitäten des Hochschulsystems abgeschlossen haben. In diesem Fall würde das Korrelationsmuster den Arbeitsaufwand entweder bei der Integration oder bei der Berichtgenerierung enorm verringern. Sie könnten nämlich nur die Informationen für die Studierenden, die an beiden Universitäten studiert haben, synchronisieren.

Bei der Aggregation werden Daten aus mehreren Systemen entnommen oder empfangen und in ein System eingefügt. Zum Beispiel könnten sich Kundendaten in drei verschiedenen Systemen befinden, und ein Datenanalyst möchte einen Bericht mit Daten aus allen drei Systemen generieren. Man könnte eine tägliche Migration aus jedem der Systeme in ein Daten-Repository erstellen und diese Datenbank dann entsprechend abfragen. In diesem Fall müsste allerdings eine weitere Datenbank überwacht und synchronisiert werden.

Darüber hinaus müsste das Daten-Repository im Fall von Änderungen in den drei anderen Systemen ständig aktualisiert werden. Ein weiterer Nachteil besteht darin, dass die Daten einen Tag alt wären. Für Echtzeit-Berichte müsste der Analyst daher die Migrationen entweder manuell einleiten oder einen Tag warten. Es wäre möglich, drei Broadcast-Anwendungen einzurichten. Dies würde bewirken, dass die Reporting-Datenbank stets auf dem aktuellen Stand der letzten Änderungen in allen drei Systemen ist. Jedoch müsste diese Datenbank, in der nur replizierte Daten gespeichert sind, dennoch gepflegt werden, damit regelmäßige Abfragen möglich sind. Darüber hinaus wird es einige verschwendete API-Aufrufe geben, um sicherzustellen, dass die Datenbank nie mehr als X Minuten von der Echtzeit abweicht.

Hier kommt das Aggregationsmuster ins Spiel. Wenn Sie eine Anwendung erstellen oder eine unserer Vorlagen verwenden, die auf einem Aggregationsmuster basiert, können Sie bedarfsgerecht mehrere Systeme abfragen, die Datensätze zusammenführen und auf beliebige Art und Weise verwenden.

Sie können zum Beispiel eine Integrationsanwendung erstellen, die die verschiedenen Systeme abfragt, die Daten zusammenführt und dann einen Bericht generiert. Hierdurch erübrigt sich eine separate Datenbank, denn die Berichte stehen in beliebigen Formaten wie zum Beispiel .csv zur Verfügung. Den Report können Sie dort ablegen, wo Reports direkt gespeichert werden.

Der Wert des Aggregationsmusters liegt darin, dass Sie Daten aus mehreren Systemen extrahieren und verarbeiten und in einer vereinten Anwendung zusammenführen können. Daher sind die Daten immer auf dem neuesten Stand, werden nicht repliziert und können zu beliebigen Datensätzen weiterverarbeitet oder zusammengeführt werden.

Das Aggregationsmuster ist wertvoll beim Erstellen von Orchestrierungs-APIs, mit denen Daten von mehreren Systemen abgerufen und zu einer Antwort zusammengefasst werden, um Legacy-Systeme zu „modernisieren“. Ein weiterer Anwendungsfall ist das Erstellen von Berichten oder Dashboards, die Daten aus mehreren Systemen abrufen, um damit eine Erfahrung bereitzustellen.

Des Weiteren wäre Aggregation nützlich, wenn zu Konformitäts- oder Prüfzwecken verwendete Systeme zugehörige Daten aus mehreren Systemen benötigen. Das Aggregationsmuster hilft sicherzustellen, dass Ihre Konformitätsdaten in einem System gespeichert werden, auch wenn es sich um eine Zusammenlegung relevanter Daten aus mehreren Systemen handelt. Daher können Sie sich schnell einen Überblick verschaffen, ohne sich dazu Kenntnisse über die verschiedenen Systeme aneignen zu müssen.