So entscheiden Sie, welche Daten ein Integrationsereignis enthalten soll

Die Gestaltung eines Integrationsereignisses wirkt wie eine technische Entscheidung, bestimmt jedoch die Autonomie der Teams, die operative Resilienz und die Qualität der Informationen, die jeder Prozess erhält. Wenn ein CRM, ein ERP, ein E-Commerce-System und eine Kundenservice-Plattform Ereignisse austauschen, stellt sich immer wieder dieselbe Frage: Soll die Nachricht alle erforderlichen Daten enthalten oder nur eine Referenz, über die sie im Quellsystem abgefragt werden können?

Eine allgemeingültige Antwort gibt es nicht. Ein zu knappes Ereignis erzwingt verkettete Abfragen und macht das Quellsystem zu einer dauerhaften Abhängigkeit. Ein zu umfangreiches Ereignis dupliziert Informationen, kann unnötige personenbezogene Daten verbreiten und möglicherweise bereits veraltete Werte enthalten. Wirksam ist daher eine Entscheidung auf Feldebene, basierend auf der tatsächlichen Nutzung durch den Verbraucher und den Betriebsbedingungen.

Drei Möglichkeiten, Kontext zu übertragen

Ein Ereignis kann Kontext auf drei Arten bereitstellen. Jedes Modell löst andere Probleme und bringt Kosten mit sich, die ausdrücklich berücksichtigt werden müssen.

Ereignis mit vollständigen Daten

Die Nachricht enthält die Informationen, die der Verbraucher zur Ausführung seiner Aktion benötigt. Ein Ereignis über eine bestätigte Bestellung kann beispielsweise Bestellpositionen, Lieferadresse, Vertriebskanal und eine Momentaufnahme der bestätigten Beträge enthalten.

• Geeignet ist es, wenn der Verbraucher sofort handeln muss, wenn der übermittelte Wert als historischer Nachweis erhalten bleiben soll oder wenn die Verfügbarkeit des Quellsystems nicht garantiert ist.
• Es reduziert nachgelagerte Aufrufe, Latenz und Laufzeitkopplung.
• Es erfordert eine klare Definition dessen, was die Information darstellt: in der Regel eine Momentaufnahme zum Zeitpunkt des Ereignisses, nicht den aktuellen Live-Zustand eines Datensatzes.
• Es erhöht die Nachrichtengröße, die Komplexität des Vertrags und die Angriffsfläche für Datenoffenlegung.

Ereignis mit Kennung und späterer Abfrage

Die Nachricht enthält eine Kennung, den Ereignistyp und minimale Metadaten; der Verbraucher fragt anschließend eine API oder eine autorisierte Replik ab. Dies eignet sich, wenn der aktuelle Wert und nicht eine historische Aufnahme benötigt wird.

• Geeignet ist es für volatile Attribute, umfangreiche Kataloge oder Informationen, die der Verbraucher nur in Ausnahmefällen benötigt.
• Es vermeidet die Verteilung von Kopien häufig wechselnder Daten.
• Es schafft Abhängigkeiten von Verfügbarkeit, Berechtigungen, Nutzungsgrenzen und Latenz des Quellsystems.
• Es kann Kaskadenabfragen erzeugen: Ein Dienst fragt die Bestellung ab, dann den Kunden, danach das Produkt und schließlich den Bestand. Solche Ketten sind oft fragil und schwer zu diagnostizieren.

Hybrides Modell

In den meisten ausgereiften Integrationen ist ein hybrider Ansatz am wirksamsten: Das Ereignis enthält einen eigenständigen Kern zur Ausführung des Ablaufs sowie Referenzen für eine Anreicherung bei Bedarf. Eine Bestellung kann Kennung, Datum, bestätigten Status, Beträge, Artikel und logistische Zieladresse enthalten, aber nur die Kundenkennung bereitstellen, um bei Bedarf aktuelle Kontaktpräferenzen abzufragen.

