Forum Discussion

cuperman's avatar
cuperman
New Contributor
9 years ago
Solved

Decimal value converted getting converted to zero

I have a WCF endpoint with a decimal value. Somewhere (between submitting the request and the first line I can debug on the WCF service) the value is getting converted to a zero.

 

I can call the same service, with the same parameters from a .NET application and don't see the same problem, so this feels strongly like a problem with the way that SoapUI is handling the request.

 

I'm baffled. Does anyone have any ideas?

 

UPDATE:

 

I have traced the request using Fiddler. The decimal value is intact after it has left SoapUI, but is getting changed before it is consumed. The value is not getting changed if it is submitted by by .NET application.

 

Still baffled.

 

  • 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.

     

    I'm yet to determine why SoapUI generated the parameters in a different order, and why (when this is XML), this order makes any difference on the server :-( 

2 Replies

  • cuperman's avatar
    cuperman
    New Contributor

    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.

     

    I'm yet to determine why SoapUI generated the parameters in a different order, and why (when this is XML), this order makes any difference on the server :-(