MyHub recognizes three sources of messages — system events, human-authored notes, and programmatic ABAP calls. Each follows the same routing model and converges in the same Inbox. Here's how it works under the hood.
They share the same data shape and the same downstream pipeline. What differs is who or what triggers them.
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.
Composed by a human in the MyHub Outbox. The sender picks a Free Text trigger that defines the input fields, writes the message, optionally routes it through approval, and chooses which Receiver Groups will receive it.
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.
The classic MyHub flow. Wired in via configuration; no per-message code.
Whenever a relevant master-data attribute changes — say, a regional listing date or a gross price condition — the source system records it as a change document. CENT watches those changes and emits a typed event. MyHub's processor receives the event, looks up which Receiver Groups have subscribed to that trigger code, applies each group's filter rules, and creates one Inbox message per matching group.
What makes ATs powerful is the "Current vs At Event Time" snapshot — every Inbox message carries both the original state of the data when the event fired and the live state right now. Reviewers always see what actually changed, even days later.
For announcements, alerts, and ad-hoc notes that need a structured home.
FTs are MyHub's answer to the question "what about updates that aren't tied to a master-data change?" A buyer who wants to flag a delivery issue, a category planner announcing a launch, an audit team broadcasting a checkpoint — they all use the Outbox.
Each FT trigger has its own configurable input schema, defined once by an admin in the Administrative Workbench under Free Text Trigger. That schema controls what fields appear in the Outbox form — Article ID, Site (DC), Supplier, Urgent flag, Post Date, etc. — so submissions stay consistent and machine-readable.
The flexibility of Free Text messaging, callable from any place in the codebase.
Sometimes you need to communicate something typed and structured, but it's not a master-data change CENT can detect. Maybe it's a custom report finishing up. Maybe a nightly job that detects an anomaly. Maybe a scheduled cleanup task that needs to tell three teams which articles it touched. That's where CTs come in.
A CT is functionally identical to an FT — same trigger schema, same Inbox view for the receiver, same status lifecycle — but instead of being authored by a human in the Outbox UI, it's posted directly through the public Outbox API. Your ABAP code does the work that a human would have done in the form.
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:
Common CT patterns: nightly anomaly reports, custom integration alerts (an external system handed us bad data), cleanup-job summaries, post-go-live "watch this" announcements that don't fit any standard trigger.
All three message types funnel through the same routing engine. The difference is who supplies the destination list.
Lead Time: Each subscription can specify a Lead Time in days. If set, the message arrives in Waiting List status and flips to New when (Post Date − Lead Time) is reached. Useful for "tell the warehouse a week before listing day" patterns.
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.
The demo includes mock data for ATs, FTs, and a CT example, with the same routing model you just read about.
Open the MyHub demo →