Technische Details

Wie Nachrichten durch MyHub fließen

MyHub kennt drei Nachrichtenquellen — Systemereignisse, von Menschen verfasste Notizen und programmatische ABAP-Aufrufe. Jede folgt demselben Routing-Modell und mündet im selben Eingang. So funktioniert es unter der Haube.

Drei Wege, auf denen eine Nachricht entstehen kann.

Sie teilen dieselbe Datenform und dieselbe nachgelagerte Pipeline. Was sich unterscheidet, ist, wer oder was sie auslöst.

Automated · AT

Automated Messages

Generated automatically when something changes in the back-office system — a price moves, a listing goes live, a contract item gets removed. The system fires a structured event; MyHub turns it into an Inbox message for every Receiver Group that subscribes.

Origin: CENT (Change Event Notification Tool) Trigger code: AT### Authoring: Nur Konfiguration — kein Mensch schreibt den Inhalt
Free Text · FT

Free Text Messages

Von einem Menschen im MyHub-Ausgang verfasst. Der Sender wählt einen Freitext-Auslöser, der die Eingabefelder definiert, schreibt die Nachricht, leitet sie optional durch eine Freigabe und wählt, welche Empfängergruppen sie erhalten.

Origin: Ausgang-UI (Fiori-App) Trigger code: FT### Authoring: Mensch, mit optionalem Freigabe-Workflow
Cross-Message · CT

Cross-Messages NEW

The newest addition. A CT is a Free Text message posted programmatically from ABAP code — anywhere — through the Outbox API. Use it when you need typed, structured communication driven by custom logic that doesn't fit a CENT event.

Origin: ABAP code (BAdI, exit, custom job, BAPI…) Trigger code: CT### Authoring: Code-driven, fully under developer control

Automatische Nachrichten — von der Datenänderung zur umsetzbaren Aufgabe

The classic MyHub flow. Wired in via configuration; no per-message code.

Wann immer sich ein relevantes Stammdaten-Attribut ändert — etwa ein regionales Listungsdatum oder eine Bruttopreis-Kondition — erfasst das Quellsystem es als Änderungsbeleg. CENT beobachtet diese Änderungen und sendet ein typisiertes Ereignis. MyHubs Prozessor empfängt das Ereignis, schlägt nach, welche Receiver Groups diesen Auslösercode abonniert haben, wendet die Filterregeln jeder Gruppe an und erstellt je passender Gruppe eine Eingangsnachricht.

Step 1 Change happens User updates master data in S/4 (or another source system)
Step 2 CENT detects Liest den Änderungsbeleg, löst ein strukturiertes Ereignis aus
Step 3 MyHub processes Maps event → trigger code, finds subscribed RGs, applies filters
Step 4 Message lands Ein Eingangs-Eintrag je EG, mit angehängtem Stammdaten-Schnappschuss

Was ATs mächtig macht, ist der "Current vs At Event Time" -Schnappschuss — jede Eingangsnachricht trägt sowohl den ursprünglichen Datenzustand zum Auslösezeitpunkt als auch den aktuellen Live-Zustand. Prüfer sehen immer, was sich tatsächlich geändert hat, auch Tage später.

Free Text Messages — humans broadcasting to teams

Für Ankündigungen, Warnungen und Ad-hoc-Notizen, die ein strukturiertes Zuhause brauchen.

FTs sind MyHubs Antwort auf die Frage „was ist mit Updates, die nicht an eine Stammdatenänderung gebunden sind?“ Ein Einkäufer, der ein Lieferproblem melden will, ein Category-Planer, der eine Einführung ankündigt, ein Audit-Team, das einen Prüfpunkt verbreitet — sie alle nutzen den Ausgang.

Step 1 User opens Outbox Clicks Create, picks an FT trigger and Sending Receiver Group
Step 2 Füllt das Formular aus Input fields tailored to the trigger; rich-text body; attachments
Step 3 Approval (optional) Routes to an Approver if the trigger requires it; can be rejected back
Step 4 Posted to Distribution List Jede empfangende EG erhält am Buchungsdatum eine Eingangskopie

Jeder FT-Auslöser hat sein eigenes konfigurierbares Eingabeschema, einmal von einem Admin in der Administrative Workbench definiert unter Free Text Trigger. Dieses Schema steuert, welche Felder im Ausgang-Formular erscheinen — Artikel-ID, Standort (DC), Lieferant, Dringend-Flag, Buchungsdatum usw. — sodass Eingaben konsistent und maschinenlesbar bleiben.

Cross-Messages — Ausgang, aber aus ABAP NEW

Die Flexibilität von Freitext-Nachrichten, aufrufbar von jeder Stelle im Code.

Sometimes you need to communicate something typed and structured, aber es ist keine Stammdatenänderung, die CENT erkennen kann. Vielleicht ein eigener Report, der fertig wird. Vielleicht ein Nachtjob, der eine Anomalie erkennt. Vielleicht eine geplante Aufräumaufgabe, die drei Teams sagen muss, welche Artikel sie berührt hat. Hier kommen CTs ins Spiel.

Eine CT ist funktional identisch mit einer FT — gleiches Auslöser-Schema, gleiche Eingangsansicht für den Empfänger, gleicher Status-Lebenszyklus — aber statt von einem Menschen im Ausgang-UI verfasst zu werden, wird sie direkt über die öffentliche Ausgang-API gebucht. Ihr ABAP-Code erledigt die Arbeit, die ein Mensch im Formular getan hätte.

