Hi, I am trying to convert a string (from source system) and convert that to double (destination field data).
I tried to use a java service where it will convert string to double by parsing. Conversion is working well. But the double consists of decimals.
For example if the string value is ‘10’, after the conversion the double value is getting populated as 10.0 with ‘.0’ decimal value. I know you might be thinking, you can parse it as Integer to avoid decimal values. But the destination field is expecting double. And If I map the Integer, the destination field is also getting changed to Integer type.
And also please include a screenshot of your service.
Under normal circumstances you shouldn’t need to convert data types manually. If all you need is the integer part, you can just split that integer with ‘.’ or ‘,’ depending on your data. Most fields in IS is either document or string. If you pass a string to an integer/double field of a service, IS will do the conversion automatically. Most backend services (for example .net core services) will do the same as well.
That does sound like there is a problem with the destination services. Do you have a wsdl or swagger url? Also please provide a screenshot of your client service and or wsdl/swagger. You can mask the secrets and confidential information, end point url, hostnames etc.
If you want to pass a string value to a primitive type field in remote server, you need to create a document or import the document to IS using swagger or wsdl or something similar (xsd, json schema or something). In the document if you set the field type to be integer/double/etc, integration server will do the necessary conversion. If you don’t do this, and pass the value as it is to the destination, you rely on destination services conversion mechanics. Most backend services does this automatically, but its usually better to stick to the protocol instead of relying on assumptions.
No it is not. You may be conflating the string representation of the double variable with the binary storage of a double – it is 64 bits of binary, not “10.0”.
Unless you’re using a code library of some sort to communicate with the target system, I’d be surprised if it is actually a double. As others have already requested, we’ll need to see the interface specification of the target system to provide meaningful help. XML/SOAP has a “double” type via XSD, but XML is a string. JSON has a “number” type but that too is a string. In each of those cases, as long as you structure the IS document correctly and manage the creation of the XML or JSON string properly (may need a bit of trick to get the JSON number right so that it is not quoted in the JSON) there is no need to convert the original string at all – and certainly not to float/double.
I addition to the info from others, I would caution about the use of double if it is intended to represent monetary values – float/double have constraints due to the nature of binary arithmetic and representation. E.g. 0.1 decimal is a repeating fraction in binary. This can impact calculations in undesired ways.
If this is used for money, you’ll want to consider never converting it to float/double anywhere along the path. If the target system is a custom interface that you or your company can control, it should avoid using double too.
There are a variety of articles/blogs/conversation boards on the web about this.
I admit that I haven’t followed up on this over the last (many) years. But a long time ago I have seen incorrect results from the use of Float that would make your hair stand up. Think about something along the lines of “9 divided by 3 equals 2.99999999” … Really!
Since then I have only used BigDecimal. And because the calculations in my code were always only for display purposes, I never looked into this in detail for a very long time. But I certainly would spend considerable time, should my code ever have a real impact.
Yes, I am probably a bit of an alarmist here. But better safe than sorry.
It also applies to .net. You should use decimal instead of float or double. Even if the variable is not used for finance, it can still cause a lot of problems if the precision accuracy is important. Most people don’t bother with float or double problems and just never use it.
Actually, it is the accuracy that is important in financial data. Precision less so. Accuracy and precision - Wikipedia. The way I remember it more easily: 1.23456 vs 1.24. The former is more precise and the latter, if the true/expected value is 1.24, is more accurate.Or using the earlier example of 9 divided by 3, 2.999999 is more precise and 3.0 is more accurate.
The avoidance of binary arithmetic via float/double applies to every language and every computer. It is a characteristic of binary floating arithmetic not of the language or run-time environment (in the past some have referred to observations of unexpected results as a “JVM bug” but it is not.)
We, who speak English as a secondary language tend to make that kind of mistakes. You are right, its accuracy, not precision. I will also edit the post to avoid misunderstanding.
Define a variable to hold the input String value.
Invoke the pub.string:toFloat service to convert the input String to a floating-point number.
Invoke the pub.math:round service to round the floating-point number to the nearest integer.
invoke the pub.math:int service to convert the rounded number to an integer.
The output result will be the integer value without any decimal points.
I cannot over-emphasize that this is not how this should be done for monetary values. Float/double should never be used, by convention and habit, because in various scenarios the results will be undesired. In this case, likely okay but as a matter of diligence, using float/double for monetary values should always be avoided.