The dead-letter channel is how Art2link honours fail loud, never drop. Three kinds of message end up here: one that no send port subscribes to, one whose send port has exhausted retries against a dead endpoint, and one rejected at the edge by validation as a poison message.

What makes it a channel and not a graveyard is that the messages are intact and recoverable. After you fix the bad map, register the missing subscription, or bring the endpoint back, the dead-lettered message can be re-driven and processed as if nothing went wrong.

Art2link gives you two ways to realise this channel. The first is built in and needs no wiring. A run that cannot proceed (an exhausted send port, a message no port subscribes to, a rejection at the edge) is held in the Suspended state: paused with its payload intact and listed in tracking, where it waits on an operator. From there you either Resume it, re-driving the held run once the cause is fixed, or Terminate it to discard it. This mirrors the suspended-message model BizTalk operators will recognise: nothing moves until a person decides, and nothing is lost while it waits.

The second realisation turns failures into first-class traffic on the bus rather than parked runs, for when you want an automated reaction instead of a manual one. Enable the failing port’s exception handling with an exception message type, say OrderSendFailed; on error the in-flight message is re-published under that type, payload intact, and the run is recorded as an Exception rather than Suspended. A dedicated dead-letter send port subscribes to that type and parks the message where it can be inspected and replayed:

{{Message.MessageType}} == "OrderSendFailed"

Either way nothing is dropped: a failure is either held for an operator in Suspended or re-published as its own visible traffic on the bus, never left to disappear.