I am invoking a web service at Siebel On Demand using a web service connector I created from their Account WSDL. I am getting a SOAP status of 1. The problem is, my SOAP Fault returned to my pipeline is incomplete. It looks like this:
<?xml version=“1.0” encoding="UTF-?>
I can view an admin page at SOD that shows the fault that was generated is:
Chris,
You may have already done this but have you used something like [url=“http://www.pocketsoap.com/tcpTrace”]http://www.pocketsoap.com/tcpTrace[/url] to verify that the soap message is actually making it back to the Integration Server? It will sit inbetween the IS server and SOD. It will show you the request message and the response message as it is on the wire.
By any chance are you using HTTPS to invoke your SOD web service? Is it possible that there is some type of SSL certificate warning message being returned?
I’ve seen a similar issue recently when we switched to HTTPS from HTTP. We’re still working to get to the specific certificate issue that might be causing the problem. We were using self-signed certs.
Did you install a security certificate on your IS? If so, is it self-signed? Sometimes, HTTPS servers return warnings about self-signed certs that would show up as pop-up dialogs in a browser, but might cause the behavior you are seeing in a soapHTTP call.
Chris,
You didn’t mention what version of the IS server you are running. There are some more issues, in addition to what Mark C is talking about, with SSL and the IS servers built-in soaphttp client. Mostly affecting versions 6.0.1 and 6.1. There are fixpaks available to fix. There are also some workarounds if you can’t apply the fixpaks for some reason.
Is the SOD server hosting the web service clustered or load balance?
Thanks for all the input. I submitted an SR with webMethods.
I am on 6.1 SP1. I applied IS_6-1_SP1_Fix55 and it didn’t make a difference.
I started writing a Java application to do the ws invoke. If I get the entire SOAP Fault back in my Java app, there is pretty good evidence the problem is in Integration Server.
A search on Advantage turned up some good soap/xml/wsdl related stuff in IS_6-1_SP1_Fix55 (also known as IS 6.1 SP1 Web Services XML Fix 6), but I did not see a specific reference to truncated soap responses over SSL for that one.
It looks like this issue may have been fixed in IS_6-1_SP1_Fix12 now included as part of IS_6-1_SP1_Fix34 (aka IS 6.1 SP1 Server Protocol Fix 4). However, the description is a bit unclear.
I also ran into this issue recently and have an open SR with Tech Services. We’ll apply these Fixes and retest.
I am doing a webex with webMethods tomorrow morning. I will let you know what happens. I found IS_6-1_SP1_Fix12 reference on Advantage earlier today. I think that’s the one that will fix it. I already tried Fix_55 with no luck.
We are getting close to doing user acceptance testing. My java service will suffice, but I really want to use a webMethods supported HTTP client. Fixing the problem with webMethods tech support has been very slow.
Mark Griffin said he uses the http client as a work-around. Do you send the payload in the http client as a stream, bytes, mime or string?
In my Java service, I am using Jakarta HTTP client. This part of the implementation is abstracted by the HTTPClient and PostMethod classes.
Applying fixes IS SP1 54, 55 and 61 addressed the issue we were having with truncated soap responses over HTTPS / SSL connections. I just noticed Rob’s post about the dependencies on higher numbered fixes and will update this post when I hear back from WM support.
Chris,
We map it in as string. We also had to set the http header SOAPAction and Content-Type. Works fine for us. We are hoping it is address in 6.5 since they fixed it in 6.0.1 and 6.1. But we have found so far that all things that were fixed in previous releases have not been carried over to 6.5.
Support replied that the dependency of IS SP1 Fix 54 on IS SP1 Fixes 55 and 61 is most likely due to a delay in releasing Fix 54 or on a subsequent change to Fix 54 that introduced the dependencies on 55 and 61. A little convoluted, I know, but the combined fixes addressed our issue with truncated soap responses.
MG,
I am able to use the http client for web services. I tested it out today. How are you building the SOAP envelope and SOAP body? Are you just concatenating strings, or are you using the createSOAPData, addBody services in WmPublic? If you are using createSOAPData, how do you transform the node to an xmlstring?
Chris,
We use the standard web services client generation from WSDL which include the createSOAPData, addBody etc. We then go in and modify the generated service. We add a header and then use soapDatatoString and then add in the Http client mapping the xmlstring to string of Http client, disabling the soapHttp. We get the response back via a byte object- bytetoString, xmlStringtoNode, xmlNodetoDocument.