#768 Error: no wsdl:definitions/portType/operation

[Scott Baily]

When attempting to generate a header file for an Echelon i.LON SmartServer, the following error occurs:
Error: no wsdl:definitions/portType/operation
The system WSDL file (iLON100_Systrem.wsdl) works without problems, and I can write a client application. Unfortunately, I'm interested in reading data from the device rather that altering its configuration, and that file (iLON100.wsdl) results in the following warning/errors:

Warning: no matching portType operation 'List' in WSDL definitions '' namespace
Warning: no matching portType operation 'Get' in WSDL definitions '' namespace
Warning: no matching portType operation 'Set' in WSDL definitions '' namespace
Warning: no matching portType operation 'Delete' in WSDL definitions '' namespace
Warning: no matching portType operation 'Read' in WSDL definitions '' namespace
Warning: no matching portType operation 'Write' in WSDL definitions '' namespace
Warning: no matching portType operation 'Clear' in WSDL definitions '' namespace
Warning: no matching portType operation 'InvokeCmd' in WSDL definitions '' namespace
Error: no wsdl:definitions/portType/operation
Error: no wsdl:definitions/portType/operation
Error: no wsdl:definitions/portType/operation
Error: no wsdl:definitions/portType/operation
Error: no wsdl:definitions/portType/operation
Error: no wsdl:definitions/portType/operation
Error: no wsdl:definitions/portType/operation
Error: no wsdl:definitions/portType/operation

[Scott Baily]

WSDL and xsd files from the manufacturer.

[Robert van Engelen]

Try this 2.8.3 update, which is a 2.8.4 pre-release:

http://www.cs.fsu.edu/~engelen/gsoap_2.8.4.zip

then rebuild the soapcpp2 and wsdl2h tools. This update includes a number
of fixes and enhancements, but is not ready for release until further
testing.

[Scott Baily]

I get exactly the same error messages, except that the namespace is reported. For Example:
Warning: no matching portType operation 'List' in wsdl definitions 'iLON100' namespace 'http://wsdl.echelon.com/web_services_ns/ilon100/v4.0/wsdl/'

[Robert van Engelen]

Well, if there is no portType operation that matches the bindings there is insufficient information to perform the mapping safely. So if there are binding operations but no portType operations, how will we be able to determine the XML messages? If there are partly REST operations that cause this, these can be done semi-automatically.

[Scott Baily]

I'm new to soap, but it looks to me like there are portType operations. In fact these are the only ones.
<!-- ******************************************************** -->
<!-- declaration: 'wsdl:portType' -->
<!-- ******************************************************** -->
<portType name="iLON100portType">
<!-- ______________________________________________________ -->
<!-- List -->
<operation name="List">
<input message="ilonwsdl:List_SoapIn"/>
<output message="ilonwsdl:List_SoapOut"/>
</operation>
<!-- Get -->
<operation name="Get">
<input message="ilonwsdl:Get_SoapIn"/>
<output message="ilonwsdl:Get_SoapOut"/>
</operation>
<!-- Set -->
<operation name="Set">
<input message="ilonwsdl:Set_SoapIn"/>
<output message="ilonwsdl:Set_SoapOut"/>
</operation>
<!-- Delete -->
<operation name="Delete">
<input message="ilonwsdl:Delete_SoapIn"/>
<output message="ilonwsdl:Delete_SoapOut"/>
</operation>
<!-- Read -->
<operation name="Read">
<input message="ilonwsdl:Read_SoapIn"/>
<output message="ilonwsdl:Read_SoapOut"/>
</operation>
<!-- Write -->
<operation name="Write">
<input message="ilonwsdl:Write_SoapIn"/>
<output message="ilonwsdl:Write_SoapOut"/>
</operation>
<!-- Clear -->
<operation name="Clear">
<input message="ilonwsdl:Clear_SoapIn"/>
<output message="ilonwsdl:Clear_SoapOut"/>
</operation>
<!-- InvokeCmd -->
<operation name="InvokeCmd">
<input message="ilonwsdl:InvokeCmd_SoapIn"/>
<output message="ilonwsdl:InvokeCmd_SoapOut"/>
</operation>
</portType>

The only difference I see in this section in iLON100.wsdl (which doesn't work) vs iLON100_System (which does work) is the comments, and removing the comments from the porttype section didn' change anything.

Does this work for you? or can you tell where the problem is with some debugging options? I appreciate your help, Thank you.

[Robert van Engelen]

If there is a portType but has the wrong name or is defined in the wrong namespace then there is no association with the bindings (no matching).

[Scott Baily]

Updated WSDL files

[Scott Baily]

I obtained updated wsdl files from the device manufacturer. These still don't work, however I found a workaround.
In the binding section for these I find this:
<operation name="List">
<soapbind:operation soapAction="http://wsdl.echelon.com/web_services_ns/ilon100/v4.0/action/List"/>
<input name="ListRequest">
<soapbind:body parts="parameters" use="literal"/>
<soapbind:header message="ilonwsdl:iLON100SoapHeader" part="soapHeaderPart" use="literal"/>
</input>
<output name="ListResponse">
<soapbind:body parts="parameters" use="literal"/>
<soapbind:header message="ilonwsdl:iLON100SoapHeader" part="soapHeaderPart" use="literal"/>
</output>

if I remove the name attributes for the input and output elements, then gsoap builds a header without warnings or errors.

The next issue I encountered was that the headers had Reads returning the most generic item type (even though the comments said those operations should return datapoint items), so I couldn't access the elements I wanted. I modified the return type in the header file to match its comments (before running soapcpp2), then I was able to access the UCPTvalue fields that I wanted.
I hope these comments help you improve gsoap so others have an easier time.

With these workarounds it is now working well for me.
Thank You.

[Robert van Engelen]

Found a fix for this. In gsoap v2.8.5 wsdl/wsdl.cpp:597 change the test to:

{ if ((!input || !input->name || !(*i).input || !(*i).input->name || !strcmp((*i).input->name, input->name)) && (!output || !output->name || !(*i).output || !(*i).output->name || !strcmp((*i).output->name, output->name)))

[Robert van Engelen]

Fixed in the upcoming 2.8.6.