Tuesday, February 03, 2009

Handling Fault Message

I think I have a at least average intelligense, but today I could not figure out have to handle Fault Message in a BizTalk orchestration.

I followed all common samples and added a Scope with Catch Blocks, one for the service Fault Message and one for ordinary Soap Exceptions, but it did not work. I got: "Received unexpected message type 'http://schemas.xmlsoap.org/soap/envelope/#Fault' does not match expected type 'http://x.y#z'" all the time no mather what I tried.

Now it seems to be a vocabulary problem. I googled on handling "Fault Message", but did not find any solution until I stumbled on something like "Typed Fault Contract", then there was information about configuring the send port correctly.

In the send port for an WCF-adapter you can specify where the body of the response message starts. If you expect to receive either your preferred message or a Fault Message you use a XPath expression. See message tab on the properties for the WCF-adapter.



  1. Check Path
  2. Add an OR-expression for your possible response messages (/*[local-name()='Fault']/*[local-name()='detail']/* "insert pipe character here" /*[local-name()='MyResponseMessageRootNodeName'] for example, see explanation below)
  3. Check that Node encoding is set to Xml
  4. Check "Propagate fault message", is checked default

The XPath means:

XPath to Soap fault (can be "Detail", if one can trust other samples, but for me it was "detail")
/*[local-name()='Fault']/*[local-name()='detail']/*

XPath OR
"pipe" (could not enter the pipe character here for some reason)

XPath to your expected Fault Contract/Message
/*[local-name()='MyResponseFaultMessageRootNodeName']

3 comments:

Bluebucket said...

Hi Martin,

If you use your port for more operations than just one, you can use the more generic expression:

/*[local-name()='Fault']/*[local-name()='Detail' or local-name()='detail']/* [pipe] /*[not(local-name()='Fault')]

The added "or" in the first part of the xpath expression is to allow both SOAP 1.1 and SOAP 1.2 faults to work.

Also, strictly speaking, the [pipe] in xpath is a union operator.

Anonymous said...

Thanks for the generic expression.
Works like a charm.

Anonymous said...

great! you saved my time! i wasted already one hole day just because of "D" vs. "d" in the xpath below which was causing issue in my Biztalk applicaiton.


After seeing your blog i changed the "D" to "d" in the below xpath and it worked! thanks a ton.


*[local-name()='Fault']/*[local-name()='Detail' or local-name()='detail']
-Sri