Die Regel lautet nicht „wenig senden“ oder „alles senden“: Übermitteln Sie, was erforderlich ist, um die ausgelöste Entscheidung zuverlässig abzuschließen, und verwenden Sie Referenzen für Daten, die aktuell sein müssen, kostspielig sind oder nicht für alle Empfänger autorisiert werden dürfen.

Kriterien für die Entscheidung über jedes Feld

Die richtige Entscheidungseinheit ist nicht das gesamte Ereignis, sondern jedes einzelne Attribut. Ein Ereignis kann unveränderliche, volatile, sensible und abgeleitete Daten enthalten, die gegensätzliche Behandlungen erfordern.

• Unmittelbarkeit: Muss der Verbraucher handeln, bevor er eine API abfragen kann, muss der Wert mitgeliefert werden. Die Logistik sollte nicht auf eine zusätzliche Abfrage warten müssen, um die validierte Versandadresse zu kennen.
• Aktualität: Erfordert die Entscheidung den zuletzt verfügbaren Wert, ist eine Referenz vorzuziehen. Kommunikationspräferenzen oder der aktuelle Status eines Kontos können sich nach der Bestellung ändern.
• Historischer Wert: Soll nachvollziehbar bleiben, was beim Eintritt eines Sachverhalts bekannt war, fügen Sie eine datierte Momentaufnahme ein. Akzeptierte Preise und angewandte Steuern dürfen nicht anhand des aktuellen Katalogs neu interpretiert werden.
• Umfang und Häufigkeit: Bilder, lange Beschreibungen, Dokumente oder große Strukturen gehören selten in die Hauptnachricht. Senden Sie eine stabile Referenz, eine Version und gegebenenfalls eine Zusammenfassung.
• Verfügbarkeit: Würde ein Ausfall des Quellsystems einen kritischen Prozess blockieren, muss das Ereignis das notwendige Minimum für eine sichere Degradierung liefern.
• Berechtigungen: Nicht alle Verbraucher, die eine Kennung kennen, dürfen personenbezogene, finanzielle oder interne Daten erhalten. Das Ereignis darf das Berechtigungsmodell der Systeme nicht umgehen.
• Nachvollziehbarkeit: Jeder entscheidungsrelevante Wert sollte angeben, aus welcher Version oder welchem Zeitpunkt er stammt. Ein Feld ohne zeitlichen Kontext kann zu Fehlentscheidungen führen.

Klassifizieren Sie die Daten zusätzlich. Unveränderliche Daten wie eine Bestellkennung oder ein Erstellungsdatum sind klare Kandidaten für die Übermittlung. Volatile Daten wie die Lagerverfügbarkeit erfordern meist eine Abfrage oder ein spezielles Aktualisierungsereignis. Sensible Daten müssen minimiert, nach Zielgruppe eingeschränkt und gemäß den geltenden Richtlinien geschützt werden. Abgeleitete Daten wie eine Segmentierung oder Bewertung sollten ihre Regel, Version oder Gültigkeit angeben, damit sie nicht als dauerhafte Tatsachen erscheinen.

Praktische Matrix und Entwurfsmuster

Bevor ein Feld zum Vertrag hinzugefügt wird, können Fachbereich, Produktteam und Technik es mit diesen Fragen bewerten. Sind mehrere Antworten im ersten Teil positiv, sollte es wahrscheinlich enthalten sein; überwiegen die Fragen im zweiten Teil, ist eine Referenz sinnvoller.

1. Kann der Verbraucher seine Aktion ohne diesen Wert nicht abschließen?
2. Muss die exakte, zum Ereigniszeitpunkt gültige Version erhalten bleiben?
3. Könnte eine spätere Abfrage fehlschlagen oder zu spät eintreffen?
4. Ist der Wert klein und innerhalb des Prozesslebenszyklus stabil?
5. Ändert er sich häufig oder wird er nur in besonderen Fällen benötigt?
6. Enthält er sensible Daten, die der Verbraucher nicht ausdrücklich benötigt?
7. Gibt es eine autorisierte und verfügbare Quelle für eine spätere Abfrage?
8. Kann der Verbraucher eine verzögerte Antwort, einen Cache oder eine manuelle Prüfung tolerieren?

