Message Headers Reference
This page lists every x.abs.* header understood by DREX-M, grouped by purpose.
If you use the Service-Bus Library you rarely set these key strings yourself - the Library converts strong-typed properties (SourceSite, BroadcastRange, etc.) into the correct header names.
When you work with a raw AMQP client, use the Qualified header names exactly as shown.
All keys live in the x.abs. namespace and are case-sensitive.
Custom application headers may be added outside this namespace; any key starting with x.abs. that is not in the list below will be rejected.
Core Routing Headers (required for delivery)
Qualified Header Key | Library Property | Description
x.abs.app.src.name | SourceApp.Name | Name of the sending adapter
x.abs.app.trg.name | TargetApp.Name | Name of the target adapter
x.abs.site.src.type x.abs.site.src.id | SourceSite | Sender site tier (vessel,central,abs-cloud) and ID
x.abs.site.trg.type x.abs.site.trg.id | TargetSite | Target site tier and ID
Intent & Flow Control
Qualified Header Key | Library Property | Notes
x.abs.scope | Scope | Required = BROADCAST for broadcast; optional but recommended for direct patterns (LINEAR, REQUEST, etc.)
x.abs.topic | Topic | Subject for broadcast; wildcards allowed in subscriptions
x.abs.seq | Sequence | Integer sequence number (optional)
x-delay | (direct property) | Delay in milliseconds for timed delivery (uses RabbitMQ delayed-message plug-in)
Broadcast Range
Qualified Header Key | Library Source | Meaning
x.abs.bcast.area.vessel | BroadcastRange.Vessel | NONE, LOCAL, WIDE
x.abs.bcast.area.central | BroadcastRange.Central | NONE, LOCAL (LOCAL = WIDE; single central per client)
x.abs.bcast.area.abs_cloud | BroadcastRange.Cloud | NONE, LOCAL (single cloud per client)
All three headers must be present when x.abs.scope = BROADCAST.
Feedback (Direct patterns only)
Qualified Header Key | Populated When | Description
x.abs.feedback.request | Sender sets FeedbackRequest | "TRUE" ⇒ ask Drex to return feedback if delivery fails
x.abs.feedback.response | Drex returns a feedback msg | Always "TRUE" on feedback messages
x.abs.feedback.response.cause | Feedback message | EXPIRED, REJECTED, BADSITE, BADAPP, BAD_TENANT, OVERFLOW, OTHER, UNKNOWN
x.abs.feedback.response.timestamp | Feedback message | AMQP timestamp when failure detected
x.abs.feedback.response.site.id x.abs.feedback.response.site.type | Feedback message | Site where the failure occurred
Feedback is only a failure notification—it does not confirm successful delivery.
Typing, Correlation & Expiry
Qualified Header Key / AMQP Property | Library Property | Purpose
AMQP MessageId | Id | Globally unique ID (set automatically if omitted)
AMQP CorrelationId | CorrelationId | Request/Response or stream correlation
x.abs.app.type.ver | Type.Version | Version number of the business message type
AMQP Type | Type.Type | Business message type / schema name
AMQP Timestamp | Timestamp | Publish-time of the message
AMQP Expiration | TimeToLive | Milliseconds until the broker discards the message
Tenant Headers (required for Cloud-tier routing)
When a message enters the Cloud tier, Drex’s Cloud processor uses tenant headers to decide whether the message is routable or should be rejected with BAD_TENANT.
Header Key | Library Property | Usage Rules
x.abs.ten.cc.id / .name / .owner | ComCoreTenant.Id / .Name / .Owner | • Preferred way to identify the tenant. • ID must be a GUID recognised by Cloud tenant registry. • owner is not used.
x.abs.ten.cli.id / .name / .owner | ClientTenant.Id / .Name / .Owner | • Alternative when Common-Core tenant ID is unknown. • owner must contain the Client ID (GUID).
x.abs.ten.par.id / .name / .owner | PartnerTenant.Id / .Name / .Owner | Optional partner metadata; currently not used for routing.
If Drex Cloud cannot resolve a tenant from these headers the message is routed to the Bad-Tenant feedback path and a BAD_TENANT feedback message may be returned to the sender (for Direct scopes).
Application Id & Version Metadata (optional)
Qualified Header Key | Library Property
x.abs.app.src.id | SourceApp.Id
x.abs.app.src.ver | SourceApp.Version
x.abs.app.trg.id | TargetApp.Id
x.abs.app.trg.ver | TargetApp.Version
Custom Headers
You may attach arbitrary application-specific headers.
Two simple rules keep you future-proof:
Prefer a non-ABS prefix, e.g. my.product.foo = "bar".
If you must add a new key under x.abs., coordinate with the Common Core team first to avoid collisions with future reserved names.
The library copies any key/value pair whose key is not in the reserved list
(RmqHeaderKeys.IsReservedHeaderKey(key) == false).
# Inspecting Headers
Open RabbitMQ Management UI (https://<host>:15671) → Queues → Get Message to view the exact headers on a sample message.