// ABAP — posting a Cross-Message from a custom job
CALL FUNCTION 'Z_MYHUB_API_POST_FREE_TASK'
  EXPORTING
    iv_trigger_code   = 'CT042'      "<-- registered Cross-Msg trigger
    iv_sending_group  = 'WAREHOUSE_OUTBOUND'
    iv_message_text   = lv_html_body
    iv_post_date      = sy-datum
  TABLES
    it_input_fields   = lt_fields           "<-- Article ID, DC, etc.
    it_distribution   = lt_receiver_groups  "<-- which RGs get it
    it_attachments    = lt_files
  EXCEPTIONS
    invalid_trigger   = 1
    not_authorized    = 2
    OTHERS            = 3.

IF sy-subrc = 0.
  log( |MyHub CT posted: { ev_message_id }| ).
ENDIF.

Why CTs matter:

  • You decide when die Nachricht ausgelöst wird — überall dort, wo ein ABAP-Event-Handler, ein BAdI oder ein Batch-Job laufen kann.
  • You decide who sie empfängt — übergeben Sie eine explizite EG-Liste oder berechnen Sie sie zur Laufzeit aus eigener Logik.
  • Sie können den Nachrichtentext programmatisch vorbefüllen — mit formatiertem HTML, Stammdaten-Nachschlägen, berechneten Feldern — allem, was ABAP erzeugen kann.
  • Die Nachricht landet im Eingang und sieht genau wie eine FT aus, sodass Empfänger kein neues UI lernen müssen.

Häufige CT-Muster: nächtliche Anomalie-Berichte, eigene Integrationswarnungen (ein externes System hat uns fehlerhafte Daten geliefert), Aufräumjob-Zusammenfassungen, Post-Go-Live-„darauf achten“-Ankündigungen, die in keinen Standard-Auslöser passen.

Distribution model

Wie Nachrichten die richtigen Empfängergruppen erreichen.

Alle drei Nachrichtenarten laufen durch dieselbe Routing-Engine. Der Unterschied ist, wer die Empfängerliste liefert.

Die Routing-Regeln in einfachen Worten

  • For ATs: Die Empfängerliste ist implizit. Jede Empfängergruppe, die diesen AT-Auslöser in der Administrative Workbench abonniert, ist ein Kandidat. Dann entscheiden Filter je EG (DC-Liste, Artikelart, Produkthierarchie, Warengruppe), wer tatsächlich qualifiziert ist.
  • For FTs: Der Sender stellt die Verteilerliste im Ausgang zusammen. Er wählt vor dem Buchen ausdrücklich, welche EGs einbezogen werden.
  • For CTs: Der ABAP-Aufrufer übergibt die EG-Liste als Parameter. Sie kann hartcodiert, aus einer eigenen Konfig-Tabelle nachgeschlagen oder zur Laufzeit aus beliebiger Geschäftslogik berechnet werden.

Lead Time: Jedes Abonnement kann eine Vorlaufzeit in Tagen angeben. Ist sie gesetzt, kommt die Nachricht an Waiting List status and flips to New wenn (Buchungsdatum − Vorlaufzeit) erreicht ist. Nützlich für Muster wie „dem Lager eine Woche vor dem Listungstag Bescheid geben“.

Status lifecycle

Von gebucht bis verarbeitet — und alles dazwischen.

Both ends of the conversation track state independently. The Outbox shows where a message is in its publishing lifecycle; the Inbox shows where it is in each receiver's processing lifecycle.

Eingangs-Lebenszyklus (je Empfänger)

Seitliche Status (Zurückgestellt, Nicht erforderlich, Auto-geschlossen) sind aus „Neu“ oder „In Bearbeitung“ über die entsprechenden Schaltflächen erreichbar. Die Reset -Schaltfläche setzt eine Nachricht stets auf „Neu — zurückgesetzt“ und löscht die Zuweisung.

Ausgang-Lebenszyklus (je Sender)

Freitext-Nachrichten können die Freigabeschritte überspringen, wenn der Auslöser für direktes Buchen konfiguriert ist. Cross-Messages buchen typischerweise direkt, weil der ABAP-Aufrufer die Validierung bereits erledigt hat.
Quick reference

Glossar für Ungeduldige.

AT Automated Trigger
An identifier (e.g. AT015) for a kind of system event that MyHub knows about. Configured once; hundreds of messages may flow through one AT over time.
FT Free Text Trigger
Eine Kennung (z. B. FT003) für eine Kategorie von menschlich verfassten Nachrichten. Definiert, welche Eingabefelder im Ausgang-Formular erscheinen und ob eine Freigabe nötig ist.
CT Cross-Message Trigger
Gleiche Form wie eine FT, aber speziell für die Nutzung über die ABAP-API registriert. Trägt dieselben Felder und Freigaben wie FTs, ohne UI zum Auslösen.
Receiver Group (RG)
The unit of subscription. Users belong to RGs; messages are addressed to RGs, not individuals. RGs configure their own filters and Lead Times.
Sending Receiver Group
Bei FTs und CTs die EG, der die ausgehende Nachricht „gehört“ — typischerweise das für die Ankündigung verantwortliche Team.
Distribution List
Bei FTs und CTs die explizite Menge der EGs, die die Nachricht erhalten. (Bei ATs wird die Liste aus Abonnements berechnet.)
Lead Time
Ein optionaler Versatz (in Tagen), der eine Nachricht vom Status „Warteliste“ auf „Neu“ verzögert. Lässt Empfänger Dinge kurz vor dem Handeln sehen, nicht Wochen im Voraus.
Post Date
The date the message becomes active for receivers. For ATs it equals the event date; for FTs/CTs the sender chooses it.

Das alles in Aktion sehen?

Die Demo enthält Beispieldaten für ATs, FTs und ein CT-Beispiel, mit demselben Routing-Modell, über das Sie gerade gelesen haben.

Die MyHub-Demo öffnen