System: Integration Server 4.6
Has someone else faced problems with the input format expected by float services? They seem to pick up some settings from the OS the server is running on. In my case this is a system with German settings for numbers (although the OS is an English W2K).
The effect is that in order to enter floats I must provide them with komma as decimal separator. This creates another problem with regard to input parameter validation, as the W3C data types expect a dot as decimal separator, which absolutely makes sense.
Currently I get the following:
10.5+10.5=210
10,5+10,5=21.0
As we will deploy IS on larger scale, we must have an option to set this behaviour in a unifeid way.
Any hints?
Integration Server is Java-based. As such, it uses the locale settings/defaults of the OS it is running on. If you need to support a specific number format that is not the format for the default locale of the JVM, you’ll have to take steps to convert strings to numbers yourself. Refer to the Java docs for details.
To get the unified implementation you’re looking for, you can set the locale for all machines to be the same locale. Do the W3C data types assume a certain locale (e.g. U.S.)? If so, looks like your choice of locale may have been made for you.
Sidebar: it is ill-advised to use float for calculations that require precision. For example, if you use float for calculating money, you will encounter rounding errors. As an example, you’ll see that .1 cannot be represented precisely by IEEE floating point. This is not a Java issue.
If you require precision, my advice is to keep decimal numbers as strings as long as you possibly can. When you need to do arithmetic, use BigDecimal, not float. Do not use the Integration Server built-in services that do float arithmetic if you need precision.