Echtzeit-Ereignisbenachrichtigung

Die Signalschicht für Ihre SAP-Stammdatenänderungen.

Jedes Speichern in S/4HANA erzeugt einen Änderungsbeleg. BEAT Hub macht aus diesen verstreuten Änderungsbeleg-Zeilen einen sauberen, deklarativen Ereignisstrom — im Moment ihres Entstehens erfasst, durch konfigurierbare Regeln gefiltert und parallel an alles geliefert, das sie braucht.

Video-Einführung

BEAT Hub in Aktion.

Was es ist, die kleine Idee dahinter und ein durchgespieltes Beispiel — eine Preiskonditionsänderung, verdrahtet mit dem Prozess, der sie auslösen soll.

Das Problem

Fünf Integrationen. Fünf Wartungslasten. Kein gemeinsames Signal.

Der Standardweg, auf eine Stammdatenänderung in S/4 zu reagieren, ist das, was gerade am einfachsten war: ein Nachtjob, der CDPOS neu liest, ein IDoc mit eigenem Mapping, ein RFC-Polling alle fünfzehn Minuten, ein E-Mail-Plugin, eine Flag-Spalte in einer Z-Tabelle. Jedes löst das Problem eines Abnehmers und fügt ein weiteres zu betreibendes Teil hinzu.

Jedes Team, das dasselbe Ereignis braucht, schreibt es am Ende erneut. Die Erfassungslogik driftet auseinander. Die Latenz steigt. Wird ein Feld umbenannt, brechen drei dieser Integrationen still, und eine mailt einfach weiter an die falsche Gruppe.

Die Gestalt von BEAT Hub

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

BEAT Hub sitzt in S/4 als implizite Erweiterung am Änderungsbeleg-Speichern. Regeln liegen im Customizing — ein Projekt, ein Änderungsbeleg-Objekt, ein Ereignis und eine Liste von Filterzeilen. Passt ein Speichern zu den Regeln, schreibt BEAT Hub eine Zeile in seine Ereignistabelle und stellt eine bgRFC-Einheit in die Queue. Worker greifen die Einheit sofort auf und rufen die Consumer-Klassen auf, die die Empfängergruppe registriert hat.

Sie konfigurieren einmal. Jeder Abnehmer — MyHub, Pricing Cockpit, REA-Replikation, was auch immer Sie als Nächstes bauen — abonniert, indem er eine Consumer-Klasse gegen dasselbe Ereignis registriert. Kein neuer Erfassungscode je Integration.

So nutzen Sie es

Drei Schritte. Kein Code. Das Ereignis ist konfiguriert und für jeden Abnehmer bereit.

1

Ein Projekt anlegen

Geben Sie ihm einen Namen, aktivieren Sie es. Ein Projekt ist nur ein Behälter für die Ereignisse, die Sie senden möchten — ein Projekt je logischer Pipeline.

2

Ein Objekt wählen & ein Ereignis anlegen

Wählen Sie das Änderungsbeleg-Objekt, das Sie verfolgen wollen, definieren Sie ein Ereignis und fügen Sie die gewünschten Filter hinzu. Das war's — die Regel ist aktiv. Kein Code, keine Transporte von Programmänderungen.

3

Abnehmer abonnieren

Jedes System kann sich als Abnehmer Ihres Ereignisses registrieren. Dasselbe Ereignis, viele Abnehmer — MyHub, das Pricing Cockpit, REA-Replikation, was Sie als Nächstes bauen. Keiner von ihnen implementiert die Erfassung neu.

Warum es funktioniert

Vier Eigenschaften, die BEAT Hub angenehm zu betreiben machen.

Echtzeit, nicht jobbasiert

Die Erfassung geschieht in der Speichern-Transaktion. Die Auslieferung läuft über eine bgRFC-Queue mit einem Worker-Pool. Es gibt keinen Scheduler zu überwachen und kein „nächster Lauf“-Fenster zu verpassen.

Parallel von Grund auf

Jedes erfasste Ereignis ist seine eigene bgRFC-Einheit. Unabhängige Einheiten laufen auf unabhängigen Workprozessen — der Durchsatz skaliert durch zusätzliche Worker, nicht durch das Tuning eines einzelnen Jobs.

Deklarativ, im Customizing

Regeln liegen in Tabellen, nicht in ABAP. Filterwerte sind wiederverwendbare benannte Konstanten. Neue Ereignisse fügen Zeilen hinzu; sie fügen keinen Code und keinen Transport von Programmänderungen hinzu.

Mehr-Abnehmer, per Registrierung

Eine Empfängergruppe registriert Consumer-Klassen. Einen neuen Abnehmer hinzuzufügen heißt: eine Klasse schreiben und eine Zeile ergänzen — jedes bestehende Ereignis steht ihm dann zur Verfügung, ohne die Erfassungslogik neu zu schreiben.

Automatische Wiederholung

Jedes Ereignis hat seinen eigenen Wiederholungsmodus und Wiederholungszähler. Schlägt ein Abnehmer fehl, wird die Auslieferung automatisch erneut versucht — Betreiber müssen nicht aufpassen.

Eine Signalquelle für alles

MyHub, das Pricing Cockpit, REA-Replikation, Aktionsartikel-Filialsteuerung, Promotionsmengen-Änderungen — sie alle konsumieren dieselben BEAT-Hub-Ereignisse. Einen Abnehmer durch Hinzufügen eines Consumers ergänzen, nicht durch einen neuen Erfassungs-Stack.

Für wen es ist

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

🛠
SAP-Integrationsteams

Eine konfigurierbare Erfassung statt N IDoc-/RFC-/Job-Stacks je Abnehmer.

📋
Stammdaten-Teams

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

⚙️
Verantwortliche für nachgelagerte Apps

Abonnieren durch Registrieren einer Consumer-Klasse. Schreiben Sie die Änderungserfassung nicht erneut.

📊
Datenplattform-Teams

Echtzeit-Stammdatensignale, um Ihr Warehouse / Ihre Streams / Ihre Reporting-Schicht zu speisen.

Sehen Sie es in Aktion

Öffnen Sie ZBEAT_SET, um den Dialogstruktur-Baum zu durchlaufen, und beobachten Sie dann, wie der bgRFC-Queue-Monitor Ereignisse in Echtzeit verarbeitet.