Event-Driven Architecture
Inhaltsverzeichnis
Das Wichtigste im Überblick
- Event-Driven Architecture (EDA) nutzt Ereignisse als zentrale Kommunikationsmittel zwischen Systemen und ermöglicht asynchrone Kommunikation statt synchroner Anfragen.
- EDA fördert Skalierbarkeit, Fehlertoleranz und eine effiziente Ressourcennutzung, da Systeme nur bei relevanten Ereignissen aktiv werden.
- Die Entkopplung von Systemen in EDA ermöglicht eine hohe Flexibilität und vereinfacht das Hinzufügen neuer Komponenten, ohne bestehende Systeme zu beeinträchtigen.
- In SAP wird EDA durch Lösungen wie SAP Event Mesh und SAP Integration Suite umgesetzt, die Echtzeitkommunikation und Event-Management ermöglichen.
Was ist Event-Driven Architecture?
Event-Driven Architecture (EDA, deutsch: ereignisgesteuerte Architektur) ist ein Architekturmuster, bei dem Ereignisse als zentrales Kommunikationsmittel zwischen den Softwarekomponenten dienen. Man spricht hier auch von asynchroner Kommunikation. Um zu verstehen, wie EDA genau funktioniert, wird im Folgenden kurz erklärt, wie eine Softwarearchitektur funktioniert, die auf synchroner Kommunikation aufbaut.
Synchrone Kommunikation
Synchrone Kommunikation zwischen zwei Systemen bedeutet, dass System A eine Anfrage an System B stellt. System A wartet dann so lange, bis System B eine Antwort gibt. Erst dann fährt System A fort, beispielsweise, indem es eine weitere Anfrage an ein System C stellt.
Beispiel:
Ein Kunde kauft Produkt A in einem Onlineshop. Das Bestell-System registriert die Bestellung und gibt dem Lagersystem eine Mitteilung, dass Produkt A einmal bestellt wurde. Wenn das Lager-System eine Mitteilung mit der Bestätigung gibt, dass die Kommissionierung eingeleitet wird, kann das Bestell-System weiter machen und dem Buchhaltungssystem eine Nachricht schicken, dass eine Zahlung für Produkt A verarbeitet und eine Rechnung erstellt und verschickt werden muss.
Wenn die Buchhaltung zurückgemeldet hat, dass es die Zahlung verarbeitet hat und die Rechnung verschicken wird, kann das Bestellsystem dem Marketing-System mitteilen, dass es einen neuen Kunden gibt, der mit Informationen über Rabattaktionen versorgt werden muss.
Wenn das Marketing-System mitteilt, dass der neue Kunde im E-Mail-Verteiler aufgenommen wurde, kann das Bestellsystem den Prozess abschließen.
Synchrone Kommunikation zwischen Anwendungen
Event-Driven Architecture: Asynchrone Kommunikation
Im Unterschied zur synchronen Kommunikation setzt Event-Driven Architecture auf asynchrone Kommunikation zwischen den Systemen. Das bedeutet, dass System A (Event Producer) eine Veränderung im System auslöst, die als Ereignis bezeichnet wird.
Der Ereignis-Broker informiert die anderen beteiligten Systeme (Event Consumer) über das Ereignis. Haben die Event-Consumer auf das Ereignis reagiert, geben sie eine Rückmeldung an den Broker, der dann eine Bestätigung an den Event Consumer schickt.
Beispiel:
Ein Kunde kauft ein Produkt in einem Onlineshop. Das Bestell-System registriert die Bestellung und ändert den Status des Produkts im System auf „Verkauft“. Diese Änderung ist das Ereignis. Der Ereignis-Broker informiert dann die Event Consumer (Lager-, Buchhaltungs- und Marketingsysteme) über diese Änderung.
Haben alle beteiligten Systeme auf das Ereignis wie vorgeschrieben reagiert, erhält der Broker eine Rückmeldung. Hat er von allen Consumern positive Rückmeldungen erhalten, kann er dies dem Bestell-System gesammelt mitteilen, das dann beispielsweise eine Bestellbestätigung an den Kunden schickt.
Asynchrone Kommunikation in einer Event-Driven Architecture
Die Struktur von EDA
Um noch einmal alle wichtigen Begriffe im Bereich der Event-Driven Architecture, folgt hier noch einmal die Struktur der EDA.
- Event Producer (Ereignisproduzent): Das System, das ein Ereignis erzeugt. Im Beispiel das Bestell-System.
- Event (Ereignis): Das Ereignis selbst, das eine bedeutende Änderung im System darstellt. Im Beispiel eine Bestellung im Shop.
- Event Consumer (Ereigniskonsument): Das System, das auf das Ereignis reagiert und entsprechende Aktionen ausführt. Im Beispiel das Lagersystem oder das Buchhaltungssystem.
- Event Broker (Ereignis-Broker): Eine Middleware, die das Ereignis von einem Producer zu einem oder mehreren Event-Consumern weiterleitet. Im Beispiel einfach als Broker bezeichnet.
Für die Kommunikation zwischen Event Producer und Event Consumer gibt es spezielle Broker-Systeme wie beispielsweise Apache Kafka. Kafka zeichnet sich dadurch aus, dass die Datenströme, die in einer EDA anfallen, nahezu in Echtzeit verarbeitet werden können. Das ist beispielsweise wichtig, wenn der Online-Shop seinen Kunden bereits wenige Sekunden nach Aufgeben der Bestellung eine Bestätigung und eine gültige Rechnung zuschicken möchte.
Zwei Typen von Ereignissen
Die Beschreibung und Kategorisierung verschiedener Arten von Ereignissen kann sehr unterschiedlich ausfallen. Grundsätzlich gibt es jedoch in der Event-Driven Architecture zwei Hauptarten von Ereignissen.
Benachrichtigungsereignisse (Notification Events)
Diese Ereignisse informieren den Empfänger nur über eine Änderung, ohne detaillierte Daten zu liefern. Der Consumer weiß dann, wie der Zustand eines Objekts im System vorher war und wie er jetzt ist.
Im Beispiel des Online-Shops könnte der Kunde nachträglich der Nutzung seiner Daten für Marketingzwecke widersprechen. Diese Statusänderung des Kunden im System von „An Werbung interessiert“ zu „Keine Werbung zuschicken“ ist ein Benachrichtigungsereignis, das für das Marketingsystem wichtig ist. Der Kunde wird dann – möglichst automatisiert – aus dem E-Mail-Verteiler für Werbung gelöscht.
Neben der Information über die Änderung des Kundenstatus benötigt das Marketingsystem keine weiteren Informationen.
Dateneignisse (Data Events)
Diese Ereignisse enthalten alle relevanten Daten eines Geschäftsobjekts. Es handelt sich um deutlich größere und komplexere Änderungen im System als im Fall der Benachrichtigungsereignisse.
Im Beispiel wären das die Anzahl der bestellten Produkte und die Art des Versands (Standard oder Express) für das Lagersystem, die Art der Zahlung (PayPal oder Kreditkarte) für die Buchhaltung und Informationen über Werbemaßnahmen (Einsatz eines Rabattcodes, Anmeldung für den Newsletter) für das Marketingsystem.
Vorteile der Event-Driven Architecture
Im Vergleich zur synchronen Kommunikation bietet die Event-Driven Architecture einige Vorteile.
Skalierbarkeit
Der wichtigste Vorteil der EDA ist ihre Skalierbarkeit. Im oben beschriebenen Beispiel bestellt ein einzelner Kunde ein einzelnes Produkt. In der Realität muss ein Online-Shop jedoch die Bestellungen von mehreren hundert Kunden, die jeweils mehrere Produkte bestellen, verarbeiten können.
Läuft die Kommunikation synchron ab, muss das Bestell-System für jede Bestellung einzeln einen Kommunikationsprozess mit allen beteiligten Systemen beginnen. In einer Event-Driven Architecture erstellt das Bestell-System für jede Bestellung ein eigenes Ereignis. Die Verteilung durch den Broker ermöglicht dann die effiziente Bearbeitung der Ereignisse durch alle beteiligten Systeme.
So können beispielsweise die Zahlungen und die Rechnungsstellung für 100 Bestellungen schnell und automatisiert innerhalb von 10 Minuten ablaufen, während die Mitarbeiter im Lager die Produkte eines nach dem anderen verpacken und verschicken. Durch die Abkopplung des Bestell-Systems von den übrigen Systemen ist dieses Ungleichgewicht im gesamten System kein Problem.
Fehlertoleranz
Durch die Entkopplung der einzelnen Komponenten voneinander, ist das gesamte System weniger anfällig für Fehler. Wenn beispielsweise das Lagersystem vorübergehend ausfällt, bleibt der Rest des Systems weiterhin funktionstüchtig. Das Ereignis kann später erneut verarbeitet werden, ohne dass der gesamte Bestellprozess gestoppt wird. Die Zahlung ist dann bereits abgewickelt und der Kunde in die Marketing-Datenbank eingepflegt. Das Problem begrenzt sich dann auf eine Verzögerung im Versand der Bestellung, anstatt einer vollständigen Blockade im System.
Lose Kopplung
Da die Systeme nur Ereignisse empfangen und nicht direkt miteinander kommunizieren, sind sie locker gekoppelt. Änderungen an einem System (z. B. im Zahlungsmodul) erfordern keine Änderungen an anderen Systemen. Außerdem ist das Hinzufügen neuer Event-Consumer, beispielsweise in Form eines Controlling-Systems, das alle Bestellung verarbeitet und auswertet, recht unkompliziert möglich.
Bessere Ressourcennutzung
Da jedes System auf Ereignisse reagiert, ohne aktiv auf Anfragen warten zu müssen, können Ressourcen effizienter genutzt werden. Jedes System wird nur dann aktiv, wenn ein relevantes Ereignis eintritt. So müssen die einzelnen Komponenten nicht ständig Anfragen an das Bestell-System stellen, ob es eine neue Bestellung gibt.
Nachteile von Event-Driven Architecture
Trotz der zahlreichen Vorteile birgt die Event-Driven Architecture auch einige Schwierigkeiten und Herausforderungen.
Komplexität
Durch den Event Broker, der die asynchrone Kommunikation ermöglicht, ist die asynchrone Kommunikation in einer Event-Driven Architecture komplexer als ein System, das auf synchrone Kommunikation aufbaut. Diese zusätzliche Komplexität kann die Wartung des Systems aufwendiger machen und die Fehlersuche erschweren.
Inkonsistente Daten
Da in einer EDA die einzelnen Consumer unabhängig voneinander auf ein Ereignis reagieren, kann es zu Inkonsistenzen der Daten im System kommen. Beispielsweise kann es vorkommen, dass der Kunde eine Bestellung aufgibt und seine Zahlungsdetails eingibt, das Konto jedoch nicht gedeckt ist. Die verschiedenen Systeme reagieren nun auf das Ereignis der Bestellung. Das Lager-System reagiert sehr zügig, die Bestellung wird verschickt und der Broker erhält eine Rückmeldung über den erfolgreichen Versand. Gleichzeitig erhält er eine Rückmeldung vom Buchhaltungssystem, dass die Zahlung nicht eingegangen ist.
In einem System mit synchroner Kommunikation hätte das Bestell-System streng die Reihenfolge eingehalten und dem Lagersystem erst mitgeteilt, dass die Bestellung verschickt werden darf, wenn das Geld eingetroffen ist. Dieser Vorgang würde länger dauern, wäre allerdings auch etwas sicherer. Unternehmen, die auf eine EDA setzen, müssen also darauf achten, dass die Daten nicht zu inkonsistent werden, um Fehler im System zu vermeiden.
Event-Driven Architecture in SAP
Um Event-Driven Architecture in SAP umzusetzen, gibt es zwei Möglichkeiten.
SAP Event Mesh
SAP Event Mesh ist ein Cloud-Service, der es Anwendungen ermöglicht, mithilfe eines oder mehrerer Event-Broker in Echtzeit miteinander zu kommunizieren. Die Events können dabei sowohl von SAP- als auch von Nicht-SAP-Systemen produziert werden.
Als Plattformen für die Verteilung der Events können beispielsweise die SAP Extension Suite oder die SAP Integration Suite genutzt werden. Mit 1 MB ist die Größe der Nachrichten, die über Event Mesh verschickt werden können jedoch vergleichsweise gering.
Betrieb, Wartung und Entwicklung für Ihre SAP Integration Suite
Steigern Sie Ihre Effizienz mit unserem Full-Service-Angebot für Ihre SAP Integration Suite. Wir unterstützen Sie von Anfang bis Ende.
SAP Integration Suite, advanced event mesh
Die SAP Integration Suite, advanced event mesh ist ebenfalls ein Cloud-Service, der Anwendungen die Echtzeit-Kommunikation in Event-Driven Architectures ermöglicht.
Dabei ist dieses Tool jedoch umfangreicher als das Event Mesh. So können Nutzer nicht nur über mehrere Broker Events verteilen, sondern die Events auch verwalten. Außerdem ist eine Anbindung an on-premises-Systeme möglich. Die Größe der Nachrichten ist mit 30 MB ebenfalls deutlich größer als bei Event Mesh.
Fazit
Event-Driven Architecture ist ein Muster für Software-Architekturen, bei dem Ereignisse als zentrales Kommunikationsmittel zwischen Anwendungen dienen und asynchrone Kommunikation ermöglichen. Im Gegensatz zur synchronen Kommunikation, bei der Systeme sich gegenseitig Nachrichten schicken und auf die Antwort warten, reagieren Anwendungen in einer EDA auf ein Ereignis. Das Ereignis wird von einem Event Producer ausgelöst und informiert die Event Consumers über eine Änderung im System. Verteilt werden die Ereignisse durch einen Ereignis-Broker.
Ereignisse können entweder Benachrichtigungsereignisse, die nur eine Änderung anzeigen, oder Dateneignisse, die vollständige Daten enthalten, sein. EDA bietet Vorteile wie Skalierbarkeit, Fehlertoleranz und eine bessere Ressourcennutzung, da Systeme nur auf relevante Ereignisse reagieren. Allerdings kann EDA auch zu Komplexität und inkonsistenten Daten führen, da die Systeme unabhängig voneinander agieren. In SAP lässt sich EDA durch SAP Event Mesh oder die erweiterte SAP Integration Suite umsetzen, die Echtzeitkommunikation und Event-Management ermöglichen.
Websession: Event-Driven Architecture
Möchten Sie sich weiter über das Konzept der Event-Driven Architecture informieren? Vereinbaren Sie gerne eine Websession mit unseren Experten und wir beantworten Ihre Fragen!
FAQ
Was ist der Hauptvorteil von Event-Driven Architecture (EDA)?
EDA ermöglicht eine asynchrone Kommunikation zwischen Systemen, was zu einer höheren Flexibilität, Skalierbarkeit und Fehlertoleranz führt. Anwendungen können auf Ereignisse in Echtzeit reagieren, ohne aufeinander warten zu müssen, was die Systemleistung optimiert.
Wie funktioniert der Ereignis-Broker in einer Event-Driven Architecture?
Der Ereignis-Broker fungiert als Middleware, die Ereignisse von einem Event Producer (z.B. Bestellsystem) an mehrere Event Consumers (z.B. Lager-, Buchhaltungs- und Marketingsysteme) weiterleitet. Er sorgt für die zuverlässige Kommunikation und koordiniert die Rückmeldungen der Consumer.
Welche Arten von Ereignissen gibt es in einer Event-Driven Architecture?
Es gibt zwei Hauptarten von Ereignissen:
- Benachrichtigungsereignisse, die nur eine Änderung anzeigen (z.B. eine Statusaktualisierung)
- Dateneignisse, die detaillierte Informationen über Geschäftsobjekte enthalten (z.B. Bestelldaten)
Wie setzt SAP Event-Driven Architecture um?
SAP setzt EDA mit Lösungen wie SAP Event Mesh und SAP Integration Suite um, die es ermöglichen, Ereignisse in Echtzeit zu verwalten, zu verteilen und auf verschiedene SAP- und Nicht-SAP-Systeme zu übertragen, wodurch die Kommunikation und Integration zwischen verschiedenen Systemen effizient gestaltet wird.
Wer kann mir beim Thema Event-Driven Architecture helfen?
Wenn Sie Unterstützung zum Thema Event-Driven Architecture benötigen, stehen Ihnen die Experten von Erlebe Software, dem auf dieses Thema spezialisierten Team der mindsquare AG, zur Verfügung. Unsere Berater helfen Ihnen, Ihre Fragen zu beantworten, das passende Tool für Ihr Unternehmen zu finden und es optimal einzusetzen. Vereinbaren Sie gern ein unverbindliches Beratungsgespräch, um Ihre spezifischen Anforderungen zu besprechen.
