Return to main navigation Page
Debugging SOAP Responses WITH Web Services 2.0
This topic discusses Web Services 2.0. For information on Web Services 1.0, see
Web Services 1.0.
This article will give you some tips for debugging SOAP responses.
Check the Error logs. Here’s what we are most likely to see:
…Could open connection.java.io.IOException: Server
returned HTTP response code: 400 for URL:
- Let's review/verify the following:
- We used a valid session
- We built the SOAP input
- We prepared the URL
- We made a POST HTTP request.
- Use Firebug or Fiddler to debug the request. In this case, we're using Fiddler.
- Build out the entire request to see what the 400 actually refers to.
- Go to the Request Builder in Fiddle and add the required URL along with the session ID.
- Change the request type to POST.
- Pass the soapInput in the post data.
- Execute the request. The first thing you may notice is that headers are required.
- Add the content type header and try again. This time, look at the response XML and notice that you need to add the SOAPAction.
- Look at SoapUI and notice that it's header contains the following:
- SOAPAction: "document/urn:crmondemand/ws/account/10/2004:AccountQueryPage"
- Navigate back to CPQ Cloud.
- Add a fourth parameter to URLDATABYPOST, which will be a diction that can contain custom headers.
Add SOAPAction and Content-type to the parameter you just created. The script should resemble:
put(headDict, "Content-Type", "text/xml:charset=utf-8");
Don't forget to escape the double quotes (\") in the SOAPAction header.
SOAP requests must include "Agent" information.