I have an orchestration that both consumes a webservice and exposes a
webservice via the WSE webservice publishing wizard.  Based on the response
from the service I am consuming I may need to issue a SOAP fault.  I followe
d
the instructions for catching soap exceptions in an orchestration in the
informative article
(http://msdn.microsoft.com/library/d...abc4dd1d1fa.asp)
by Brian Loesgen.  After adding the scope and catching the exception, I
created some fault details, logged the fault details to the event viewer, an
d
wired this message to the fault method of the solicit-response port.

When I test the service with a SOAPClient test harness, I do get a SOAP
exception as expected.  Unfortunately, I can't seem to access the details of
the soap fault that I added in the orchestration.  When I catch the soapfaul
t
in my test harness, I have access only to the soap fault object and the
details node is null.  Since a soap exception is thrown, I don't have access
to the response object so I can only interogate the soap exception object an
d
the details I added are no where to be found.

I have also tested having the consumed service throw the soap exception
after adding exception details instead of creating my own soap fault message
in the orchestration.  In this case the SOAPClient that consumes the Biztalk
Proxy gets the soap exception as expected, but the soap fault details are
once again missing.  Biztalk automatically logged this error to the event
viewer and I can see the fault details in the message that was logged.

Based on the posting I see with others using this feature I can't believe
this is a bug so there must be something wrong with how I am trying to unwra
p
the soap exception message to get to the details.

Does anyone have any advice on how to get to the fault details?

Thanks,
Scott

[ Post a follow-up to this message ]

Hi Scott

Please first check if ThrowDetailedError switch has been set to True in
web.config:

If an error occurs, the Web client receives a generic SoapException.

To debug your published Web service, you can add a switch to the Web.config
file to control the level of the exception details returned from the
published Web service.

The Web.config file contains an application setting switch,
ThrowDetailedError. False is the default setting for ThrowDetailedError. If
you change the setting to True, the server proxy returns inner exception
information to the Web client enabling you to debug the published Web
service.

The following XML code shows the ThrowDetailedError switch that appears in
the Web.config file under the <appSettings> node:

<appSettings>
<add key="ThrowDetailedError" value="False" />
<appSettings/>

Security  BizTalk Server does not return inner exception information to
the Web client by default since it may contain sensitive information, such
as application call stacks. After debugging, you should set the
ThrowDetailedError setting to False.

Best regards,

WenJun Zhang
Microsoft Online Partner Support

This posting is provided "AS IS" with no warranties, and confers no rights.

[ Post a follow-up to this message ]