Ereignisdaten – Event Data – sind Datensätze, die ein einzelnes, zeitpunktgebundenes Vorkommnis beschreiben: Was ist passiert? Wann? In welchem Kontext? Im Unterschied zu Stammdaten (die einen stabilen Zustand beschreiben) oder Bewegungsdaten (die Transaktionen erfassen) sind Ereignisdaten unmittelbar, atomar und unveränderlich – ein Ereignis ist passiert, dieser Fakt ändert sich nicht mehr.
Ereignisdaten sind das Fundament ereignisgesteuerter Automatisierungen: Jeder Trigger in einer Automationsplattform reagiert letztlich auf ein Ereignis – eine eingehende E-Mail, ein neuer Datenbankeintrag, ein Webhook, eine Sensor-Messung. Je präziser und vollständiger Ereignisdaten strukturiert sind, desto zuverlässiger kann darauf reagiert werden.
Ereignistypen in der Unternehmensautomation
Business-Ereignis Auftrag eingegangen, Zahlung erhalten, Kunde registriert: Geschäftlich bedeutsame Ereignisse, die Prozesse anstoßen – das Brot-und-Butter der Prozessautomatisierung
System-Ereignis Deployment abgeschlossen, Fehler aufgetreten, Schwellenwert überschritten: Technische Ereignisse aus Infrastruktur und Applikationen – Basis für Monitoring und Alerting
IoT-Ereignis Temperatur überschritten, Bewegung erkannt, Maschine gestartet: Physische Welt trifft digitale Verarbeitung – hohe Frequenz, oft Echtzeit-Anforderungen
Nutzer-Ereignis Formular ausgefüllt, Button geklickt, Seite verlassen: Interaktionsdaten aus Web- und App-Oberflächen – Grundlage für Conversion-Optimierung und Personalisierung
Event-Sourcing: Ereignisdaten als Systemzustand
Event-Sourcing ist ein Architekturmuster, bei dem der Zustand eines Systems nicht als aktueller Datenbankwert gespeichert wird, sondern als lückenlose Sequenz aller Ereignisse, die zu diesem Zustand geführt haben. Der aktuelle Kontostand ist nicht „1.240 Euro“, sondern die Summe aller Ein- und Auszahlungs-Ereignisse. Vorteile: vollständige Audit-History, Zustand zu jedem Zeitpunkt rekonstruierbar, einfache Integration neuer Systeme durch Event-Replay. Nachteile: Komplexere Abfragen, Speicherbedarf wächst über Zeit.
Praxisbeispiel
Ein Automationsdienstleister strukturiert alle Ereignisdaten nach einem einheitlichen Schema: Ereignis-ID (UUID), Ereignistyp (z. B. „invoice.received“), Zeitstempel (ISO 8601, UTC), Quelle (System-ID), Payload (Ereignis-spezifische Daten als JSON), Korrelations-ID (verknüpft zusammengehörende Ereignisse). Vorteile dieser Standardisierung: Alle Ereignisse fließen in denselben Kafka-Topic-Namespace. Monitoring-Tools können alle Ereignistypen einheitlich auswerten. Neue Workflows können beliebige bestehende Ereignistypen als Trigger nutzen, ohne spezifische Konvertierung. Debugging: Über die Korrelations-ID lässt sich der vollständige Verarbeitungsweg einer Rechnung durch alle Systeme nachvollziehen – in 3 Sekunden statt manueller Spurensuche über 4 Systeme.
