Echtzeit-Ereignisbenachrichtigung

Die Signalebene für Ihre SAP-Stammdaten­änderungen.

Jeder SAVE in S/4HANA erzeugt ein Änderungsbeleg. BEAT macht aus diesen verstreuten Änderungsbeleg-Zeilen einen sauberen, deklarativen Strom von Events — im Moment des Geschehens erfasst, nach konfigurierbaren Regeln gefiltert und parallel an alle ausgeliefert, die sie brauchen.

Demo öffnen → Erst das Problem ansehen
Video-Einführung

BEAT in Aktion sehen.

Was es ist, die kleine Idee dahinter und ein durchgespieltes Beispiel — eine Preiskonditionsänderung, verbunden mit dem Prozess, der dadurch ausgelöst werden soll.

Das Problem

Fünf Integrationen. Fünf Wartungsaufwände. Null gemeinsames Signal.

Der Standardweg, in S/4 auf eine Stammdatenänderung zu reagieren, ist das, was gerade am einfachsten war: ein nächtlicher Job, der CDPOS erneut liest, ein IDoc mit eigenem Mapping, ein RFC-Polling alle fünfzehn Minuten, ein E-Mail-Plugin, eine Z-Tabellen-Flag-Spalte. Jeder löst das Problem eines nachgelagerten Systems — und fügt der Landschaft ein weiteres bewegliches Teil hinzu.

Jedes Team, das dasselbe Event braucht, schreibt es am Ende neu. Die Erfassungslogik driftet auseinander. Latenz wächst. Wenn ein Feld umbenannt wird, brechen drei dieser Integrationen still und leise — und eine schickt einfach weiter E-Mails an die falsche Gruppe.

Die Gestalt von BEAT

Ein Erfassungspunkt. Eine deklarative Regel-Engine. Viele Verbraucher.

BEAT sitzt in S/4 als implizites Enhancement auf dem Änderungsbeleg-SAVE. Die Regeln leben im Customizing — ein Projekt, ein Änderungsbeleg-Objekt, ein Event und eine Liste von Filter-Zeilen. Wenn ein SAVE die Regeln erfüllt, schreibt BEAT eine Zeile in seine Event-Tabelle und stellt eine bgRFC-Unit in die Warteschlange. Worker holen die Unit sofort ab und verteilen sie parallel an jeden registrierten Verbraucher.

Sie konfigurieren einmal. Jedes nachgelagerte System — MyHub, Pricing Cockpit, REA-Replikation, was immer Sie als Nächstes bauen — abonniert, indem es eine Consumer-Klasse für dasselbe Event registriert. Kein neuer Erfassungscode pro Integration.

So nutzen Sie es

Drei Schritte. Kein Code. Das Event ist konfiguriert und bereit für jeden Verbraucher.

1

Projekt anlegen

Geben Sie ihm einen Namen, aktivieren Sie es. Ein Projekt ist nur ein Container für die Events, die Sie senden möchten — ein Projekt pro logischer Pipeline.

2

Objekt wählen & Event anlegen

Wählen Sie das Änderungsbeleg-Objekt, das Sie überwachen möchten, definieren Sie ein Event und fügen Sie die gewünschten Filter hinzu. Das war's — die Regel ist aktiv. Kein Code, keine Transports von Programmänderungen.

3

Verbraucher abonnieren

Jedes System kann sich als Verbraucher Ihres Events registrieren. Dasselbe Event, viele Verbraucher — MyHub, Pricing Cockpit, REA-Replikation, was immer Sie als Nächstes bauen. Keiner implementiert die Erfassung neu.

Warum es funktioniert

Vier Eigenschaften, die den Betrieb von BEAT angenehm machen.

Echtzeit, nicht Job-basiert

Die Erfassung passiert innerhalb der SAVE-Transaktion. Die Verteilung läuft über eine bgRFC-Queue mit Worker-Pool. Es gibt keinen Scheduler zu überwachen und kein „nächster Lauf"-Fenster zu verpassen.

Parallel by Design

Jedes erfasste Event ist seine eigene bgRFC-Unit. Unabhängige Units laufen auf unabhängigen Workprozessen — der Durchsatz skaliert über mehr Worker, nicht über das Tuning eines einzelnen Jobs.

Deklarativ, im Customizing

Regeln leben in Tabellen, nicht in ABAP. Filterwerte sind wiederverwendbare benannte Konstanten. Neue Events fügen Zeilen hinzu — keinen Code und keinen Transport von Programmänderungen.

Mehrere Verbraucher, per Registrierung

Eine Empfängergruppe registriert Consumer-Klassen. Ein neues nachgelagertes System hinzuzufügen bedeutet, eine Klasse zu schreiben und eine Zeile hinzuzufügen — jedes bestehende Event ist dann verfügbar, ohne die Erfassungslogik neu zu schreiben.

Automatische Wiederholung

Jedes Event hat seinen eigenen Retry-Modus und Retry-Count. Fällt ein nachgelagerter Verbraucher aus, wird die Auslieferung automatisch wiederholt — Operatoren müssen nicht aufpassen.

Eine Signalquelle für alles

MyHub, das Pricing Cockpit, REA-Replikation, Special-Buy-Filialmanagement, Aktionsmengen­änderungen — sie alle konsumieren dieselben BEAT-Events. Ein neues nachgelagertes System hinzufügen heißt einen Consumer hinzufügen, nicht einen neuen Erfassungs-Stack.

Für wen

Wenn Sie irgendetwas ausliefern, das auf SAP-Stammdaten reagiert, ist BEAT die Schicht darunter.

🛠
SAP integration teams

Eine konfigurierbare Erfassung statt N IDoc-/RFC-/Job-Stacks pro nachgelagertem System.

📋
Master-data teams

Eine einzige, auditierbare Spur dessen, was geändert wurde, von wem und was darauf reagiert hat.

⚙️
Downstream app owners

Per registrierter Consumer-Klasse abonnieren. Erfassungslogik nie wieder schreiben.

📊
Data platform teams

Echtzeit-Stammdatensignale für Ihr Warehouse / Streams / Reporting.

In Aktion sehen

Öffnen Sie ZBEAT_SET, navigieren Sie durch den Dialog-Strukturbaum und beobachten Sie, wie der bgRFC-Queue-Monitor Events in Echtzeit verarbeitet.

Open the demo → Architektur lesen