0

I'm building out a simple C# application that integrates with a SOAP web service. I add the service reference to the appropriate WSDL and everything works out fine so far.

Occasionally, the server's firewall will respond with a 503 error before the request gets a chance to hit the web service. That 503 error also contains some HTML with an ID number (which changes each time) that I want to capture.

If I catch the exception, it doesn't give me the full message - just the re-formatted basic exception that says the server is too busy.

I tried the message inspectors suggestion from this post: Intercept SOAP messages from and to a web service at the client

...and it gives me the outbound request, but it never hits the AfterReceiveReply call, so the response isn't captured.

I've also tried subscribing to all of the channel's major events (Faulted, Opening, Opened, UnknownMessageReceived, etc), and I've tried inspecting the channel when I catch the exception, but nothing seems to work.

Any thoughts or suggestions?

Community
  • 1
  • 1
jhilgeman
  • 1,543
  • 10
  • 27

3 Answers3

1

Why not just run fiddler on the machine your soap client is running on and intercept and inspect the traffic that way?

Justin Dearing
  • 14,270
  • 22
  • 88
  • 161
  • I am doing that today, but this application will be used by other non-technical people who will be unable to run Fiddler. I need the application to be able to handle this. – jhilgeman Nov 26 '13 at 19:09
  • In my expeience getting people to install and run fiddler during troubleshooting is not particulary difficult. Also, replaying with fiddler after massaging the data speeds up troubleshooting. – Justin Dearing Nov 26 '13 at 20:32
  • In this particular case, though, the point is to programmatically capture the ID when the error happens and log it somewhere. I appreciate the suggestion to use Fiddler, but it's just not the right answer for this specific situation. I need the .NET app to be able to see the raw content of the 503 error message so the app can handle it automatically and properly. – jhilgeman Nov 26 '13 at 20:39
1

Turn on WCF Tracing. In particular, Message Logging.

John Saunders
  • 160,644
  • 26
  • 247
  • 397
  • I'm trying to figure out how to enable message logging via runtime code instead of via the .config file. This application ends up being a plugin for a larger application, and when installed and distributed, only the DLL goes out. I'm defining a new endpoint, binding (BasicHttpBinding), and client at runtime. Now I'm trying to piece things together, but any help would be very welcome. Thanks! – jhilgeman Nov 26 '13 at 19:44
  • 1
    I turned on the logging in the config file for testing purposes and I'm not seeing the actual raw content of the 503 error: `System.ServiceModel.ServerTooBusyException: The HTTP service located at https:///503.php is unavailable. This could be because the service is too busy or because no endpoint was found listening at the specified address. Please ensure that the address is correct and try accessing the service again later. ---> System.Net.WebException: The remote server returned an error: (503) Server Unavailable. at System.Net.HttpWebRequest.GetResponse()` – jhilgeman Nov 26 '13 at 20:49
0

  1. It seems like disabling SOAPProcessing in the .config file may be a step in this direction, but I was unable to figure out how to enable this setting via code (and I cannot use a .config file in my final application because this is a plugin and the parent app's .config file is dynamically generated each launch).

  2. I was able to work around this somewhat. In my situation, I had separate dev and production servers. The 503s errors were happening mostly on the production server (likely due to the firewall being sensitive about a different hostname in the API requests), so I ended up with a solution that duplicated the API requests and sent them over to the production server.

(This was okay, because the production server was not configured with anything that would be affected by any API requests that made it through the firewall. The requests would just be considered invalid.)

I did this by using message inspectors to generate the last outgoing request. Then for each outgoing request, I generated a new WebBrowser control, set the proper headers (SOAPAction and all that), re-injected the security credentials (the message inspector stripped them out at runtime), and then posted the request to the production server with that WebBrowser control. The WebBrowser instance's DocumentCompleted event let me dump the result and search for the ticket ID when appropriate.

Not exactly glamorous, but it works well.

jhilgeman
  • 1,543
  • 10
  • 27