Hi all
I am currently encountering an issue with wsdl importation in webMethods.
My wsdl looks like this:
…
The matter being generated parts (ie fields part1 to partn) are SYSTEMATICALLY optional.
Is it possible to change that behaviour, because parts are actually required by default
according to web services specifications.
Am I missing something here ?
Thanks in advance for helping
Thanks in advance for helping
Hi
Any thoughts ?!
So can you update the WSDL to have the nillable=false as mentioned in the other thread to check?
HTH,
RMG
Hi rmg
Thank you for this answer.
This wsdl was provided by a partner and I can’t actually modify it (I so wish I could !!).
As it uses the “part” element that only allows name, type or element as attributes and not the “element” element the nillable field can not be set to false
RH
Validate the WSDL in a third party tool like Eclipse or XMLSpy or any other XML Editor. See if it passes the validation. If you can, post the WSDL here.
There are ways to make changes to the WSDL (make it a valid WSDL) and import it in to webMethods and it will work as long as your SOAP request is meeting your partner specification, in this scenario your partner does not have to change anything. You will not be able to completely use the documents or the connectors generated by WM from the WSDL but you could do the SOAP over HTTP\HTTPS by composing the SOAP data.
Changing the WSDL from your end and going the SOAP over HTTP is a slippery slope and there is no meaning of using a web service, if it is not conforming to the specifications in the WSDL.
Cheers,
Akshith
Hi
The wsdl is valid I just checked it with Xml Spy.
You’ll find it attached
RH
inscr.wsdl (1.52 KB)
That is a valid WSDL and the problem that you are facing is because you do not have any (complex) types defined in the WSDL. Edit the WSDL on your end while consuming to set these restrictions in the complex types and then consume it in webMethods. Since the WSDL is not defining any restriction you can not expect WM to generate artifacts with the desired restrictions.
In other words the WSDL needs to have the definitions defined properly for them to show up in webMethods. Attached is a partially modified WSDL with the restrictions that you were asking for. I am not sure what value these changes will bring to code in webMethods.
inscr.wsdl (2.12 KB)
I agree it would be easier to use a complexType, the matter with that approach being it brings up a wrapper as a root element, that’s what I was gladly actually going for in the first place, because having fields around without a root element seemed weird to me. Not to mention tremendous field to field mappings amongst others! But then I was told that pain of a wsdl could not be changed! Maybe fields being displayed as optional doesn’t prevent webMethods from performing some kind of validation. I 'll get to the bottom of that tomorrow at work.
RH
Hi
Unfortunately, as “expected” the fields are optional indeed. When I invoke the webService, after removing some of the parts parts from the request, I don’t get any error back it has to be a webmethod bug I guess. By the way SoapUi does recognize the mandatory fields. Since I can’t modify the wsdl it seems I am out of options here!
RH
Hi again
I did another test, I changed manually the field required of one of the parts.
Then I remove the corresponding element in the request.
If I invoke the web service I get no error, it seems that webMethods doesn’t perform any validation when a provider is invoked by a caller. At the end of the day even if the fields are generated as optional fields that makes NO DIFFERENCE at all from the point of the view of the caller.
Thanks anyway.
RH
Try setting the validate Input setting on the service input, it will throw a SOAP fault to the caller when they invoke the WM web service associated with the Flow service when required fields are not present in the SOAP request.
Hi
Yes indeed, validation can be activated trough parameters Validate input/output.
If the partner asks us to disable that validation, the current implementation (ie with optionnal fields) will be Ok but what happens when he needs that validation ?!
RH
Hi
Any thoughts ?!
If the partner asks to disable the input validation on the flow service used in the provider WSD then it will not be okay with optional fields. The consuming application can send empty values which might result in a service exception. If the input validation is disabled then the expectation is that as long as the incoming SOAP message conforms to the defined WSDL, the call will go through.
In general the partner asks us to disable the validation when he takes care of it before invoking our provider.
But still, the issue concerning the fields systematically switched from required to optional remains.
The only work around I can see right now is handling what should have been embedded inside the provider, ie checking the presence of each field manually, via webMethods code inside the code of the provider service.
It’s not pretty but it will do the trick.