http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/webcontent/uuid/858903f9-0b01-0010-a994-b... http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/webcontent/uuid/c73003f9-0b01-0010-aa8b-8...
Introduction
If you have read my blog entry titled Never, ever use XI's built-in arithmetic functions, you know that XI's arithmetic and statistical functions are seriously flawed. Thankfully, SAP seems to have been paying attention also, and the functions have (mostly) been fixed with SP18! The corrections are described rather vaguely in the release notes which do not, however, explain exactly what has been done. Nor does the referenced SAP Note 958486. So here's the lowdown.
Switch
For compatibility (who knows, someone might actually rely on the behaviour of the old functions), the corrections must be activated by a parameter in the Exchange Profile:
com.sap.aii.mappingtool.flib3.bigdecimalarithmetic
If this parameter is set to true, the old arithmetic and statistical functions are replaced by a new implementation.
Note: I don't yet have an SP18 system available, so I don't know if the parameter is checked dynamically while XI is running or whether a restart is required.
Implementation
As I said, I haven't yet seen this in action. But I have downloaded the XITOOL SCA from SAP Service Marketplace, and it's amazing what you can accomplish with a good Java decompiler.
The new implementation is based on the java.math.BigDecimal class. This class requires the programmer to specify the desired precision and rounding mode for all operations that can result in a loss of precision e.g. division. This configurability has not been extended to the Message Mapping editor, but sensible values have been predefined. All such operations are performed with a scale of 17 which means that 17 digits are retained to the right of the decimal point. And the rounding mode used (ROUND_HALF_UP) is the one we all know and love.
There are only two arithmetic functions that have not benefitted from the new implementation. The first is sqrt (for calculating the square root of a number). It is limited in precision to a Java double because it relies on the java.lang.Math.sqrt() method. Fair enough. The second is formatNum which formats a number for output. This, alas, also uses double internally. So you still have to write your own formatting routine if you need one.
The statistical functions sum and average have also been corrected to use BigDecimals. The count and index functions still rely on integers, but this should not pose a problem.
Now I just hope the Exchange Profile parameter defaults to true for new installations...
