How do I get the SOAP response when there was an exception?

I made a call to a third party web service and get back an ESOAPHTTPException with a message in this format:

Cryptic message here - URL: http://webserviceurl - SOAPAction: performWithArgList

Now the support personnel for this web service has asked for the full SOAP response. Normally, I would attach an event handler to T开发者_Go百科HTTPRIO.OnAfterExecute and simply store the content of the stream I receive as parameter.

But since Delphi raises the exception, that event handler doesn't execute. I understand that the exception may in fact mean that the service had failed in some catastrophic way, but there should still be some kind of response (not a timeout error).

Is there some other method I can use to trap the response before Delphi turns it into an exception?

---

For an ERemotableException-based exception you'd want to look at the OnAfterExecute event as it represents a fault sent back by the Service... but for ESOAPHTTPException (your case) you'll want to handle the OnWinInetError event ( http://docwiki.embarcadero.com/VCL/en/SOAPHTTPTrans.THTTPReqResp.OnWinInetError).

D2010 introduced a bug in the SOAP HTTP handling. The typical symptom is that it would miss HTTP failures (such as when the Server is busy). So maybe that's not the issue you're running into but without knowing the exact error code or message you're seeing, one cannot tell. You can find more details here: https://forums.embarcadero.com/message.jspa?messageID=304898&tstart=0

For example, if you're getting the error about 'Handle is in the wrong state', the issue mentioned above is the culprit. It means that the 'Send' failed but the runtime happily proceeded to read a response. You can find out more about that one from this thread: https://forums.embarcadero.com/message.jspa?messageID=307048.

So you should handle OnWinInetError and grab the error code (LastError param). That's probably key to understanding the failure.

Cheers,

Bruneau

---

Yes, you can use the RIO event to examine the response before it is deserialized.

OnAfterExecute

You'll get the response as a stream, which you can convert to a string. Then you can examine for bad things like exceptions, beign totally empty, or starting with '', which usually (in my case) indicates that the service isn't up.

---

I would open the source for SOAPHTTPTrans and put a break point inside THTTPReqResp.Check(), just inside the "if error". When you hit the breakpoint, you'll have more of an idea what's wrong. Look at the call stack to see how you got here. It's probably something going wrong with your reqest being created and sent. If it's during the send, then it's likely not ever going out on the network so you won't see it with WireShark, Fiddler, or SoapUI.

IMO, functions like Check() should have an extra parameter for CallerLocation, so that instead of calling this: Check(not Assigned(Request), False); you'd call this: Check(not Assigned(Request), False, 'THTTPReqResp.SendGet'); and Check would append CallerLocation to the error message, and you'd know (a lot) more about what's going on.