KPost
18 years agoNew Contributor
Mock Response problem handling WSDL with multi levels of xsd:includes
When a test case Mock Response step is emulating an operation defined in a WSDL file that xsd:includes's an XSD file which in turn xsd:includes another XSD file, the WSDL published by the Mock Response step will not be valid.
I know the above description sounds confusing so let me give an example.
Suppose the WSDL is structured as follows:
….
….
And AppSpecificTypes.xsd is structured as follows:
….
The contents of CommonTypes.xsd are not important to describing the bug.
Given the above structure for WSDL and XSD’s causes soapUI to generate WSDL of the following form from its mock response service:
….
….
So far, so good.
The problem comes in when you fetch the XSD included from the WSDL. Fetching the XSD from the URL provided by soapUI in the WSDL returns XSD of the following format:
….
The bug is that the schemaLocation generated by soapUI in the above XSD is incorrect. Instead of including a different URL for the CommonTypes.xsd file, the URL generated by soapUI points back to the same XSD file. The result is an XSD file that just re-includes itself.
Thanks for looking into this problem,
Kurt
I know the above description sounds confusing so let me give an example.
Suppose the WSDL is structured as follows:
….
….
And AppSpecificTypes.xsd is structured as follows:
….
The contents of CommonTypes.xsd are not important to describing the bug.
Given the above structure for WSDL and XSD’s causes soapUI to generate WSDL of the following form from its mock response service:
….
….
So far, so good.
The problem comes in when you fetch the XSD included from the WSDL. Fetching the XSD from the URL provided by soapUI in the WSDL returns XSD of the following format:
….
The bug is that the schemaLocation generated by soapUI in the above XSD is incorrect. Instead of including a different URL for the CommonTypes.xsd file, the URL generated by soapUI points back to the same XSD file. The result is an XSD file that just re-includes itself.
Thanks for looking into this problem,
Kurt