Home > Blogs > matt

Failed Message Routing and Failed Orchestration Routing in BizTalk 2006

Posted: Wednesday, November 01, 2006 9:51 PM by matt
Filed under:

This post discusses Failed Message Routing and Failed Orchestration Routing in BizTalk 2006

Failed Message Routing

Failed Message Routing is a new feature of BizTalk 2006.
You can read about it here: Using Failed Message Routing

Below is an excerpt from the above help topic:

What Does Failed Message Routing Consist Of?

When failed message routing is enabled, BizTalk Server does not suspend the message—it routes the message instead. Failed message routing can be enabled on both receive and send ports, with the following results:
If failed message routing is enabled on a receive port and a message fails in the receive pipeline or in routing, a failed message is generated. In the case where an error occurs in or before the disassembly phase, the error message is a clone of the original interchange. If failed message routing is enabled on a send port and the message fails in the send pipeline, a failed message is generated. When a failed message is generated, BizTalk Server promotes error-report-related message context properties and demotes regular message context properties before publishing the failed message. Compare this to the default behavior when failed message routing is not enabled: Messages that fail are suspended.

There is much more information in the above article. I would highly recommend reading it. One of the properties promoted on a failed message is:

ErrorReport.ErrorMessage = "FailedMessage"

You can then subscribe to a failed message using a Send Port or Orchestration by filtering on the above property.

Failed Orchestrations Routing

There is no such thing. If an orchestration suspends, the orchestration and its contained messages will become suspended. If you have an orchestration or send port with a filter such as:
ErrorReport.ErrorMessage = "FailedMessage"

It will not subscribe to the failed orchestration. No failed message is automatically generated that can be subscribed to on orchestration failure. But, if you have set up a subscriber that is set up for Failed Message Routing and would like a message generated by the Failed Orchestration to be routed to the same subscriber, you can do the below:

1) As below, add a scope shape and exception block in the orchestration to catch exceptions in the orchestration:

2) In the exception block construct a new message in the orchestration. While constructing the new message, promote the following property:

msgError(ErrorReport.ErrorType) = "FailedMessage";

See below for an example:

3) As below, use the orchestration view to create the following Correlation Type.

4) As below, use the orchestration view to create a Correlation Set that derives from the Correlation Type.

5) As below add a Send shape to send out the newly constructed message. For the properties of the Send Shape, initialize the correlation set from 4).

6) As below, link the send shape to a Logical Send port in the orchestration that will do a direct send into the messagebox.

7) The ErrorReport.ErrorType is now promoted on the error message and you can now subscribe to it, using a filter condition as:

ErrorReport.ErrorType = FailedMessage
(if using a send port)
Or:
ErrorReport.ErrorType = "FailedMessage"
(For a Receive Shape in an orchestration.)

Note: You can also promote your own custom context property as described Here
There is an example that you can download Here. Read the Readme before installing.

Comments

  • matt November 2, 2006 4:09 PM

    Matt, it's always nice to read you, thanks. A little question regarding failed message routing :
    Is using it or not has any impact on the adapter behavior (ex. for the file adapter, if there is an error in the pipeline, does the file remain on disk or not) ?

  • matt November 2, 2006 5:09 PM

    Hi Christian,
    Good to hear from you. To answer your question. If you check off "Enable Routing for Failed Messages" in your Receive Port, and you are using the File Adapter to pick up the message, and the message fails in the pipeline, the file will still be deleted from disk by the adapter. ie the adpater will delete the message from the folder whether or not "Enable Routing for Failed Messages" is enabled or not

  • chrisromp.com January 11, 2007 12:37 PM

    Here's a great blog post at Matt Meleski's blog regarding failed message routing and failed orchestration

  • Working Title May 9, 2007 5:19 PM

    Here's a great blog post at Matt Meleski's blog regarding failed message routing and failed orchestration

  • BizTalk Newbie November 30, 2007 12:15 AM

    Matt,

    Thanks for the detailed explanation. I am trying to correlate it to one of the scenario I am facing. I am new to BizTalk,so I would want some advice on a better design. To make my scenario simple I will skip a lot.

    I am building an Orchestration which is supposed to send messages to 4 Web services in Parallel (but the parallel activity is not taking place,it goes in a sequential manner). I use a Send and Receive Port for sending the messages to the WS. I take the response and do DB inserts. The issue I face is when the WS goes down. For ex: WS2 is down, BizTalk Orch has sent a message to WS1 and it gets suspended while trying to send it to WS2. I can see the Orchestration and Send Port suspended instances. Later when I resume both, the send port action completes successfully but the Orchestration suspendes with an error like - "Orch will suspend or re throw the same exception when resumed". I want to know how can i use Error based routing to continue this Orchestration to complete its action of sending data to WS3 and WS4 and then completes successfully. And is it a common issue, when we use Req-Resp SOAP functionality?

    Any advice is really appreciated.

    Thanks

    Newbie

  • matt November 30, 2007 7:46 AM

    When thing you could do is:

    1) Create a Retry pattern in your orchestration.

    For example, put a loop shape in your orchestration to retry the Soap Call.

    2) In the loop shape use a Scope shape with an exception block, to catch soap exceptions. You can have a configuration value to loop around and retry the Soap Message (via the send/receive port) a number of times. If it fails

    that number of times, then suspend the orchestration using a suspend shape and then send out an email or something to alert that the orchestration has to be resumed.

    3) For the Soap send port suspended messages

    (Mark this send port for -> Failed message routing). Then create a subscriber (ie an orchestration, that will just eat the messages and do nothing with them. i.e. the message to be retried will be in the orchestration.

  • Ibrahim Hamouda April 7, 2008 6:11 AM

    Matt

    I'm trying to use your sample as a guide.

    Installing your sample, everything work.

    In my own application, running on Biztalk 2006 R2, when a message fails in the orchestration it goes to the exception block ok.

    But it gets suspended with an error at the exception send shape saying that XML Document is not marked as serializable.

    Any ideas?

  • giri May 1, 2008 12:23 PM

    Hi I am new to this blog.

    i have on eproblem regarding Failed Message routing.

    the secnario is , Biztalk will recevie a flat file through file adapter, if there is any pasring erros are occured i neeed to send a mail with Receive Filename.

    can u please helop me out regarding thi s issue.

    thanks.

  • matt May 1, 2008 1:05 PM

    If your Receive Port has the "Enabled Routing For Failed Messages" checked off, then you can create an orchestration that will subscribe to these messages. Create an orchestration with a "Direct" Logical Receive Port. For the Receive Shape in your orc, set a filter condition like:

    ErrorReport.ErrorType == "FailedMessage"

    In an expression shape to get at the FileName use something like below:

    System.Diagnostics.Trace.WriteLine("The Receivefilename is " + Message_1(FILE.ReceivedFileName));

    Where Message_1 is the incoming failed message.

    You can set the ReceviedFileName and then send out the email message from the same orchestration.

  • giri May 1, 2008 2:25 PM

    Thanks matt,

    it is working now

    thanks a lot

Leave a Comment

(required) 
(optional)
(required) 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS