Limitations to WSDL Document Support

Unsupported WSDL Documents

RPC-encoded WSDL documents.
Documents that the Apache^® CXF program cannot compile into complete code.
Documents that import other WSDL documents that contain WSDL type definitions.
Workaround
Move all schema definitions from the imported files into the top-level WSDL file. Schema definitions appear as schema elements inside types elements.
If the imported files are not local, copy them locally and modify the import elements of all the files to point to the local files.
For example, consider the following top-level file.
```
    <definitions> 
        <import location="http://foo/bar?wsdl" /> 
        <types> 
           ...top level type definitions... 
        </types> 
    </definitions>
```
Download the file in the location attribute, http://foo/bar?wsdl, to a local file, and save it as imported_file. This file contains information similar to the following.
```
    <wsdl:types> 
        ...low level type definitions... 
        <xsd:schema> 
            ...schema definitions... 
        </xsd:schema> 
    </wsdl:types> 
```
Look for types and schema elements. The text prefixes, wsdl and xsd, do not have standard naming conventions and might not appear at all. Do not download import elements within the schema definitions. Move all schema elements in the imported file, including the opening and closing tags, from the imported file to the end of the types element of the top-level file. Then delete the elements from the imported file. Do not modify existing schema elements in the top-level file. If the top-level file already contains a types section, add the schema elements to the existing types content. Otherwise, create a types section within the definitions element of the top-level file to contain the schema elements.
The top-level file now contains the following.
```
    <definitions> 
        <import location="imported_file" /> 
        <types> 
            ...top level type definitions... 
            <xsd:schema> 
               ...schema definitions... 
            </xsd:schema> 
        </types> 
    </definitions>
```
The imported_file file contains the following.
```
    <wsdl:types> 
        ...low level type definitions... 
    </wsdl:types> 
```
There must be exactly one types element in the top-level file inside the definitions element, containing all the schema defined in the imported WSDL files. None of the imported WSDL files should contain any schema elements.
On Windows^®, documents that import other WSDL documents might fail if the imported URI contains certain punctuation characters.
Some documents with messages containing multiple parts.
Some documents with schemas containing anonymous complex types.
Some documents defining an input parameter to an operation as a simple type. When you invoke such an operation, for example GetMyOp, MATLAB^® displays one of the following errors.
```
Error using xxx/GetMyOp.  Too many input arguments.
```
Or:
```
Error using matlab.internal.callJava
No GetMyOp method with appropriate signature exists in Java class $Proxy57
```
If the WSDL document defines schema types in multiple namespaces, an error might occur if types in different namespaces have the same names. Multiple namespaces usually occur when using import statements. MATLAB displays messages similar to the following.
```
Error using matlab.wsdl.createWSDLClient (line 239) 
Error processing WSDL: 
file:/l:/02090080/incoming/service_w0_x0.xsd [149,4]: Two declarations cause a collision in the ObjectFactory class.
```
To work around this problem, copy the imported files and edit them to rename the conflicting types.
XML Schema element all not recognized.
Workaround
If a complexType is defined using all, then none of the child elements appear in the generated MATLAB class for the type. In this example, the Id and Name elements do not appear as a properties of the Record class.
```
<xsd:complexType name="Record">
    <xsd:all>
        <xsd:element name="Id" type="xsd:string"/>
        <xsd:element name="Name" type="xsd:string"/>
    </xsd:all>
</xsd:complexType>
```
To work around, copy the WSDL file locally and replace xsd:all with xsd:sequence.
```
<xsd:complexType name="Record">
    <xsd:sequence>
        <xsd:element name="Id" type="xsd:string"/>
        <xsd:element name="Name" type="xsd:string"/>
    </xsd:sequence>
</xsd:complexType>
```

Documents Must Conform to Wrapper Style

Operations defined in the WSDL must conform to the rules for wrapper style, as described in The Java API for XML Web Services (JAX-WS) 2.0. Error messages similar to the following are indications of this problem.

Error using matlab.internal.callJava
No authenticate method with appropriate signature exists in Java class com.sun.proxy.$Proxy55

Error in Service/Authenticate (line 107)
            matlab.internal.callJava('authenticate',obj.PortObj,fromMATLAB({'Authenticate','user'},
            user,'string',false,false),...

To work around this issue, edit the WSDL to conform to the wrapper style rules, or edit the generated MATLAB code to instantiate and pass in the Java^® class object that contains the parameters.

SOAP Header Fields Not Supported

It is not possible to send messages that require Simple Object Access Protocol (SOAP) header elements. Only SOAP body elements are supported.