Aus dieser Bewertung ergeben sich drei nützliche Muster:

• Nachvollziehbare Momentaufnahme: Übermitteln Sie den Wert und ergänzen Sie occurred_at, eine Ereigniskennung, die Schemaversion und gegebenenfalls die Ressourcenversion. Das eignet sich für Beträge, akzeptierte Bedingungen und operative Zieladressen.
• Anreicherbare Referenz: Senden Sie eine stabile Kennung, den Ressourcentyp und, falls vorhanden, eine Version. Der Verbraucher fragt nur bei Bedarf ab und protokolliert die verwendete Antwort.
• Minimale Daten mit kontrolliertem Cache: Fügen Sie eine minimale Auswahl ein und erlauben Sie die Anreicherung aus einer Lesekopie mit definierter Gültigkeitsdauer. Dies ist für Kataloge oder nicht sensible Profile nützlich, bei denen eine geringe Verzögerung akzeptabel ist.

Ein einfacher Vertrag kann den Unterschied zwischen einem Sachverhalt und abfragbaren Informationen klar ausdrücken:

{
  "event_id": "evt_123",
  "event_type": "order.confirmed",
  "occurred_at": "2025-03-08T10:30:00Z",
  "order": {
    "id": "ord_456",
    "total_confirmed": 125.00,
    "delivery_address_snapshot": { "country": "ES" }
  },
  "customer_ref": { "id": "cus_789" }
}

Die enthaltene Adresse ist eine operative Momentaufnahme; die Kundenkennung ermöglicht die autorisierte Abfrage aktueller Attribute. Daraus darf nicht abgeleitet werden, dass alle Kundenfelder zum Bestellzeitpunkt gültig oder genehmigt waren.

Verfügbarkeit, Ausfälle und operative Degradierung

Wer sich für eine spätere Abfrage entscheidet, muss festlegen, was bei deren Scheitern geschieht. Ein automatischer Wiederholungsversuch allein genügt nicht: Eine anhaltende Nichtverfügbarkeit kann Duplikate erzeugen, die Quell-API überlasten und ganze Warteschlangen blockieren.

Definieren Sie das Degradierungsverhalten vor der Veröffentlichung des Ereignisses. Vereinbaren Sie für jeden Verbraucher, ob er mit Minimaldaten verarbeiten, später erneut versuchen, eine Ausnahme-Warteschlange nutzen oder eine manuelle Intervention verlangen kann. Der Kundenservice kann einen Fall mit unvollständigen Informationen eröffnen; die Logistik muss den Versand möglicherweise zurückhalten, wenn eine überprüfbare Adresse fehlt.

• Verwenden Sie Ereigniskennungen und Idempotenz, damit eine Wiederholung nicht dieselbe Aktion zweimal ausführt.
• Trennen Sie temporäre Fehler von dauerhaften Fehlern wie einer nicht vorhandenen Referenz oder unzureichenden Berechtigungen.
• Vermeiden Sie synchronisierte und unbegrenzte Wiederholungsversuche, die einen Vorfall im Quellsystem verstärken.
• Überwachen Sie Warteschlangenverzögerungen, Anreicherungsfehler, das Alter der zuletzt abgefragten Daten und den Anteil degradierter Verarbeitung.
• Bewahren Sie für blockierte Entscheidungen einen Prüfpfad auf, der Grund und ursprüngliches Ereignis für Auditzwecke verfügbar macht.

Versionierung, Sicherheit und Vertragsgovernance

Ereignisverträge entwickeln sich weiter. Ein optionales Feld hinzuzufügen ist meist weniger riskant, als die Bedeutung eines bestehenden Feldes zu ändern, ein optionales Feld verpflichtend zu machen oder Informationen zu entfernen, deren Verfügbarkeit ein Verbraucher voraussetzt. Kompatibilität bedeutet nicht nur, dass eine Nachricht gelesen werden kann; auch ihre geschäftliche Bedeutung muss erhalten bleiben.

