Die Digitalisierung schreitet in nahezu allen Branchen voran. Im Zeitalter von Big-Data steigt die Menge an zu analysierenden Daten exponentiell an. Mit dem IoT werden mehr und mehr Daten produziert, die in heterogenen Systemlandschaften von verschiedenen Anwendungen interpretiert werden müssen. Dabei stoßen Auswertungen und Analysen der enormen Datenmengen im Rahmen von Reports an ihre Grenzen.
Diese Entwicklung rückt die sogenannte „Event-Driven-Architecture“ in den Vordergrund, auf der auch die Lösung von Apache Kafka basiert. Ziel ist nicht das periodische Abgreifen und Auswerten großer Datenmengen, sondern die echtzeitnahe Verarbeitung von auftretenden Events. Diese Events können sowohl Ereignisse der echten Welt sein (IoT), aber auch transaktionale Vorgänge aus SAP-Systemen darstellen.
Zentrale Datenquelle
Der bisher übliche Aufbau von Schnittstellen, die spezifisch für einzelne Applikationen, Systeme oder Werke entwickelt, auf die individuellen Anforderungen zugeschnitten und damit einzigartig waren, führen in der Realität zu einer Vielzahl von Insellösungen, die sich grundsätzlich ähneln, sich jedoch in Bezug auf Datenformate, Selektions- oder Aggregationslogik unterscheiden. Apache Kafka bietet eine Plattform, um alle Events unterschiedlicher Systeme zu vereinen und einen kontinuierlichen Datenfluss von Events in Echtzeit abzubilden und zu historisieren.
Durch die Entkopplung der Systeme wird der Testaufwand minimiert und die Ausfallsicherheit maximiert. Daten können dabei konsumiert, aggregiert, gruppiert und mit sonstigen Logiken versehen und anschließend in angepasster Form wiederum bereitgestellt werden.
Funktionsweise von Kafka
Events stellen Datensätze von etwas gerade Geschehenem dar und können auch als Nachrichten bezeichnet werden. Diese Nachrichten werden von dem sogenannten „Producer“ an ein oder mehrere KAFKA-Topics geschickt und dort persistiert. Die Topics stellen zusammenhängende Events dar und können frei definiert werden. Im Kontext SAP können beispielsweise alle Warenbewegungen aus verschiedenen SAP-Systemen in einem Topic hinterlegt werden. Ein Event besteht immer aus einem Timestamp, einem Schlüssel (Key) und einem Wert, der unlimitiert ist und ganze Tabellen beinhalten kann. Die Daten werden durch Broker verwaltet und auf verschiedenen Partitionen gesichert. Durch das Spiegeln von Daten auf verschiedenen Brokern wird das Topic durch Ausfälle abgesichert.
Als Abnehmer der Daten stehen die sogenannten „Consumer“. Diese sind völlig von der „Producer“-Seite entkoppelt und können die Events asynchron verarbeiten. Mehrere Consumer können dabei auch auf unterschiedlichen Verarbeitungsständen sein, wobei jeder Consumer seinen eigenen Stand kennt. Ein Consumer kann die Daten von einem oder mehreren Topics lesen, interpretieren und weiterverarbeiten. Verarbeitungslogiken können sowohl auf Producer- als auch auf Consumer-Seite definiert werden.
Auf Basis verschiedener Kafka-Topics können auch neue Topics geschaffen werden, welche den Mehrwert für das Business erhöhen, indem das Event-Handling genauer abgestimmt werden kann. Beispielsweise ist es möglich aus dem Topic für Lagerbestände und dem Topic der Sekundärbedarfe die Kritikalität einer Änderung des Liefertermins eines Rohstoffs zu ermitteln, zu verarbeiten und die Information an den zuständigen Materialsteuerer weiterzuleiten.
Die Haltedauer der Daten in einem Topic wird durch die Retention Policy festgelegt. Diese bestimmt, wie lange die Daten vorgehalten und von Consumern abgefragt werden können. Bei sogenannten Compacted-Topics sind die Daten unbegrenzt verfügbar, wobei es hier je Key nur einen Eintrag geben kann. Dieses Vorhalten der Daten ist vergleichbar mit der Datenhaltung auf einer SAP-Datenbank.
Integration in SAP ERP
Für Echtzeit-Messaging, Datenintegration und Datenverarbeitung in großem Maßstab besteht für SAP ERP (ECC und S/4HANA), aber auch für die meisten anderen Produkte aus dem umfangreichen SAP-Portfolio, ein enormes Potential. Um einen modernen sowie skalierbaren Ansatz für die Integration von Apache Kafka und SAP zu implementieren, gibt es unterschiedliche Optionen. Möglichkeiten sind neben RFC, BAPI, IDOC, SOAP und OData auch KAFKA Connect. Es können beispielsweise auch RFC-Bausteine implementiert werden, um im Rahmen der Verbuchung Daten an Kafka zu übermitteln.
Confluent bietet hier für SAP vordefinierte Lösungen an, mit denen einfach auf SAP-Datenbanken zugegriffen werden kann. Gleichzeitig bietet das Tool Kafka Connect Möglichkeiten, Events in andere Datenbanken zu speichern, welche später für Auswertung oder Drittsysteme genutzt werden können und dadurch nicht mehr das SAP-System belasten müssen.
Events können ebenfalls von anderen Topics konsumiert werden, um die relevanten Daten aufzuschlüsseln und zu bewerten, während die Ereignisse auftreten. Durch die Vereinigung aller Systeme und Datenquellen in einer gemeinsamen Plattform können unterschiedlichste Daten zu völlig neuen Strukturen mit neuen Mehrwerten transformiert und wiederum als Topic bereitgestellt werden.
Vorteile von eventbasierten Business Workflows
Auswirkungen eines nicht eventbasierten Konzepts:
- synchrones Warten, bis alle Arbeiten abgeschlossen sind, bevor die Antwort gesendet wird
- Abhängigkeiten der Systeme durch Updates oder Releases
- Geringe Transparenz der Abhängigkeiten
- langsamer und komplexer Entwicklungsprozess aufgrund von Abhängigkeiten
- höherer Testaufwand aufgrund von Organisierung und Orchestrierung der Tests
- redundante Datenübertragung und redundante Anbindung an einen Data Lake / BW
- viele Anfragen können das Quellsystem überlasten
Auswirkungen des eventbasierten Konzepts:
- viel früher im Prozess auf den Nutzer reagieren
- voneinander entkoppelte Systeme (in technischer Hinsicht)
- systemspezifische Vorteile der direkten Kommunikation gehen verloren (z. B. SAP-RFC-Aufrufe)
- Daten müssen möglicherweise mehr als einmal konvertiert werden
Vorteile für das Quellsystem und die Zielarchitektur
Eine eventbasierte Datenkommunikation bringt deutliche Vorteile sowohl für das Quellsystem als auch für die Zielarchitektur:
Die Programmlogik des Ausgangssystems wird erheblich vereinfacht und die Abhängigkeiten von nachgelagerten Systemen werden beseitigt. Die Änderungen im Quellsystem werden seltener erforderlich, und nur dann, wenn eigene kohärente Funktionalität betroffen ist. Als Folge werden das Testen und Deployment deutlich einfacher.
Die Zielarchitektur gewinnt größere Freiheit sich zu verändern, wenn kein anderes System von ihr abhängig ist. Die Transparenz von Auswirkungen auf das System und die Daten ist erheblich höher und die Autonomie sorgt für Agilität und Flexibilität.
Die Experten von CONSILIO liefern das notwendige Know-how für die Einführung von Kafka, unterstützen Sie dabei, den Programmieraufwand zu minimieren, und erstellen zusammen mit den Usern Use-Cases für die Nutzung von Kafka.
In der Event-driven-Architecture wird durch die Entkopplung der Systeme der Testaufwand minimiert und die Ausfallsicherheit maximiert. Daten können dabei konsumiert, aggregiert, gruppiert und mit sonstigen Logiken versehen und anschließend in angepasster Form wiederum bereitgestellt werden.
