Partager via

“Route Failed Messages” routes the wrong message – really?

  • Article

Consider the following scenario:

  1. You have 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. You have the “Route Failed Messages” option enabled on the Receive Port.
  5. You have set up an orchestration (or Send Port) 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, you expect that the message in Format B will be received by your error-handling orchestration (or Send Port). However, in some scenarios (depending on the pipeline, pipeline configuration, etc), you see that 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. Your error-handling orchestration (or send port) thus ended up receiving the message in Format A.

Question: What do you do if you want to have the message received by your error-handling orchestration (or send port) to be 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. Your 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.

Comments

  • Anonymous
    February 23, 2010
    This is super cool. It just shows the breadth of the product, still lot of things left for learning. I certainly didn't know about this feature SuspendMessageOnRoutingFailure. While browsing through the documentation I also noticed there is one more called SuspendMessageOnMappingFailure which work in failed map scenarios. Thanks for this information. Regards, Saraqvana