Bestimmen Sie für jedes Feld eine verantwortliche Person und dokumentieren Sie Ursprung, Klassifikation, Semantik, Format, Gültigkeit und autorisierte Verbraucher. Fügen Sie eine Schemaversion hinzu und behandeln Sie wesentliche semantische Änderungen als neue Versionen oder neue Ereignistypen. Verwenden Sie einen Namen nicht für eine andere Bedeutung wieder: Ein Feld namens status ohne Wertekatalog und zeitliche Definition ist eine häufige Ursache für unvereinbare Interpretationen.

Wenden Sie in der Sicherheit Datenminimierung an. Ein Ereignis, das über eine gemeinsame Infrastruktur verbreitet wird, kann mehr Verbraucher erreichen als zunächst vorgesehen. Nehmen Sie keine personenbezogenen Daten „vorsichtshalber“, keine Geheimnisse, Zugangsdaten oder Attribute ohne konkreten Zweck auf. Benötigt ein Prozess sensible Informationen, ziehen Sie einen eingeschränkten Kanal oder eine autorisierte Abfrage vor, statt sie in einem allgemeinen Ereignis zu verbreiten.

Beispiel: Bestellung für Logistik, Kundenservice und Kommunikation

Stellen Sie sich vor, eine bestätigte Bestellung löst drei Abläufe aus. Die Logistik benötigt Artikel, Mengen, die validierte Lieferadresse, Versandart und Bestätigungsdatum. Diese Daten sollten als Momentaufnahme übertragen werden, weil sie die Versandvorbereitung ermöglichen, selbst wenn das E-Commerce-System nicht verfügbar ist.

Der Kundenservice benötigt Bestellkennung, Status und Kundenreferenz. Er kann bei der Bearbeitung eines Vorfalls den aktuellen Kundenverlauf abfragen, sofern entsprechende Berechtigungen vorliegen. Transaktionale Kommunikation benötigt den Ereignistyp und eine autorisierte Referenz auf den Empfänger, muss aber nicht die gesamte Bestellung oder das vollständige Kundenprofil erhalten.

Diese Trennung reduziert die Offenlegung und verhindert, dass ein einzelnes Ereignis zu einer unbeabsichtigten Replik des CRM oder ERP wird. Sie klärt auch Verantwortlichkeiten: Das E-Commerce-System sendet den bestätigten Sachverhalt, die Logistik nutzt die Erfüllungs-Momentaufnahme und jeder Kanal fragt nur den aktuellen Kontext ab, der ihm zusteht.

Checkliste vor der Veröffentlichung

• Beschreibt das Ereignis einen eingetretenen Sachverhalt, oder versucht es, den vollständigen Zustand eines anderen Systems zu replizieren?
• Hat jedes Feld einen identifizierten Verbraucher, Zweck und Verantwortlichen?
• Ist klar, welche Felder Momentaufnahmen sind und welche als aktueller Zustand abgefragt werden müssen?
• Wurden sensible Daten minimiert und Zugriffsberechtigungen definiert?
• Funktioniert der Prozess weiter, wird er verschoben oder manuell eskaliert, wenn die Anreicherung fehlschlägt?
• Gibt es Ereigniskennung, Eintrittszeitpunkt, Idempotenz und Schemaversion?
• Können Verbraucher neue Felder ignorieren, ohne zu brechen?
• Gibt es Metriken und Warnungen für fehlgeschlagene Abfragen, Verzögerungen und unverarbeitete Nachrichten?

Die richtige Entscheidung macht ein Ereignis zu einem zuverlässigen Geschäftsvertrag statt zu einem beliebigen Datencontainer. Übermitteln Sie ausreichend Kontext, damit der Sachverhalt eigenständig Wert schaffen kann; fragen Sie ab, was aktuell sein muss, sensibel ist oder nicht zwingend erforderlich ist. So sinkt die Kopplung, ohne Nachvollziehbarkeit oder operative Kontinuität zu opfern.