Incorrect values sent to server?
Hi - I'm pretty new to soapUI, so please bear with me. We found that when sending certain values to the server they are getting converted by soapUI from Strings to 0. This is the scenario:
We are sending the following data to the server as shown in this (sanitized) piece of the wsdl:
<xsd:complexType name="XXXX">
<xsd:sequence>
<xsd:element name="XXXX" type="xsd:string"></xsd:element>
<xsd:element name="XXXX" type="xsd:string"></xsd:element>
<xsd:element name="XXXX" type="xsd:float"></xsd:element>
<xsd:element name="XXXX" type="xsd:float"></xsd:element>
<xsd:element name="XXXX" type="xsd:float"></xsd:element>
</xsd:sequence>
</xsd:complexType>
With schema validation turned on in the Editor properties, if we try to pass a sequence of characters (like abcd, etc.) in any of the float elements, the system correctly rejects this. However, our testers want to turn off validation to run the tests. In this case, soapUI takes the incorrect character sequence string and converts it to 0. In doing this, our application will return a value in the response, as 0 is a valid input.
Is there any way we can make soapUI stop performing this conversion? We are using soapUI 2.5.1 with the following build info: Build dist-104-2009-02-01, Build Date 2009/02/01 21:22. The application server is WAS 7.
If this is fixed in a later build please let me know so I can send justification for an update. Otherwise, if there is some other way to fix this, please let me know. We have confirmed that the input coming in to the application is being converted prior to hitting the application itself, so we are pretty sure it is happeining somewhere in the request process. It's possibly that WAS could be doing something as well, but so far we have not found any indication that this is happening. Running SOAP Monitor is not showing the whole picture either - The request message contains the characters as input, and the response is defined only to show the results of the calculations. I'm working on getting tcpmon installed to see the raw packets for the entire process, but that is probably not going to happen any time soon here.
Thanks for your time, and let me know if I can provide any additional information to help troubleshoot this issue.
--Jim White
We are sending the following data to the server as shown in this (sanitized) piece of the wsdl:
<xsd:complexType name="XXXX">
<xsd:sequence>
<xsd:element name="XXXX" type="xsd:string"></xsd:element>
<xsd:element name="XXXX" type="xsd:string"></xsd:element>
<xsd:element name="XXXX" type="xsd:float"></xsd:element>
<xsd:element name="XXXX" type="xsd:float"></xsd:element>
<xsd:element name="XXXX" type="xsd:float"></xsd:element>
</xsd:sequence>
</xsd:complexType>
With schema validation turned on in the Editor properties, if we try to pass a sequence of characters (like abcd, etc.) in any of the float elements, the system correctly rejects this. However, our testers want to turn off validation to run the tests. In this case, soapUI takes the incorrect character sequence string and converts it to 0. In doing this, our application will return a value in the response, as 0 is a valid input.
Is there any way we can make soapUI stop performing this conversion? We are using soapUI 2.5.1 with the following build info: Build dist-104-2009-02-01, Build Date 2009/02/01 21:22. The application server is WAS 7.
If this is fixed in a later build please let me know so I can send justification for an update. Otherwise, if there is some other way to fix this, please let me know. We have confirmed that the input coming in to the application is being converted prior to hitting the application itself, so we are pretty sure it is happeining somewhere in the request process. It's possibly that WAS could be doing something as well, but so far we have not found any indication that this is happening. Running SOAP Monitor is not showing the whole picture either - The request message contains the characters as input, and the response is defined only to show the results of the calculations. I'm working on getting tcpmon installed to see the raw packets for the entire process, but that is probably not going to happen any time soon here.
Thanks for your time, and let me know if I can provide any additional information to help troubleshoot this issue.
--Jim White