Modul: Audit

Das Audit-Modul beantwortet eine Frage, die in Commerce- und Stammdatensystemen ständig gestellt wird: Was ist mit diesem Datensatz passiert – alles, von wem und wann? Es zeichnet Änderungen als vollständigen, schnellen und lesbaren Verlauf auf und macht ihn durchsuchbar. Intern trägt dieses Vorhaben den Namen Heartbeat.

Die Idee

Statt Änderungen erst zur Lesezeit aus der Datenbank zu rekonstruieren, entsteht der Audit-Eintrag zum Zeitpunkt der Änderung. Jede relevante Aktion – ein angelegter Benutzer, eine geänderte Adresse, ein vergebener Rabatt, eine neue Rolle – wird als Ereignis erfasst, mit dem Auslöser, dem genauen Zeitpunkt und dem, was sich geändert hat. Das Ergebnis ist ein chronologischer Aktivitätsstrom, der sich zu jedem Datensatz anzeigen lässt.

Dieser Ansatz löst die typischen Schwächen klassischer Änderungsverfolgung: Er ist vollständig (auch mehrstufig verknüpfte Änderungen erscheinen), schnell zu lesen (weil nichts zur Laufzeit zusammengerechnet werden muss) und wartbar (weil der Verlauf nicht unkontrolliert die operative Datenbank aufbläht).

Wie ein Eintrag entsteht

Der Weg einer Änderung in den Audit-Trail folgt einem klaren Ablauf:

1. Eine Änderung passiert – etwa eine Datenänderung in einem Modul oder ein fachliches Ereignis.
2. Es wird eine Audit-Nachricht mit den rohen Quelldaten auf den Nachrichtenbus veröffentlicht.
3. Das Audit-Modul nimmt die Nachricht entgegen und schlägt in seiner Konfiguration nach, wie mit diesem Ereignistyp zu verfahren ist.
4. Ist das Ereignis zu speichern, wird es unverändert in einen append-only-Verlauf geschrieben.
5. Ist es zu indexieren, durchläuft es die Index-Pipeline und wird nach Elasticsearch geschrieben – die Grundlage für die schnelle Abfrage.

Ereignisquellen

Das Modul kennt unterschiedliche Herkünfte von Ereignissen und behandelt sie einheitlich über ein klares Schlüsselschema <Namespace>.<Was>.<Aktion>:

• Datenänderungen an Entitäten (Anlegen, Ändern, Löschen) – automatisch erfasst, mit Alt/Neu-Vergleich.
• Business-Ereignisse der Fachmodule – aussagekräftige Vorgänge wie „Position ersetzt” oder „Rolle zugewiesen”.
• Projektspezifische Ereignisse aus aufsetzendem Code.

Je hochwertiger die Business-Ereignisse eines Moduls, desto sprechender wird der Verlauf: aus einem technischen „Datensatz geändert” wird ein verständliches „hat beim Auftrag Artikel A durch Artikel B ersetzt”.

Konfigurierbarer Katalog

Welche Ereignistypen gespeichert, indexiert und wie dargestellt werden, steuert ein Katalog. Pro Ereignistyp lassen sich Gruppe, Symbol, eine mehrsprachige Meldung sowie die Verarbeitung festlegen. So bleibt steuerbar, was im Verlauf erscheint und wie es lesbar aufbereitet wird – pflegbar als reguläre Konfiguration, ohne Eingriff in den Code.

Abfrage und Darstellung

Der aufgezeichnete Verlauf wird über eine Abfrage-Schnittstelle lesbar gemacht: gefiltert nach Zeitraum, Gruppe, Kategorie und Aktion. Anwendungen zeigen daraus eine Timeline zu einem Datensatz – in ganzen Sätzen statt in Feldnamen –, die dieselbe Grundlage für Detailansicht, Seitenleiste und Dashboard nutzt. Die Abfrage läuft dabei immer über die Plattform, nie direkt gegen den Suchindex.

Einordnung

Als Modul der Service Platform liefert das Audit-Modul die Nachvollziehbarkeit, die in regulierten Branchen und bei anspruchsvollen Kunden zählt. Zusammen mit Health-Checks und strukturiertem Logging trägt es dazu bei, dass buzzle Commerce Core nicht nur funktioniert, sondern überprüfbar funktioniert.