Technische Details

Filter, Stufen und die Gestalt einer Ereignisregel.

BEAT Hub Hubs Customizing ist klein genug, um es im Kopf zu behalten. Drei verschachtelte Entitäten (Projekt → Objekt → Ereignis), eine Filterzeile mit fünf interessanten Spalten und eine Queue mit fünf interessanten Zuständen. Diese Seite geht jeden davon in der Reihenfolge durch, in der sie zur Laufzeit zählen.

Das Datenmodell

Three nested entities, owned by one project.

Lesen Sie die Customizing-Tabellen von oben nach unten, und die Bedeutung ergibt sich: 

Project          (zbeat_prj)         # MYHUB, PRICING_COCKPIT_AUTOMATION, REA_REPLICATION, …
 └── Object      (zbeat_prjobj)     # MAT_FULL, COND_A, EINKBELEG, KRED, WLK1, …
      ├── Filter Values  (zbeat_fltv)  # DISPLAY, MMSTA_NOT_30, KHTMACHINE, PRODH_00001, …
      └── Event     (zbeat_objevn)    # MYHUB_AT002_RPT_TO_BE_REPEATED, MYHUB_AT011_NATIONAL_PRICE, …
            └── Filter (zbeat_objevnf) # eine Zeile je Bedingung, die das Ereignis erfüllen muss

Receiver Group     (zbeat_grp)         # genau eine je Projekt, benannt wie das Projekt
 ├── Consumers     (zbeat_grpcns)     # registered ABAP class implementations
 ├── Filter Values (zbeat_grpfv)      # group-scoped overrides like MY_DC, ARTICLE_TYPE
 └── Object/Event  (zbeat_grpobj/grpevn) # mit Wiederholungsmodus + Wiederholungszähler je Ereignis
Die Filterzeile

Die ganze Regel-Engine läuft auf diese Zeile hinaus.

Jedes Ereignis besitzt eine Liste von Filterzeilen in zbeat_objevnf. Jede Zeile ist eine Bedingung, die eine erfasste Änderung erfüllen muss. Sie werden AND-verknüpft. Die fünf Spalten, die einen Filter ausdrucksstark machen, sind Filter Value, Data Source Stage, Table Type, Table Name, and Field Name.

Filter Description Group Stage Table Type Table Name Field Filter Value
ARTICLE_CATEGORY Article Category 0 Main M Merged Tables MYHUB_MAT_FULL ATTYP DISPLAY
DC_ARTICLE_STATUS DC Article Status 0 Old M Merged Tables MYHUB_MAT_FULL MMSTA STATUS_LIST_AT002
STATUS_CHANGE DC Article Status Change 0 Updated M Merged Tables MYHUB_MAT_FULL MMSTA STATUS_21
RP_TYPE RT Type on DC level 0 Main Change Document Tables MARC DISMM RP_TYPE
WLK1_EXISTS Listing Check 0 Main M Merged Tables MYHUB_MAT_FULL WLK1_EXISTS NOT_EMPTY

Fünf Zeilen. Zusammen sagen sie: „löse dieses Ereignis aus, wenn ein Artikel der Kategorie DISPLAY, der eine Listung hat, von einem der AT002-Statuswerte auf Status 21 wechselt, mit konfiguriertem RP-Typ.“ Kein Code.

Data Source Stages

Wie ein Filter die Änderung „sieht“.

Eine Änderungsbeleg-Zeile hat ein Vorher- und ein Nachher-Bild. Verschiedene Filter interessieren sich für verschiedene Sichten derselben Zeile. Das Data Source Stage -Dropdown wählt, welche Sicht dieser Filter betrachtet.

Main — „die Änderung geschah, in beliebige Richtung“ (Neu ODER Zusätzlich ODER Gelöscht)
New — nur das Nachher-Bild
Old — nur das Vorher-Bild
Updated — Old <> New AND Old <> space (a real value-to-value change)
Inserted — eine Zeile, die vorher nicht existierte
Deleted — eine Zeile, die im Vorher-Bild existiert, aber nicht danach
Edited — Update OR Inserted (with optional X-structure variant for low-level reads)
Additional — eine Zeile, die BEAT Hub beim Zusammenführen aus einer verwandten Tabelle holte

Die Table Type -Dropdown steht neben Stufe und wählt die Datenquelle, aus der der Filter liest: Change Document Tables (MARA, MARC…), Sicht-Tabellen (die das Projekt definiert hat), Merged Tables (die verknüpfte Sicht, die BEAT Hub zur Laufzeit baut), oder System Tables.

Die bgRFC-Queue

Five states. No scheduler.

Once a captured row enters zbeat_cdqueue, it walks through one of these states. ZBEAT_CDQUEUE_PROC ist die Live-Sicht der Queue.

QUEUED
Awaiting
Ein Worker hat die Einheit noch nicht aufgegriffen. Der Standardzustand beim Einfügen.
PROC
Processing
Ein Worker hat die Einheit und ruft die Consumer-Klasse auf.
DONE
Forwarded
Consumer kehrte ohne Ausnahme zurück. CDHDR-Zeile als FORW markiert.
FAIL
Errored
Consumer raised. If retries remain, transitions to RETRY; otherwise stays FAIL.
RETRY
Re-queueing
Bumped back to QUEUED with retryNo + 1. CDHDR row marked REPRO when it eventually succeeds.
Warum nicht einfach ein Job?

Zum Vergleich: dasselbe Problem, auf die alte Art.

Job-based polling

Nightly / hourly batch

  • Scheduler config + monitoring + on-call coverage
  • Latency = next run window (up to N hours stale)
  • Liest CDPOS in jedem Zyklus neu von der Platte, auch wenn sich nichts geändert hat
  • Erfassungslogik je Abnehmer neu implementiert
  • Single point of failure: one missed run = one missed event
  • Hard to scale: bigger window = bigger query, not more parallelism
BEAT Hub (real-time, bgRFC)

Erfassen beim Speichern, parallel ausliefern

  • Kein Scheduler. Die Erfassung ist Teil des Speicherns des Nutzers.
  • Latency measured in hundreds of milliseconds.
  • Das Lesen geschieht einmal, geteilt von jedem Abnehmer.
  • Die Erfassung lebt im Customizing, nicht im Code.
  • Fehlgeschlagene Auslieferungen werden je Ereignis-Wiederholungsmodus automatisch erneut versucht.
  • Der Durchsatz skaliert durch zusätzliche Worker im bgRFC-Pool.