Working With Rails

Try loading http://myip/mywebservice/services/Message?wsdl and look at what content you get returned. Compare it to http://mymachine:8080/mywebservice/services/Message?wsdl

I suspect the problem is in the web server configuration on myip.

Maybe try http://myip:8080/mywebservice/services/Message?wsdl

Another possibility, you say you are using a VPN. Maybe IE is set up to use a proxy server, and your VPN lets the proxy server address connect to port 80, but when you try from ruby you are making a direct connection to port 80 from your machine and the VPN disallows it.

oh man… I ran into this same issue, but now can’t remember what I did to solve it.

I seem to remember it had something to do with bad data being cached from the previous attempt…

Try adding .create_rpc_driver on the end of the remote call…

driver = SOAP::WSDLDriverFactory.new(wsdl_url).create_rpc_driver

Hello Jon and Tim.

Thanks for your replies.

Tim, I tried your suggestion with no positive results. The same error is generated.

Jon, when I can see the content of both web services with success. I don’t think the problem comes from the web services because I can see the WSDL and the error is generated by the code line driver = SOAP::WSDLDriverFactory.new(wsdl_url) (so, before i make the call to the web service).
I think the problem can be originated by the web server configuration of by the VPN configuration (but i didn’t found where yet)

Thanks
regards

soap4r gives more log messages if $DEBUG is true (i.e. run ruby -d) so you could try that.

I’ve just looked through some of my old SOAP code and I’ve done it with stub classes created using wsdl2ruby. Is that a possibility for your code, or do you need to dynamically parse a new wsdl at runtime?

Another debugging step, replace your failing line of code with this:

require 'uri'
require 'net/http'
r = Net::HTTP.get_response(URI.parse('http://myip/mywebservice/services/Message?wsdl'))
logger.debug "response code #{r.code}" 
logger.debug "response body: #{r.body}"

I tried to use your solution using net/http with both web services.

I remember that the application is running on a server.

With the web service running in my machine no error happens. The r.code result is 200 and the r.body result is an XML (the WSDL of my web service)

With the web service running on the other machine (which is on another network and we have to use a VPN to communicate with) the following happens: the r.code result is 302 and the r.body result is empty (nothing is logged).

Note: when I type both URL WSDL’s on IE or on mozilla firefox, I can see correctly the WSDL’s files.

The result means that the rails server cannot communicate with the other machine? Am I correct? do you know how to resolve this problem?

Thanks again.

Regards.

302 is a temporary redirect. Try logging the value of r[‘location’] to see where it is trying to redirect to.

It sounds like maybe your VPN is blocking direct http connections. Have a look in the proxy settings of your browsers to see if they have been configured to use a proxy server. The value of the location header might also give you a clue here – it might be redirecting you to a company VPN / Proxy logon page. Is there someone in your IT support department you could ask?

I Jon,

I am confused. I tried your suggestion, so I printed the r[‘location’].
The result is the following URL:
response location http://server_ip/mywebservice/services/Message/wsdl/Message.wsdl

The URL used is:
http://server_ip/mywebservice/services/Message?wsdl

I don’t know why is trying to redirect to this URL.

I will try to use the IT support to try to find out the problem.

Thank you.

regards

Hi Paulo,

What happens if you try the original code with the redirect URL?

factory_chgst = SOAP::WSDLDriverFactory.new("http://server_ip/mywebservice/services/Message/wsdl/Message.wsdl")

Also I think soap4r uses the httpclient library. It might be worth checking the value of HTTPClient::VERSION on both your dev machine and your server, to see if they are the same. Maybe the one on your dev box automatically follows redirects, but the one on the server doesn’t.

Hi Jon,

I tried with the redirect URL and it seems to work ().
How can this happen? Is this normal?
And how can I parse the result? (normally I use the following code to do that but now, it does not accept the “return” value…

..
soapResponde_chgst = soap_chgst.process(:message=>message)
result = soapResponde_chgst.return.inspect
...

Thanks again

Hi Jon,

I tried with the redirect URL and it seems to work ().
How can this happen? Is this normal?

And how can I parse the result? (normally I use the following code to do that but now, it does not accept the “return” value…

..
soapResponde_chgst = soap_chgst.process(:message=>message)
result = soapResponde_chgst.return.inspect
...

Thanks again

Paulo,

What is the Service URL returned by the WSDL (waay at the bottom, usually)? It’s possible that your Web Server administrator incorrectly or incompletely implemented the Temporary Redirects.

The SOAP endpoint in the WSDL is what gets used to make the service call, and I suspect the URL in your WSDL is stale or incorrect.

Check to see if the WSDL is still directing you to “myip:8080…Message” endpoint, while your Administrator is trying to force you go over “myip..Message” (no port 8080.. or some other URL mismatch along these lines). If this is the case, you’ll need to get the WSDL updated on your remote end, get your Admin to set up things the way they’re designed and intended, or (worst case) you’ll need to alter the SOAP URL that soap_chgst picked up from your WSDL before you do a .process() call.

Hello

Thanks for your reply and help.
The URL returned by the WSDL is “http://myip:port/mywebservice/services/Message”
It seems correct. When I type it on IE, the method is executed correctly and show me the expected result…

Hello

I still trying to resolve this problem. And I am more and more surprised by the tests obtained trying to figure out the problem.

What I’ve done is the following:
Instead of doing this factory_chgst = SOAP::WSDLDriverFactory.new(wsdl_url) -> this is the line when error “no element found” is thrown
I made this (after saving locally the WSDL file: factory_chgst = SOAP::WSDLDriverFactory.new(“c:/webservice_wsdl.wsdl”)

The web service is only running on “wsdl_url”. After that, I done the normal stuff to call it:

soap_chgst    = factory_chgst.create_rpc_driver
soap_chgst.streamhandler.client.receive_timeout = $ws_timeout
soapResponde_chgst = soap_chgst.process(:message=>message)
...

It worked, no error was generated.
So it seems that the only problem is retrieving the WSDL with the factory_chgst = SOAP::WSDLDriverFactory.new(wsdl_url) instruction.

Any idea?

Thanks anyway

Paulo,

Soap4R has its quirks, and I’ve had more than my share of pulling my hair over getting a robust configuration. Sometimes the “out of box” Soap4R bundled with Ruby works, sometimes the Soap4R gem works, sometimes I had to install from Subversion.

What I usually do these days is pre-generate the SOAP Client code with wsdl2ruby (make sure to pass in sane names for the generated classes), and stick the generated results into the $RAILS_ROOT/components directory. I can then instantiate a Soap Client by class name, and let it do its thing. It’s a bit more work—especially when constructing the requests, but I’ve found it to be a reliable way to get the job done with the least number of surprises.

The upside to the approach is I know the same client code is used between Dev and Production environments, and I could even tweak things to override the Service URL if needed. The downside is if the remote SOAP endpoint is under rapid development, you’ll need to regenerate your SOAP Client code every time the service api changes.

I found another solution that is working.
Instead of using SOAP4R i am using ‘soap/rpc/driver’:

driver = SOAP::RPC::Driver.new($webservice_changement_statut_url, ‘urn:process’)
driver.add_method(‘process’, ‘message’)
wsResult_chgst = driver.process(message)

That way, I resolved my problem. I don’t know why it was not working with SOAP4R…