There is no sample for this, but if I get enough requests (say five or so) I'll create one and post it.
I decided to whip up a quick prototype of FailedMessage subscription in BizTalk 2006 and I ended up hitting a couple of bumps in the road on my first shot. I'm the kind that does not stop and ask for directions, nor do I take the time to look at samples. I try to do it on my own, and failing that, I'll hit the blogs. All of that with a couple of trial and error sessions produced the following notes that I will use when trying this again:
Generating a FailedMessage
- Generating a failed message is easy. Just submit a schema type that you are not looking for in any of your artifacts, or just unenlist the subscribers.
- Be sure to enable FailedMessageRouting on the port that is Receiving/Sending the erroreous message
When Using A SendPort subscriber to the FailedMessage
- Just create a send port and Set the filter criteria to ErrorReport.ErrorType == FailedMessage (do NOT put quotes around the failedmessage string)
When Using an Orchestration subscriber to the FailedMessage
- Create a receive port that is Direct Binding (the “will be defined by filter expressions“ one)
- Have your activating receive shape with the ErrorReport.ErrorType == “FailedMessage” (put quotes around the failedmessage string)
- Your receive message type should just be Xmldocument
Some Insights
- There are a handful of other ErrorReport fields that will help you narrow your subscription criteria if you wish I like the MessageType and ReceivePortName
- If your subscription to the FailedMessages is messed up, you will see TWO reports of failed message routing per message that you submit. I can only assume that this is because the attempt to route the failedMessage also fails. If you want to explore this Disable/Enable FailedMessage routing on the port in question and see if it affects the number of reports you see.
- This is all about error handling so you have to assume that some pretty significant things are allready wrong. Depending on the stage at which you get the exception that causes the failedMessage, not all of the ErrorReport feilds will be helpful. For instance, if the failure occurrs during the Xml[Dis]Assembly you can expect that the ErrorReport.MessageType will not be available.
Corollaries
- This errorRouting mechanism also has the usefull behaviour of suppressing suspended messaging instances. I had a Solicit-Response call to an unreliable webservice [aren't they all], that would fail periodically. When it did fail it would suspend the orch and the message instance. When I resumed them, it would send a dup message (on from orch and one from message instance). I'm sure there's a better way to solve this one (but I don't stop for directions remember) so we enabled ErrorRouting on the send port. The consequence of this was that, on failures, only the orchestration was suspended. Now when I resume, I do not get duplicate messages and I do not have to remember to terminate the message instances.
By the way, I fiddled with the SuspendAsNonResumable on this and it never seemd to work the way that the help file described. There was a lot of sketchy behavior surrounding the resuming of a failed web call... but that can be another post.