1

I am using SOAPUI to call a WCF endpoint with a decimal value. Somewhere the value is getting converted to a zero.

I can call the same service, with the same parameters from a .NET application and the value is not getting altered. I can de-serialise and inspect the values being passed from my .NET app and SoapUI, and both de-serialised versions of the object are identical.

I have been able to capture the request in Fiddler after it has left SoapUI and the decimal value is still in tact so I know it is getting converted down stream somewhere.

This post suggests that this can happen when the proxy is generated: int properties are 0 when consuming WCF in .Net 2 - but evidence is not pointing to this being a problem in the service, not the client.

Apologies I can't share WSDL nor XML due to corporate privacy restrictions.

Community
  • 1
  • 1
Mark Cooper
  • 6,738
  • 5
  • 54
  • 92
  • 1
    If SoapUI would convert all decimals to zero, you wouldn't be the first to notice. Please show relevant WSDL and XML. – CodeCaster Mar 07 '16 at 13:11
  • what is the data type defined in the xml schema? – Rao Mar 07 '16 at 13:19
  • It's definitely not all decimals. It feels like a setting. I can't show WSDL or XML due to corporate restrictions on code sharing :-( – Mark Cooper Mar 07 '16 at 13:23
  • Do you see the change between what you have entered in the request editor and the raw request? – Rao Mar 07 '16 at 13:42
  • 1
    @Rao - No - its the same value. I can share that too, the request and raw value is `8.000000` – Mark Cooper Mar 07 '16 at 14:16
  • Have you tried to intercept using `tcp mon` or something to confirm the data is changed by `soapUI`? – Rao Mar 07 '16 at 14:19
  • 1
    Thanks @Rao. I have traced the message with Fiddler and can prove that it has not been altered in SoapUI, instead somewhere downstream. Question has been updated to reflect new findings. – Mark Cooper Mar 07 '16 at 14:36

1 Answers1

1

The resolution in my case was to change the order of my request parameters.

I was able to determine this by enabling WCF tracing, including message payloads, and then comparing the payloads from my .NET application against the payloads from SoapUI.

The payloads are massively different, but ignoring namespaces, correlation ids, keys and dates I was able to determine that my problematic parameter was in a different position. Changing the order within SoapUI XML request resolved the issue.

Community
  • 1
  • 1
Mark Cooper
  • 6,738
  • 5
  • 54
  • 92