Schemas
An optional structural contract for messages, used at runtime to validate that a payload matches its declared message type.
Art2link ESB supports XSD for XML payloads and JSON Schema for JSON payloads. A schema does one job and only one job: when a message arrives carrying a message type that has an associated schema, the runtime validates the payload against that schema.
Schemas are mandatory in BizTalk, every message type is, in effect, a schema. In Art2link ESB they are deliberately optional: message types stand on their own, and schemas are an additive validation layer you opt into where you need it.
If a message type has no schema associated with it, no validation runs and the payload flows through unchanged. There is no implicit fallback, no auto-detection, no warning, the absence of a schema simply means the runtime is not asked to check anything structurally.
Routing a message to its subscribers does not depend on a schema. Type assignment, promotion evaluation, and routing fire on every message; the schema, if attached, just adds a structural check between the two. Without one, the runtime simply does not invoke that check, nothing else about the flow changes.
{{Promoted.MessageType.Name}} simply get nothing. See Promotions in the message-types article for the full shape rules.Schemas are scoped to an Application. From the application menu, the Schemas list shows every schema you have defined. Each entry has just three fields:
| Field | Purpose |
|---|---|
| Name | How the schema is referenced when associating it with a message type. |
| Type | XSD or JSON, must match the format of the message type the schema will be associated with. |
| Code | The schema document itself, XSD or JSON Schema source, pasted in. |
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 schema uses the same flow: with an Application selected, the form opens with that Application preemptively chosen; without one, the form exposes an Application picker.
Two schema languages are supported, each paired one-for-one with a message format. A message type's Format splits the whole list into two camps: XML and JSON, which carry a schema directly, and every other Format, which has to be disassembled to XML or JSON first. Formats get added to the list over time, and a new one lands in the second camp unless it is XML or JSON.
The two solid pairings are exclusive: an XSD schema can only be associated with an XML message type, and a JSON Schema can only be associated with a JSON message type. The UI prevents mismatched bindings. Every other Format sits in the second camp and cannot carry a schema directly, whether it is delimited (CSV, TAB), positional (POS), an interchange standard (EDI, HL7, SWIFT, NCPDP), plain text (TXT), or binary (BIN). See Validating other formats below for the disassembly pattern.
A schema is touched at one design-time moment and however many runtime moments the message type happens to be instantiated:
| Moment | What happens |
|---|---|
| Design time | When you define a message type, you may optionally associate a schema with it. The schema's Type must match the message type's Format. If you skip this step, the message type has no schema attached and nothing changes downstream. |
| Runtime | Every time the message type is instantiated, see When a message type is instantiated, the runtime validates the current payload against the associated schema. If no schema is associated, validation is skipped and the message flows through unchanged. |
The association is made on the message type, not on the schema and not on a port. Once associated, every message of that type, regardless of which port it arrived on, is subject to the same validation.
Schema validation fires only after a message type gets assigned to a payload, and only if the resulting type carries a schema. Type assignment happens at a small, well-defined set of events inside receive and send ports; outside those events, schemas never run.
The flow that connects these events, adapters, pipeline stages, subscriptions, bus topology, is documented in Ports. The matrix above is the index of where in any port type assignment can occur, and therefore where schema validation has a chance to run.
At each moment, schema validation is the third of three runtime stages, type assignment, promotion evaluation, and (if a schema is associated) schema validation. See When the runtime touches a message type for the full sequence.
Validation has two outcomes, conforms or doesn't, and the failure path is terminal, not transient.
The message is marked errored, not suspended. Suspension implies a transient failure that retry can resolve; schema validation is deterministic, so resuming the same payload against the same schema would just fail the same way.
Schemas only validate XML or JSON. A payload in every other Format, an EDI or HL7 interchange, a positional record set, a CSV or tab-delimited extract, a binary blob, has to be brought into one of those two shapes before a schema can apply. The pattern is a four-link chain:
The disassembler is a normal pipeline component, the same C# class you write to handle any other inbound transformation. EDI is the canonical example: the EDI Format covers X12 and EDIFACT, and those interchanges plus most organization-specific variants are well documented, so a parser can be written from the spec without any special tooling. Whatever the component emits is a regular XML or JSON message from that point on; from the schema's point of view, the original payload never existed.
That is the whole job
A schema is one form, three fields, and a deterministic runtime check that fires wherever its message type is instantiated. Optional, format-matched, and out of the way until something does not conform.