Return to main navigation Page
Calls to Oracle On Demand from Configuration with Web Services 1.0
Setting up Calls to Oracle On Demand
- Prepare a session by locating _BM_USER_PARTNER_SESSION_ID on doing a partner login.
- Preparing the SOAP Request. Let's assume we
have the required WSDL files containing the definitions of the various
web services available. Secondly, let us assume we have the session Id.
Web Services 1.0 does NOT use Session ID authentication. To determine which version of Web Services you are using, see An Overview of SOAP APIs and Web Services 1.0.
- Build the SOAP request.
- Use a tool such as SoapUI for this. SoapUI
takes in the WSDL as input and generates the SOAP request for each API
call defined by the WSDL. All we have to do, is take this SOAP request,
change it to have the fields we require, and send it through a POST HTTP
request. Let us break this down.
- Open the file SampleSoapInput-WS 1.0.xml.
- Put this SOAP input into a POST request.
- In CPQ Cloud we would do this through
URLDATABYPOST. "Stringify" the above SOAP input, and that forms second
parameter to URLDATABYPOST.
- The first parameter is the URL. That would
also be available from the WSDLs and along with the session id, should
look something like:
- Using URLDATABYPOST we should have;
responseXmlString = urldatabypost(url, soapInput, "Default Response on error");
- CPQ Cloud makes a POST HTTP request passing
the soapInput in the body of the request. On getting a response, we
notice the default error message. OOPS! What just happened here? Thought
we had everything in place. We should have got a nice little XML
containing the data we requested for. SoapUI gives us exactly what we
need, then why not CPQ Cloud? What are we missing?
- Navigate to the Error logs. Here’s what we are most likely to see;
connection.java.io.IOException: Server returned HTTP response code: 400
for URL: https://secure-ausomxdia.crmondemand...on/object;jses...
- Debug using Firebug or Fiddler. I just like
the way Fiddler works, so lets go with that. Let us build out the entire
request using Fiddler, and see what the 400 actually refers to.
- Go to the Request Builder in Fiddler, add the required Url along with the session id, as explained earlier.
- Change the request type to a POST.
- In the post data pass the soapInput.
- Execute the request.
- First thing we notice, headers are required, we add the content type header and try again.
- When the response comes in, as expected, again
we see a 400 error. This time however, we can take a look at the
response XML. On investigating we find out that another piece of
information is missing in the header – “SOAPAction”.
- Look back at SoapUI, and we notice that it’s header contains:
- Now we come back to CPQ Cloud, and thankfully
we have a fourth parameter to URLDATABYPOST, a dictionary that can
contain custom headers. We add SOAPAction and Content-type to it. The
code should look something like:
headerDict = dict("string");
put(headerDict, "Content-Type", "text/xml; charset=utf-8");
put(headerDict, "SOAPAction", "\"document/urn:crmondemand/ws/account/10/2004:AccountQueryPage\"");
Don't forget to escape the double quotes (\") in the SOAPAction header.