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. There is no schema-driven routing, no schema-driven mapping, no field discovery - schemas are validators, nothing else.

Because schemas are optional, you can run an entire integration without ever defining one. They only enter the picture when you decide a particular message type warrants a structural check.

Design choice

Optional by design

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.

When to add one. A schema is worth defining when an upstream system can drift, when you want a hard contract with a partner, or when you want a fast structural rejection before the message is mapped or routed. For internal, fully-controlled flows, doing without is perfectly reasonable.

Reference

Where schemas live

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.

Supported formats

XSD and JSON Schema

Two schema languages are supported, each paired one-for-one with a message format:

Schema type	Validates
XSD	XML message payloads.
JSON	JSON message payloads.

Only XML and JSON messages can be validated directly. Anything else - flat files, fixed-width records, EDI, CSV - has to be turned into XML or JSON first; see Validating other formats below.

Schema and message type must agree. An XSD schema can only be associated with an XML message type; a JSON Schema can only be associated with a JSON message type. The UI prevents mismatched pairings.

Lifecycle

Design time vs. runtime

Schemas are touched at two distinct moments - and only those two:

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	When a message identified as that message type is processed, the runtime validates the payload against the associated schema. If no schema is associated, the runtime skips validation 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.

Behaviour

What happens on validation failure

If the payload does not match the schema, the message is marked as errored and processing stops. It is not placed in suspended state - suspension implies a transient failure that retry can resolve, and schema validation is deterministic. Resuming the same payload against the same schema would just fail the same way.

⚠️

Recovering from a validation failure means fixing upstream, not retrying. Either correct the payload at the source, relax the schema, or remove the schema association if the structural check is no longer wanted. There is no in-place retry that will rescue a structurally invalid message.

Pattern

Validating flat files and other formats

Schemas only validate XML or JSON. Anything else - EDI, fixed-width, CSV, custom binary - has to be brought into one of those two shapes before a schema can apply. The pattern is straightforward:

1. Build a custom pipeline component that knows how to disassemble the format. EDI is the canonical example: standards like X12 and EDIFACT are well-documented, as are most organization-specific variants, so a parser can be written from the spec without any special tooling.

2. Have the component emit XML or JSON that represents the disassembled record.

3. Define a message type for that disassembled shape and, if you want validation, associate an XSD or JSON Schema with it.

From the schema's point of view, the original flat file never existed - it sees only the XML or JSON the disassembler produced.

Validation can also happen inside the disassembler. If your custom pipeline component already enforces the format's rules during parsing - required fields, value ranges, segment counts - that is a valid validation point too. A formal schema is one option, not the only one.

That is the whole job

A schema is one form, three fields, and a single runtime check. Optional, format-matched, and out of the way until something does not conform.