hi every body,
i am trying to send a soap message to a server url which is like https:/www…/// . using SOAPHTTP. but i get a error saying
soap error: Soap Request Failed
error message:SOAP-ENV:Client [ISS.0088.9134] Exception occurred while processing the body of the message [url]http://localhost:5555/soap/rpc[/url] com.wm.app.b2b.server.AccessException [ISS.0084.9004] Access Denied
but if i cahnge the server url from https/… to http:/ it works. i am stuck here.
can anybody tell me what i have to do. or how to send soap to https
com.wm.app.b2b.server.AccessException may be caused due to the https Authentication supplied(user/password)is not matching with that SSL user created by webservice provider.
Please contact the webservice provider or any Admin who can detect the reason for AccessDenied of particular hosted webservice and make sure HTTPS authentication is Accept or Denied for the client user.
Also do check the pub.client:soapHTTP service pipeline output header/lines,headerStatus,headerStatusMessage and soapStatus for capturing the ErrorDetails.
Actually this is not a client side problem,So probably you might have to contact hosted webservice provider and they can trace or analyze the logs which should give further information about this https error.
“Connection closed by remote host” indicates the client successfully attempted to connect the target location using https but the server rejected to give Access permission.
So i believe nothing to do any changes in client webMethods IS side.
Hi,
i think the problem is because of the certificates. since when i was using java erlier. i was asked for the Latest versionof JRE/JDK for connecting.( it didnt worked with the older version)
and i think the webMethods uses jre 1.3.0. so is there any way that i can update the JRE in the webMethods or can connect the webMethods to an External JDK/JRE. because externally i have java 1.4.2_06. and this is one that i used to connect and recommended by the server side too. because of certificate problems.
so can any body help me in canginh the java version or can i upgrade the certificates in the exsisting JRE.
It looks like you are trying to invoke a web service on your Integration Server by using pub.client:soapHTTP from a Flow service on the same server. I assume you are doing this for testing purposes.
To have IS listen for HTTPS requests (including Soap messages sent over HTTPS) you have to first define an HTTPS port using the IS Administrator.
You can optionally configure that port’s “Client Authentication” to request certificates, require certificates or “none” which simply requires Basic authentication (username and password).
If you configure your IS server’s HTTPS port to only require basic authentication, you will not need to provide any certificates and setting the “auth” parameters on your pub.client:soapHTTP service will be sufficient. If you are just doing some testing, that is what I would recommend.
The Integration Server Administration Guide discusses the way IS works with SSL-secured resources in either a client or a server role. In your case take a look at the section entitled “When the Integration Server Is an SSL Client” that starts on page 120 of the 6.1 version of this document.
If you need to present a specific client SSL certificate to the server that is hosting your web service, IS provides built-in services that you would need to call before invoking pub.client:soapHTTP. These services are covered in the Built-In Services guide (located in your \Developer\doc folder. See the “Security” section of this guide for information on the pub.security:* group of services.
To reiterate, for simple testing, configure your HTTPS port’s “Client Authentication” setting to “none”. Only if you need experience the brain damage of managing SSL certificates first hand should you set your port to require certificates.
I do not believe that use JDK 1.3 vs. 1.4 has anything to do with this issue in your case. webMethods 6.1 Windows installations ship with both 1.3 and 1.42 JVM’s. Switching between the two is accomplished by changing one line in the server.bat file. This takes a little more effort in 6.01 because you have to remove a couple of classes from Sun’s JCE package. These extra steps are covered in the release notes that Ray referred to earlier.
I am opening this thread again.We are doing a similar thing but in our case the authentication is not an issue.The .Net server on which the web service is residing does not return the SOAP Response back to WM server in case of HTTPS while the same service returns the correct SOAP response If invoked using HTTP.
The SOAP response returned in case of HTTPS only contains
“xml version=1.0 encoding=utf-?”.
Any suggestions on this?
Thanks
Puneet,
I’m assuming the input message to the .Net service works okay on the https but the response is what is getting messed up. Not really sure about this one since you are not getting error messages(you are not getting error messages, right?), but here is something to look at if you haven’t already. Check this Microsoft note and see if it applies to you, “[url=“http://support.microsoft.com/default.aspx?scid=kb”]Microsoft Support” .
Thanks for your response.
I have tried both TCP and proxy trace but it seems that they don’t
work well with HTTPS port 443.TCP Trace shows junk while proxy trace hangs!.Both work fine If I use HTTP.
But the issue remains that the soap response goes missing while using HTTPS protocol.The pub.soap.utils.getBody returns null.
I have tracked the IIS logs and the webservice is indeed getting invoked and performs the desired function, just that the response goes missing.The IIS logs shows that the more then 300 byes were sent back to the wm client.
The Microsoft site you have refered explains the issue If the .Net client invokes any service using SSL but in my case I am using WM client to invoke .Net webservice.
Is there anything else I amy be missing?
Puneet,
I didn’t think TCP Trace would show the ssl but it was worth a try, plus it is a good tool to have. I don’t really have any other suggestions other than if you haven’t already try turning up your log debug level to see if anything shows up. You can try and install the IIS servers public cert locally on the wb IS server to see if that helps with the decryption
Puneet,
i am not sure if you need this any more. if you are using IS 6.1, apply SP1 patch to it. you will get 2 more servicein parameters for soapHTTP call. Set loadas to ByteStreamArray. this should take care of your problem.
Puneet,
How did you resolve this issue. I am having exact same issue.
Mark,
Thanks for your response.
I have tried both TCP and proxy trace but it seems that they don’t
work well with HTTPS port 443.TCP Trace shows junk while proxy trace hangs!.Both work fine If I use HTTP.
But the issue remains that the soap response goes missing while using HTTPS protocol.The pub.soap.utils.getBody returns null.
I have tracked the IIS logs and the webservice is indeed getting invoked and performs the desired function, just that the response goes missing.The IIS logs shows that the more then 300 byes were sent back to the wm client.
The Microsoft site you have refered explains the issue If the .Net client invokes any service using SSL but in my case I am using WM client to invoke .Net webservice.
Is there anything else I amy be missing?
Puneet
Product
webMethods Integration Server
Version
6.1
Updates
IS_6-1_FP2
IS_6-1_SP1_Fix29
IS_6-1_SP1_Fix53
IS_6-1_SP1_Fix61
IS_6-1_SP1
Add a pub.flow:tracePipeline call after the soapHTTP call to your .Net-provided web service. That way you can see what is contained in soapResponseData immedately after the web service is invoked (you can also do this by tracing through your Flow). What HTTP response code is returned?
Hmmm. This rings a bell. I think it’s quite possible that your X509 Certs are not configured correctly. I don’t remember the details of our cert configuration problem, but the symptoms were exactly what you are seeing.
In order to improve your odds of getting a helpful reply from this all-volunteer forum, I suggest providing more details about what you are attempting to do. Asking wMUsers members to re-read the entire thread of an old post is probably not going to get you an answer anytime soon.