Ereignisgesteuerte Architektur
Stand 2026-09-03
Ereignisgesteuerte Architektur ist die Entscheidung, nicht mehr auf den nächtlichen Batch zu warten, sondern in dem Moment zu reagieren, in dem S/4HANA seinen Zustand ändert — und ersetzt ein Ladefenster von 02:00 bis 06:00 Uhr durch ereignisnative Replikation in Datasphere im Sekundenbereich. Die eigentliche Entwurfsentscheidung, die ein Berater verteidigen muss, lautet nicht „Kafka oder nicht“, sondern durchgängige At-least-once-Zustellung, wodurch idempotente Upserts auf Basis natürlicher Schlüssel von Tag eins an nicht verhandelbar sind. Praktiker, die diese Pipeline von Anfang bis Ende entwerfen und betreiben können — vom S/4HANA Business Event Handling über den Event-Mesh bis zu einem überwachten Datasphere-Replication- oder Data-Flow — sitzen in DACH-Einstellungsgesprächen auf Senior-Architekten-/Principal-Consultant-Niveau, weil der Pool, der beide Seiten der Pipeline abdeckt — ABAP und Datasphere —, klein bleibt.
Was Sie lernen
- Eine vollständige ereignisgesteuerte Datenpipeline von S/4HANA ABAP Business Event Handling über SAP Advanced Event Mesh oder Kafka bis zu einem Datasphere Replication Flow oder Data Flow entwerfen, mit expliziter Behandlung von Schema-Evolution und Konsumenten-Idempotenz
- Die Kompromisse zwischen event-nativer Replikation, logbasiertem CDC über SLT und Micro-Batch-Planung für ein gegebenes Analytics-Aktualitäts-SLA bewerten und das architektonisch passende Muster für eine BDC-ausgerichtete Landschaft auswählen
- Beobachtbare EDA-Pipelines implementieren, indem Consumer-Lag-Monitoring, Dead-Letter-Queue-Alarmierung und End-to-End-Latenz-P99-Messung über SAP Advanced Event Mesh und Datasphere hinweg entworfen werden
- Szenarien mit verspätet eintreffenden Ereignissen in Datasphere-Analysemodellen und SAC-Stories mithilfe eines Korrekturschicht-Musters lösen, ohne die primäre Faktpartition zu stören oder eine vollständige historische Neuladung zu erzwingen
Warum ereignisgesteuerte Architektur für SAP-Analytics alles verändert
SAP-Analytics-Plattformen arbeiteten historisch nach einem Pull-Modell: Ein BW/4HANA-Extraktionsjob startet um 02:00 Uhr, lädt ein Delta aus S/4HANA über ABAP-CDS-Views, transformiert es durch eine ADSO-Kette und liefert bis 06:00 Uhr einen Report. Für die meisten operativen Reportings ist dieses Batch-Fenster akzeptabel. Aber wenn ein Treasury-Desk eine untertägige FX-Exposure benötigt, wenn ein Supply-Chain-Team innerhalb von Minuten auf ein Logistikereignis reagieren muss, oder wenn ein Joule-gestützter Assistent Fragen auf Basis der heutigen Daten beantworten muss, ist der Batch-Rhythmus konstruktionsbedingt nicht mehr tragfähig.
Ereignisgesteuerte Architektur (Event-Driven Architecture, EDA) kehrt das Modell um: Statt dass Konsumenten Daten nach einem Zeitplan abholen, senden Produzenten Ereignisse in dem Moment, in dem sich der Zustand ändert. Für SAP-Analytics-Berater ist der Wechsel vom Batch-ETL-Denken zum ereignisorientierten Design eine der folgenreichsten Architekturentscheidungen dieses Jahrzehnts, unmittelbar verknüpft mit der SAP-Business-Data-Cloud-Strategie (BDC) und den Echtzeit-Replikationsfähigkeiten von Datasphere.
Voraussetzungen
- Fortgeschrittene praktische Erfahrung mit SAP-Analytics-Projekten
- Zunächst die Kernkonzepte wiederholen: C035, C023, C087
Lernergebnisse
- Ein realistisches Szenario durcharbeiten: Ein EMEA-Logistikkonzern ersetzt seine 02:00-Uhr-Batch-Ladung von Sendungs- und FX-Exposure-Daten durch einen ereignisgesteuerten Feed nach Datasphere.
- Das Anti-Pattern erkennen und vermeiden: Einen alle 5 Minuten geplanten Data Flow als „ereignisgesteuert“ bezeichnen — Es handelt sich um Micro-Batch mit zusätzlichen operativen Kosten.
- Die zentrale Entscheidung des Moduls anwenden: Event-native Replikation vs. Bridge-and-Batch-CDC — Event-nativ wählen.
- Die Beherrschung anhand des KPI verfolgen: Consumer Lag (pro Topic-Partition).
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.