BEAT Hub lives inside S/4. Es gibt keinen separaten Server auszurollen, keinen Broker zu betreiben, keinen Message-Bus zu lizenzieren. Die Erfassung geschieht im selben Speicher wie das Speichern des Nutzers, und die Auslieferung läuft über die systemeigene Hintergrund-RFC-Infrastruktur.
Das ganze Werkzeug sind zwei Ideen: Änderungen im Moment ihres Entstehens erfassen, dann an jeden übergeben, der sie angefordert hat. Alles andere ist Konfiguration. Sie können es in einem Meeting in fünf Minuten erklären — und genau diese Einfachheit lässt es auf Dutzende Abnehmer skalieren, ohne zu jemandes Vollzeitjob zu werden.
Wenn sich in S/4 etwas ändert, führt BEAT Hub nicht „den Auslieferungsjob“ aus. Es baut einen kleinen Baum von Hintergrundprozessen — jeder Zweig unabhängig, jede Ebene fügt Parallelität hinzu. Das Bild unten zeigt, was wirklich passiert, von oben nach unten, jedes Mal, wenn eine konfigurierte Änderung gespeichert wird.
In derselben Transaktion, die der Nutzer speichert, führt BEAT Hub einen winzigen Schritt aus, der sammelt die Änderungsdaten aus dem Standard-Änderungsbeleg-Mechanismus. Kein Filtern, kein Ausliefern, keine Aufrufe nach außen — nur die Änderung erfassen und übergeben. Die Kontrolle geht sofort an den Nutzer zurück. Dieser Schritt ist klein genug, dass der Nutzer ihn nicht wahrnimmt.
Die erfasste Änderung wird an einen brandneuen bgRFC-Prozess übergeben, der dieser einzelnen Änderung gewidmet ist. That's where the analysis starts. The first thing it does is look up which Projects in the system are configured to track this kind of object — for the article object that might be MYHUB, PRICING_COCKPIT and REA_REPLICATION; for a contract it might be only one. Whatever the answer is, this process spawns one bgRFC per Project and walks away.
Der Prozess jedes Projekts läuft jetzt in seinem eigenen Workprozess, auf seinem eigenen Thread. Er geht jedes Ereignis durch, das das Projekt auf diesem Objekt hat, wertet die Filterzeilen aus und entscheidet, welche Ereignisse auslösen sollen. Manche Projekte erzeugen null Treffer und beenden still. Andere einen. Andere viele. Was auch herauskommt: Die Analyse keines Projekts blockiert die eines anderen.
Für jedes ausgelöste Ereignis startet BEAT Hub einen separaten bgRFC-Prozess für jeden dagegen registrierten Consumer. Hat MyHub zwei Consumer an einem Ereignis und das Pricing Cockpit einen, sind das drei weitere unabhängige Prozesse. Jeder Consumer läuft in seinem eigenen Workprozess, in seinem eigenen Speicher. Was er auch tut — eine Nachricht schreiben, Preise neu berechnen, an ein nachgelagertes System senden — er tut es isoliert.
Isolation by design. Stürzt ein einzelner Consumer ab — geht der Speicher aus, ein Datenbank-Deadlock, eine unbehandelte Ausnahme, irgendetwas — bleibt der Dump im bgRFC-Prozess dieses Consumers. Die anderen Consumer sehen ihn nicht. Die anderen Projekte sehen ihn nicht. Die ursprüngliche Nutzersitzung ist längst fertig. Ein kaputter Abnehmer kann den Rest der Pipeline nicht mitreißen. Und der Durchsatz skaliert durch zusätzliche Worker im Pool, nicht durch das Tuning eines einzelnen Jobs.
Wann immer in S/4 etwas geändert wird — ein Artikel, ein Preis, ein Kontrakt, ein Lieferant — erfasst das System diese Tatsache bereits über seinen Änderungsbeleg-Mechanismus. BEAT Hub klinkt sich in diesen Kernfluss ein. Vom Moment des Speicherns an kann BEAT Hub die Änderung aufgreifen, die Regeln auswerten und übergeben — für jede Änderung im System, solange die Konfiguration es sagt.
Nichts verlässt S/4, sofern Sie es nicht angeordnet haben. Nichts wird beobachtet, sofern Sie es nicht konfiguriert haben. Die Signalschicht ist Teil desselben Systems, in dem die Daten ohnehin leben.
Die Seite Reale Szenarien geht zwei alltägliche Situationen durch — eine Preisänderung und eine Artikel-Auslistung — ganz ohne technische Details. Nützlich für ein fachliches Publikum.