Closed mvastola closed 12 years ago
This is what I'm getting for the operations output based on your wsdl:
{:login=>{:action=>"login", :input=>"ProteusAPI_login", :namespace_identifier=>"tns"}}
Seems right to me from looking at the wsdl. What are you expecting it to look like?
Well you can see with my Gist, previously (in 2.1.1) it had just been:
{:login=>{:action=>"login", :input=>"login"}}
Also of potential note. To get things to work, in 2.1.1, in Savon, I needed to call the following to get a successful reply:
response = @client.request :wsdl, :login do |soap, wsdl, http, wsse|
soap.body = { :username => Credentials::USERNAME, :password => Credentials::PASSWORD }
end
The request that 2.1.1 then generated was:
<?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wsdl="http://api.proteus.bluecatnetworks.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ins0="http://api.proteus.bluecatnetworks.com" xmlns:ins1="http://jaxb.dev.java.net/array"><env:Body><login><username>mvasto01api</username><password>****</password></login></env:Body></env:Envelope>
Now, with all current releases of Wasabi, the same code in Savon yields this request:
<?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tns="http://api.proteus.bluecatnetworks.com" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ins0="http://api.proteus.bluecatnetworks.com" xmlns:ins1="http://jaxb.dev.java.net/array"><env:Body><wsdl:ProteusAPI_login><username>mvasto01api</username><password>****</password></wsdl:ProteusAPI_login></env:Body></env:Envelope>
If I replace the :wsdl
with :tns
(or just leave it out) in the Savon request call, I get the same request with 'tns:' replacing the 'wsdl:'s.
In 2.2.0+ with :wsdl
, I get an error message parsing my response that reads
/usr/lib/ruby/gems/1.9.1/gems/savon-1.0.0/lib/savon/soap/response.rb:107:in `raise_errors': (env:Client) org.xml.sax.SAXParseException: The prefix "wsdl" for element "wsdl:ProteusAPI_login" is not bound. (Savon::SOAP::Fault)
In 2.2.0+ with :tns
or with nothing prefixing :login
in the Savon request call, I get the following:
/usr/lib/ruby/gems/1.9.1/gems/savon-0.9.9/lib/savon/soap/response.rb:106:in `raise_errors': (env:Client) Endpoint {http://api.proteus.bluecatnetworks.com}ProteusAPIPort does not contain operation meta data for: login (Savon::SOAP::Fault)
@mvastola could you please test against wasabi master? i think i fixed the problem with bb9b1ff65cd1f2d634170b97d9ff6d766f097dab.
So much win!
For now/to test, I switched my Gemfile to:
gem 'wasabi', :git => 'git://github.com/rubiii/wasabi.git', :ref => 'bb9b1ff65cd1f2d634170b97d9ff6d766f097dab'
and all is well.
Only caveat (which I'm not sure if it's the way things are supposed to be or not.. from my -- inexperienced -- analysis of the WSDL I want to go with yes...): To get it working I had to change every Savon request call such as:
response = @client.request :wsdl, :login do |soap, wsdl, http, wsse|
soap.body = { :username => Credentials::USERNAME, :password => Credentials::PASSWORD }
end
To:
response = @client.request :login do |soap, wsdl, http, wsse|
soap.body = { :username => Credentials::USERNAME, :password => Credentials::PASSWORD }
end
Or otherwise run :1,$ s/:wsdl, //g
on every file in my library in VIM, but that was a cinch, and everything seems to be working correctly now.
Thanks so much!!
not having to specify the namespace is actually a feature :) but i understand that it requires you to change your code, which is something we should prevent if possible.
thanks for testing. i'll release a fix for this soon.
Hey, If it can be solved with a simple find-replace and was a straightforward change to think of/implement like here, absolutely no harm done. :-) My library's not huge anyways.
And this totally beats banging my head against the table trying to figure out why this upgrade wouldn't work when my WSDL skills weren't really up to par to debug too well.
I was just scared it was a vendor issue (which wouldn't have surprised me at all) cause I don't have access to their help ticketing system and would need to play a thrilling game of telephone with another Dept to get that solved. :-\
Thanks for maintaining this/being an expert at this so I don't have to be! :-p
Best, Mike
related to rubiii/savon#295
released wasabi v2.5.0.
So I have a tool that interfaces with a web app's API that I had written using Savon (and, by extension, Wasabi). I just decided to try to upgrade all the gems it uses, and I'm running into problems that I think I have tracked down to have occurred between Wasabi 2.1.1 and 2.2.0.
Long story short, between those two versions, Wasabi will parse the same wsdl differently, resulting in slightly different data being sent to Savon and thus slightly different data making up the SOAP request. The SOAP request fails based on the data from the newer version of Wasabi, but not based on the data from the older one.
My proof of concept displaying the non-forward-compatibility in my Wasabi upgrade is show in this gist: https://gist.github.com/2975359
For what it's worth, I haven't worked too in depth with WSDL -- at least not enough to know what Wasabi's output should be here. Therefore, I don't mean to accuse you guys of necessarily doing anything wrong. For all I know, between 2.1.1 and 2.2.0, you fixed a major bug or added a major feature and the reason why upgrading made things stop working has to do with Savon or a vendor compatibility issue that I need to probe further.
Any guidance you can give me would be much appreciated.
Thanks, Mike