Richard Seroter has a few good
recommendations here on how to diagnose the confusing “Internal SOAP Processing
Failure” message you get when a call to a WebService exposed from BizTalk fails. As
he mentions, it can be quite confusing and sometimes quite hard to get to the
root of the cause if you’re not familiar with the system.
Other recommendations I’d add to Richard’s list would include:
-
Make sure the URL specified in the receive location matches the one where the service
is actually deployed. An simple typo here can make your life miserable. - Make sure the receive location is enabled (it never hurts to mention it :-))
-
If the service is request/response, make sure the orchestration is not taking too
long to send the response message back and is not causing the service to fail with
a timeout. -
Make sure that you haven’t done any changes to the schemas used by the orchestration
and didn’t run the Web Service Publishing wizard again to generate the WebService
and the associated messaging. I’ve seen plenty of people having their exposed Web
Service failed because of a schema change that causes the incoming message not to
trigger the right subscription, or have it cause the orchestration to fail when it
tries to access a missing field.
Besides this, I always recommend developers that any orchestration that is going to
be exposed as a Web Service should have extremely strong error handling built-in,
hopefully to ensure it always returns a response message (either a real response or
a failure message). Otherwise, an unhandled exception will cause the orchestration
instance to be suspended which will cause the Web Service to timeout.