-
Notifications
You must be signed in to change notification settings - Fork 74
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
WSDL ... Non-WSDL mode? #232
Comments
From my knowledge If you have a WSDL, you can nevertheless set the location, the url, to where the request must be sent because the WSDL may contain a SOAP address location with a To set the location of where the request must be sent, you have to call the method setLocation on the SerciveType instance passing the SOAP address location. Am I mistaken? |
Whoops. I had overwritten my URL variable and it really wasn't pointing to the correct location. So disregard that issue as I do get a response back, but it's only when I pass in the local path to the WSDL in the URL setting. If I don't it also tries to send the SOAP packet, but the format is different: [With WSDL PATH in the URL optoin -- looks normal and works]
{Result}
VS [No WSDL PATH in the URL option -- looks different and fails from the server side response]
{Result}
Any idea why the difference? Am I doing something wrong or missing anything? |
I'm not sure to follow, what's the real issue?
|
I'm just wondering confused what made it output the SOAP packet differently. I'm not passing the URL parameter the local wsdl in the 2nd instance, and it generates the SOAP similarly, but not the same. It essentially includes the 'ns1:' on all the fields in the first instance and on the one without the local WSDL file path it generates it without the 'ns1' and with those extra 'xsi:' attributes. Is there a reason behind it? I'm just trying to understand the difference and what is causing it to generate the SOAP packet differently. |
To clarify more ... using the first example does work properly and I get a proper soap response back now. (Yea!) I was just trying to understand why the output changes when I do not pass in the local URL of the wsdl versus when I do. |
If the SoapClient has the WSDL, it can namespace the parameter so you end up with |
Alright. Thanks. |
Hello,
I have a new issue that is related to #231 but I thought it made the most sense to open a new ticket.
So, now that the SOAP packet is being sent in the correct format, the issue now is that server doesn't have the WSDL on it. So, I'm not sure, but I'm thinking that would make me need to use "Non-WSDL" mode??
If so, it appears that the URL is supposed to be null and the uri and location should be filled in. However, this isn't working. If I input the path to the local WSDL, it complains with a SOAPFAULT of "Looks like we got no XML document". (which there isnt' a WSDL on the server side from the vendor) .... but if we leave the URL null, then the package generator is looking for the WSDL file in a local folder on the webserver and bombs out.
Any ideas? Help!?
Thanks!
The text was updated successfully, but these errors were encountered: