-
Notifications
You must be signed in to change notification settings - Fork 614
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I had to use :message_tag #520
Comments
Thanks for using Savon @eljojo ! This seems like it might be a bug in Savon or maybe Nori, but it's hard to tell. Could you maybe explain how you came to find out that the |
Hi, I just upgraded from version 2.2.0 (which was working fine) to 2.3.0 and I ran into the same issue. Unfortunately, the API is under an NDA so I can't post the full WSDL, but it seems something like: <portType name="Musteri_PORT">
<operation name="MUSTERI_KAYDET">
<documentation/>
<input message="tns:MUSTERI_KAYDET_Request"/>
<output message="tns:MUSTERI_KAYDET_Response"/>
</operation>
</portType> in the WSDL makes Savon think it should send the <env:Envelope xmlns:tns="http://localhost:8080/server/cms" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<tns:MUSTERI_KAYDET>
.... Fields elided ...
</tns:MUSTERI_KAYDET>
</env:Body>
</env:Envelope> now looks like this: <env:Envelope xmlns:tns="http://localhost:8080/server/cms" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<tns:MUSTERI_KAYDET_Request>
.... Fields elided ...
</tns:MUSTERI_KAYDET_Request>
</env:Body>
</env:Envelope> If I have time, I'll try to do a git-bisect to see which commit has broken the functionality, and let you know. |
Just looked at the code and I believe it was savonrb/wasabi#15 that caused the issue. That patch adds output message parsing but also changes the returned tag name for input operations. |
For me it looks like it appends a 4 in the end:
And that's really weird.
|
@paracycle was kind enough to track down these changes. I believe these changes may be valid for Output, but almost certainly not for Input. I had an opportunity to speak with @rubiii earlier about this and his thoughts were that it wasn't very surprising that this change broke a lot of real code. For one, it also changed specs. Secondly, there wasn't a real example of why this would need to be like this in the PR. Lastly, the end result of the code is overly complicated. I've just spent the last hour looking at the `input_output_for` method in Wasabi::Parser just to find out that this was pulling in a completely bogus request / response tag name in two thirds of the cases. My hopes are that this fix will fix the regression in Savon 2.3.x and we can stop worrying about this for Savon v3.
there is something wrong with it: |
Hey @jsaak, I think what you're describing is fixed in savonrb/wasabi#39. Wasabi v2.3.3 was released today, and I think these issues are fixed now. @eljojo could you confirm that this issue is fixed with Savon 2.3.2 and Wasabi 2.3.3? sidenote: savon 2.3.2 has a dependency on wasabi >= 2.3.2, so updating Wasabi alone should resolve this. |
The issue is fixed with Savon 2.3.2 and Wasabi 3.2.3 👌😉 |
I'm experiencing this issue with Savon 2.4.0 / Wasabi 3.2.3. Here's bit of the top level wsdl (it's broken down into many pieces):
It should (and used to in earlier versions) produce output that looks like this:
But with the latest release (2.4) it now produces this, generating errors similar to those described above:
Note, as before, it's sending "flt:FLEformFields" as the tag instead of "writeCaseEformData". |
@davemitchell would you mind opening a new issue? If you can include your entire WSDL, or a small subset, or best -- a failing spec, I'd be more than happy to investigate and find a solution. |
I'm having a similar issue parsing a WSDL with Savon 2.7.0 and Wasabi 3.3.1 Parsing the EchoSign's WSDL https://secure.echosign.com/redirect/latestApiWsdl returns different results between the two versions above, and I believe is the reason my Savon client call throws the error "(soap:Client) Invalid operation: {http://api.echosign}sendDocumentRequest". The WSDL is the change but the request that savon makes is different. Below is a part of the request: Working, old version of Savon/Wasabi <env:Envelope>
<env:Body>
<tns:sendDocument>
<tns:documentCreationInfo>
<ins0:fileInfos>
<ins0:fileInfo>
<ins0:fileName>file.pdf</ins0:fileName>
</ins0:fileInfo>
</ins0:fileInfos>
</tns:documentCreationInfo>
</tns:sendDocument>
</env:Body>
</env:Envelope> Not working, latest version of Savon/Wasabi <env:Envelope>
<env:Body>
<tns:sendDocumentRequest>
<tns:documentCreationInfo>
<tns:fileInfos>
<tns:fileInfo>
<tns:fileName>file.pdf</tns:fileName>
</tns:fileInfo>
</tns:fileInfos>
</tns:documentCreationInfo>
</tns:sendDocumentRequest>
</env:Body>
</env:Envelope> As you can see there are tns instead of ins0 and the action in the NOT working request is sendDocumentRequest instead of sendDocument. |
Hi,
I'm just sharing this in case it's useful.
I'm using savon 2.3.0 and I guess the gem had some problems identifying parameters automatically from my wsdl. I have no idea about SOAP and this is the first time I'm actually using it.
I'm dealing with TradeTracker's WSDL
With the following code I got it working:
Without setting the
message_tag
I would get the following response:Procedure 'AuthenticateMessage' not present
I'm just sharing this in case there is something that might be fixed. Thanks for rocking with your heavy metal.
The text was updated successfully, but these errors were encountered: