BA_Service_Haus
11 years agoRegular Contributor
Problems with abstract data-type
Hi,
in our WSDL there is defined an abstract data type, e.g.
It is extended by another type, e.g.
In soapUI these types causes 2 problems:
Especially the second behaviour is blocking our test execution.
in our WSDL there is defined an abstract data type, e.g.
<xsd:complexType abstract="true" name="AbstractElement">
<xsd:annotation/>
<xsd:sequence>
...
</xsd:sequence>
</xsd:complexType>
It is extended by another type, e.g.
<xsd:complexType name="RealElement">
<xsd:annotation/>
<xsd:complexContent>
<xsd:extension base="tns:AbstractElement">
...
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
In soapUI these types causes 2 problems:
- When creating a mock response, containing an element of type "AbstractElement", it can be declared as element of type "RealElement" within the form-view. No other selection is possible. But when using this mock-response in a testcase, schema-compliance assertion fails with message:
line x: Element 'T=AbstractElement@namespace' is abstract and cannot be used in an instance
I guess, this error is caused by the missing xsi:type="RealElement" statement. Adding this statement into the mock-request leads to a passed schema compliance assertion.
This is the mock-response created by soapUI:...
<opt:Response>
<opt:Element>
...
</opt:Element>
</opt:Response>
...
This is the modified response that passes the schema compliance assertion:...
<opt:Response>
<opt:Element xsi:type="RealElement" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
...
</opt:Element>
</opt:Response>
... - Schema compliance also fails sometimes, when testing against the real service.
If the response only contains one element of type "RealElement", everything is fine.
But if there are more elements of type "RealElement" (which is permitted by the schema), the schema compliance failes with the following message:line xx: Invalid xsi:type qname: 'RealElement' in element Response@http://url2xsdfile
The problem seems to be the namespace of RealElement , which is the defaultnamespace (xmlns) in this response, so there is no namespace-shortcut added to the datatype.
The response looks like:...
<ns1:Response xmlns="http://default" xmlns:ns1="http://default">>
<ns1:Element xsi:type="RealElement" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
...
</ns2:Element >
<ns2:Element xsi:type="RealElement" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
...
</ns2:Element>
</ns2:Response >
...
Especially the second behaviour is blocking our test execution.