Message types
A named handle for a recognizable shape of data - the contract subscriptions, maps, and tracking rules reference.
A message type gives a friendly name to the kind of payload moving through your integration - PurchaseOrder, InvoiceAck, InventorySnapshot, whatever vocabulary the business uses. Once a message has been classified as a particular type, the rest of the platform - subscriptions, maps, custom pipeline components, tracking - can reason about it by name instead of by where it came from.
Message types live inside an Application. Each one carries a Format, an optional Description, and a set of Promotions that elevate selected payload values into named tokens any downstream expression can read.
In BizTalk, a message type is a schema - the schema's target namespace and root element name together form the type, and defining a type without a schema is impossible. Art2link ESB takes the opposite stance: a message type is a name you choose, and a schema is an optional, additive validation layer you may associate with it later.
The practical effect is that you can introduce a new type for an integration in seconds - no XSD, no canonical model, no contract negotiation up front. When (and if) you decide a structural check is warranted, you create a schema and bind it to the type. Until then, the type is purely a label the platform uses for routing, mapping, and tracking.
Message types are scoped to an Application. From the application menu, the Message types list shows every type you have defined. Each entry has these fields:
| Field | Purpose |
|---|---|
| Name | How the message type is referenced everywhere else - in subscriptions, maps, schema associations, and the runtime tag attached to each message. |
| Format | XML, JSON, CSV, or TXT - declares the shape the payload is expected to take. See Format below. |
| Description | Free-text description for human readers. Optional, has no runtime effect. |
| Promotions | The named XPath expressions that lift values out of the payload. See Promotions below. |
The list view follows the platform's Selected Application behavior - with an Application selected, the list filters to it and the Application column is hidden; with no selection, the list spans every Application you have access to and the column is shown. Creating a new message type uses the same flow: with an Application selected, the form opens with that Application preemptively chosen; without one, the form exposes an Application picker.
Format declares the shape the payload is expected to take. It is primarily a hint - the runtime does not parse the payload simply because a Format is set - but it gates two things that do matter: which schema type can be associated with the message type, and whether Promotions can be defined.
| Format | Schema | Promotions |
|---|---|---|
| XML | Pair with an XSD schema. | Supported - XPath against the XML payload. |
| JSON | Pair with a JSON schema. | Supported - XPath against the JSON payload. |
| CSV | No direct schema. Validate by disassembling to XML or JSON first. | Not supported directly. Disassemble to XML or JSON if you need promoted values. |
| TXT | Same as CSV - flat-file, no direct schema. | Not supported directly. Same disassembly path applies. |
A Promotion lifts a value out of the payload and gives it a name, so any downstream expression can reach it with {{Promoted.name}} instead of re-parsing the message. Each promotion is a pair: a name you choose, and an XPath expression the runtime evaluates against the payload at the moment the message enters the bus.
Unlike BizTalk's distinguished/promoted property pair - which limits promoted properties to scalar values and forbids them from referencing repeating nodes - an Art2link promotion is one mechanism that handles every shape an XPath can return:
| Resolves to | XPath returns | Example expression | Reference |
|---|---|---|---|
| Scalar | A single text node or attribute | /Order/CustomerId | {{Promoted.CustomerId}} |
| List | A node-set with multiple matches | /Order/Lines/Line/SKU | {{Promoted.SKUs}} |
| Sub-tree | A single inner element with its children | /Order/ShipTo | {{Promoted.ShipTo}} |
| Whole message | The document root | / | {{Promoted.WholeMessage}} |
A promotion that resolves to a list or sub-tree is a real value you can pass to a map, iterate over in a custom function, or wrap inside another payload - not just a flat string. A whole-message promotion is the canonical way to forward or wrap an inbound payload, for instance embedding the original message inside an envelope produced by an outbound map.
{{Promoted.CustomerId}} against the type the current message carries.Anywhere a string can be typed in the platform - subscription expressions, map bindings, custom pipeline component property values, custom function arguments - you can reference message types, their promotions, and application variables with double-curly-brace tokens. The exception is naming an object itself: the Name field on a message type, port, schema, etc. is a literal, never an expression.
| Token | Resolves to |
|---|---|
{{Message.MessageType}} | The Name of the message type the current message carries. Useful in subscription expressions and any other context that needs to branch by type. |
{{Promoted.PromotionName}} | The value of the named promotion as evaluated against the current message's payload. Resolves to a scalar, list, sub-tree, or the whole message depending on how the promotion's XPath was defined. |
{{Variable.VariableName}} | The current value of the named application variable. Application-scoped (not bound to a message), resolved by the same expression engine - mix freely with the two tokens above. |
A subscription expression that picks up only invoices coming through the bus, for example, looks like this:
{{Message.MessageType}} == "Invoice"
And a subscription that narrows further by promoted property:
{{Message.MessageType}} == "Invoice" && {{Promoted.Currency}} == "USD"
Subscription mechanics - how the bus matches messages to send ports, the full expression grammar, and the role of promoted properties in routing - are documented in the Subscriptions and Message Types section of the Ports article.
Three things happen at runtime that depend on the message type:
| Stage | What happens |
|---|---|
| Type assignment | The inbound flow tags the message with a type. Once tagged, the type stays with the message for the rest of its journey. |
| Promotion evaluation | For XML and JSON message types, every promotion's XPath is evaluated against the payload as the message enters the bus. The results are exposed under Promoted.* for the rest of the flow. |
| Schema validation | If the message type has a schema associated, the payload is validated against it. A validation failure marks the message as errored and stops it from reaching its subscribers. |
None of these are conditional on the others. A message type with no schema and no promotions is still a valid type - the runtime tags the message, matches subscriptions on {{Message.MessageType}}, and lets the message flow.
A schema in Art2link ESB is an optional structural contract that may be associated with a message type at design time. The association lives on the message type, not on a port, so once associated, every message of that type is subject to the same validation regardless of which port it arrived on. The schema's type must match the message type's Format (XSD pairs with XML, JSON Schema pairs with JSON), and the absence of an associated schema simply means no validation runs.