WSDL with multiple namespaces failing to identify them

[jufemaiz]

I'm attempting to use Savon with a relatively complex namespaced (6 excluding the standard SOAP XML namespaces) environment and am wanting to use the WSDL to drive Namespaces.

My expectation is that, given a WSDL identifying the namespaces for SOAP objects and variables, that these be automatically updated with the namespace.

Can you give any guide on this? I'm not sure how much code I can post (I know that in itself is an issue).

[rubiii]

you want to know if it's possible? or did you try it? if savon failed to parse the wsdl, please post the link to the wsdl
or create gist for it so i can debug it.

[jufemaiz]

Hi @rubiii - it's a bit of both. Github-mailed you the gist link.

[rubiii]

thx. i didn't have any time to test this yet, but i'll get back to you asap.

[acallaghan]

I also have this problem - are there any updates?

[anherdene]

i have same problem too

[jkingdon]

I'm not sure what people mean by "same problem", these things are depending on the specific WSDL file. Savon attempts to parse the WSDL and add the right namespaces, and any bugs are likely ones that would happen with some WSDL files and not others.

[rubiii]

can one of you provide a wsdl document and xml examples of the expected and actual xml?!

[jkingdon]

The namespaced WSDLs that led me to do this work initially, or the server they describe, are no longer available to me, which is part of the reason for my silence; I don't have an especially good way of testing changes against real SOAP servers these days (unless there are public ones which would serve).

The namespace code could use some love, I'm sure. What I got accepted in 2011 was enough for the particular server I had, but I didn't make any serious effort to make it handle all cases.

I keep meaning to spend some time on this, but keep not getting around to it. Definitely agree with rubiii that a test case would make it easier for us to fix this.

[rubiii]

right. closing this issue until it gets some ❤️

[jufemaiz]

@rubiii I had sent you what I could. Using this behind the firewall so can't provide everything.

[psulightning]

Know this is from 8 years ago, but I am experiencing similar behavior. Unfortunately, I cannot post the wsdl as it is proprietary, but I can give broad information.

The WSDL in question is maintained by an external company that has multiple API versions (and different WSDLs) that are implemented by our mutual clients. My work requires me to by able to connect to the endpoints regardless of what API version.

What I have done:

1. Make a hash for each API version in code with base URLs for the namespaces
2. Prefix the base URLs to the common paths
3. Use namespaces global to add in namespaces from WSDL definition not automatically loaded

This is not optimal as a lot of data is in the code. Yes, I could put these all in external configurations, but subsequent API versions may eliminate these namespaces.

When I've stepped through my code and this gem, I see the Wasabi Document does indeed parse completely with the namespaces available in the parser.namespaces.

What I would like to see:
When building the request, inspecting the data for the XML body to see if the namespace is not the target namespace and pull from parser.namespaces. Obviously, the content in the GlobalOptions namespaces key should take precedent, but when namespaces that exist in the WSDL definition are used, they should be included in the request.

Happy to clarify if any confusion.