Consider the following scenario:

1. There is an adapter on a Receive Location, which submits a message in Format A into BizTalk.
2. The Pipeline configured on this Receive Location converts the message into Format B.
3. Assume that there is no map configured on the Receive Port.
4. The “Route Failed Messages” option is enabled on the Receive Port.
5. There is an orchestration (or Send Port) set up which subscribes to the Error Reports (i.e., the failed messages which are routed due to the “Route Failed Messages” feature) generated by this Receive Port 1.

Problem: When a message is received on this Receive Location, and there are no subscribers for it, the expectation is that the message in Format B will be received by the error-handling orchestration (or Send Port). However, in some scenarios (depending on the pipeline, pipeline configuration, etc), the message received by the error-handling orchestration (or Send Port) is in Format A. How come?

Here’s what is most probably happening:

1. Adapter submits a message in Format A.
2. The pipeline executes, and the message is converted to Format B.
3. The Messaging Engine attempts to publish the message, but finds that there are no subscribers for this message. It thus returns an error back to the Adapter.
4. The Adapter attempts to suspend the message. NOTE – here, it attempts to suspend the message which it knows about (which it received from the back-end) – this message is in Format A.
5. The Messaging Engine sees this:
   1. someone (the adapter in this case) is suspending a message (message in Format A, in this case)
   2. “Route Failed Messages” is enabled on the port
6. The Messaging Engine, instead of suspending, decides to “route” an Error Report corresponding to the message being suspended. This is the message in Format A, in this case.
7. The error-handling orchestration (or send port) thus ended up receiving the message in Format A.

Question: How do you ensure that the message received by the error-handling orchestration (or send port) is in Format B?

Answer: The output message from the pipeline must have the context property “SuspendMessageOnRoutingFailure” present, with a value of true (boolean).

How does that work? Well, it changes the sequence above to be as follows:

1. Adapter submits a message in Format A.
2. The pipeline executes, and the message is converted to Format B.
3. The Messaging Engine attempts to publish the message, but finds that there are no subscribers for this message.
4. The Messaging Engine sees the “SuspendMessageOnRoutingFailure” message context property is set to true, and instead of returning an error back to the Adapter, attempts to suspend the message. NOTE that this message is in Format B.
5. At the same time, the Messaging Engine also sees this:
   1. someone (the Messaging Engine itself, in this case) is suspending a message (message in Format B)
   2. “Route Failed Messages” is enabled on the port
6. The Messaging Engine, instead of suspending, decides to “route” an Error Report corresponding to the message being suspended. This is the message in Format B.
7. The error-handling orchestration (or send port) now receives the message in Format B.

The out-of-box XML Disassembler component, has an option named “Recoverable Interchange”. When this option is set to true, the XML Disassembler internally translates this to mean “SuspendMessageOnRoutingFailure”=true, and sets this context property to the message.