You are here: Integrating With CPQ Cloud > Web Services 2.0 and SOAP APIs > Calls to Oracle On Demand from Configuration with Web Services 2.0

Calls to Oracle On Demand from Configuration WITH Web Services 2.0


ClosedSetting up Calls to Oracle On Demand

  1. Prepare a session by locating _BM_USER_PARTNER_SESSION_ID on doing a partner login.
  2. 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.
  3. Build the SOAP request.
  4. 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.
  5. Open the file SampleSoapInput-WS 2.0.xml.
  6. Put this SOAP input into a POST request.
  7. In CPQ Cloud we would do this through URLDATABYPOST. "Stringify" the above SOAP input, and that forms second parameter to URLDATABYPOST.
  8. The first parameter is the URL. That would also be available from the WSDLs and along with the session id, should look something like:;jsession= 8d497390b14d3588fef9b6f.e3iRbuMa

  9. Using URLDATABYPOST we should have:

    responseXmlString = urldatabypost(url, soapInput, "Default Response on error");

  10. 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?


ClosedDebugging Errors

  1. Navigate to the Error logs. Here’s what we are most likely to see:

    …Could open Server returned HTTP response code: 400 for URL: https://secure-ausomxdia.crmondemand...on/object;jses...

  2. 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.
    1. Go to the Request Builder in Fiddler, add the required Url along with the session id, as explained earlier.
    2. Change the request type to a POST.
    3. In the post data pass the soapInput.
    4. Execute the request.
  3. First thing we notice, headers are required, we add the content type header and try again.
  4. 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”.
  5. Look back at SoapUI, and we notice that its header contains:

    SOAPAction: "document/urn:crmondemand/ws/account/10/2004:AccountQueryPage"

  6. 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");

    headerDict = dict("string");

    put(headerDict, "SOAPAction", "\"document/urn:crmondemand/ws/account/10/2004:AccountQueryPage\"");

    1. Don't forget to escape the double quotes (\") in the SOAPAction header.



Related Topics Link IconSee Also