Author |
Message
|
mikko |
Posted: Mon May 28, 2007 4:46 am Post subject: conversion error of double value in xml message |
|
|
Newbie
Joined: 25 May 2007 Posts: 7
|
I'm having problems with xml messages including the datatype double.
I get an error like this one:
(0x01000000):ParserException = (
(0x03000000):File = 'F:\build\S600_P\src\cpi\pwf\xml\xmlhandler.cpp'
(0x03000000):Line = 1895
(0x03000000):Function = 'XMLHandler::convertStringToData'
(0x03000000):Type = ''
(0x03000000):Name = ''
(0x03000000):Label = ''
(0x03000000):Catalog = 'BIPv600'
(0x03000000):Severity = 3
(0x03000000):Number = 5404
(0x03000000):Text = 'Error converting characters into a data value'
(0x01000000):Insert = (
(0x03000000):Type = 5
(0x03000000):Text = 'TradeEvent'
)
(0x01000000):Insert = (
(0x03000000):Type = 5
(0x03000000):Text = 'FarRate'
)
(0x01000000):Insert = (
(0x03000000):Type = 5
(0x03000000):Text = 'Float'
)
(0x01000000):ConversionException = (
(0x03000000):File = 'F:\build\S600_P\src\cpi\bsutils\datacnv.cpp'
(0x03000000):Line = 782
(0x03000000):Function = 'DataCnv::StrToDbl'
(0x03000000):Type = ''
(0x03000000):Name = ''
(0x03000000):Label = ''
(0x03000000):Catalog = 'BIPv600'
(0x03000000):Severity = 3
(0x03000000):Number = 5505
(0x03000000):Text = 'CPI Converter Input Data Invalid'
(0x01000000):Insert = (
(0x03000000):Type = 5
(0x03000000):Text = 'string'
)
(0x01000000):Insert = (
(0x03000000):Type = 5
(0x03000000):Text = '4.4E0'
)
)
4.4E0 is a canonical representation of double so there really shouldn't be a problem.
I have an implementation with two message flows.
-Flow no1 reads the message, adds some metadata and publishes it.
-Flow no2 reads the published message and processes it further.
Both flows start with an MQInput node.
MQInput node of flow no1 raises an error whenever there is a double value in a canonical representation or a value with decimal point and no E and exponent in the message. Values without decimal point (2E-2, 3, 4E0 etc.) don't cause a problem.
What I find really interesting is that if I write a message with values:
Code: |
<xxxAmount>12312,3E-3</xxxAmount>
<yyyAmount>123E0</yyyAmount>
|
flow no1 processes the message without errors and publishes it with values:
Code: |
<xxxAmount>1.23123E+1</xxxAmount>
<yyyAmount>1.23E+2</yyyAmount>
|
i.e. it replaces the comma with period in xxxAmount and creates an almost canonical representation for both (+ sign is prohibited according to specification).
Now it's the MQInput node in flow no2 that raises the error while trying to parse these values. So it cannot parse its own representation of the value!
Quite confusing... Should I just use decimal instead of double? |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon May 28, 2007 8:35 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Somebody sold you a lot of crap:
Quote: |
4.4E0 is a canonical representation of double so there really shouldn't be a problem. |
4.4E0 is a representation of a FLOAT or DECIMAL.
NOTE we are not talking about java parsing / formatting rules here but ESQL rules. I know of Decimal and Float but I don't know of an ESQL double type...
See the manual about numeric types here  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mikko |
Posted: Mon May 28, 2007 9:27 pm Post subject: |
|
|
Newbie
Joined: 25 May 2007 Posts: 7
|
I'm not talking about java or ESQL datatypes, rather an element in an xml message of datatype double as it is specified in: http://www.w3.org/TR/xmlschema-2/#double. Here you find that 4.4E0 actually is a canonical representation of both float and double.
Evidently Message Broker does convert this into ESQL float - or tries to. |
|
Back to top |
|
 |
fjb_saper |
Posted: Tue May 29, 2007 2:32 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Could it be that you need a space ?
'4.4 E0' _________________ MQ & Broker admin |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue May 29, 2007 2:47 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Okay, let's be clear.
ONLY the MRM-XML parser will attempt to convert any XML fields into ESQL datatypes.
So I assume you're using MRM to parse this document? You don't say anywhere. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
mikko |
Posted: Mon Jun 04, 2007 2:38 am Post subject: |
|
|
Newbie
Joined: 25 May 2007 Posts: 7
|
Yes, I'm using MRM to be able to validate the messages. |
|
Back to top |
|
 |
kimbert |
Posted: Mon Jun 04, 2007 1:18 pm Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Sounds like a defect. You could change the type to 'string' as a workaround. If you really need to validate this field, you should raise a PMR. |
|
Back to top |
|
 |
shanson |
Posted: Tue Jun 05, 2007 12:28 am Post subject: |
|
|
 Partisan
Joined: 17 Oct 2003 Posts: 344 Location: IBM Hursley
|
Presumably you have this field defined as xs:double because you require 64-bit precision. The value you quote "4.4E0" can be represented by xs:float. Have you tried changing the logical type of the field to xs:float and seeing if you get the same error? |
|
Back to top |
|
 |
mikko |
Posted: Mon Jun 11, 2007 4:57 am Post subject: |
|
|
Newbie
Joined: 25 May 2007 Posts: 7
|
I get the same error with xs:float.
PMR is now open... |
|
Back to top |
|
 |
ChristianH |
Posted: Thu Sep 27, 2007 7:18 am Post subject: same error? |
|
|
Novice
Joined: 27 Sep 2007 Posts: 19 Location: London, UK
|
Hi,
It seems like I get the same error converting from CWF-Format (COBOL PIC9(11).9(7) format defined as External Decimal in the MRM (source message definition)
to double in a XML format.
(The Format looks fine in the message tree (e.g. 10.5), but when parsing to XML via RCD-Node an exception is thrown giving the canonical representation and telling that it could not be converted from string to double(!?!?).
When defining the output format as decimal in the xsd the conversion works fine -of course it only works when you don´t really need the double format)
Did you get an response to your PMR?
Is it a bug in the MessageBroker and is IBM fixing it?
Please let me know about the status of your PMR and if it´s a real bug or if you solved the problem a different way! |
|
Back to top |
|
 |
mikko |
Posted: Sun Sep 30, 2007 11:44 pm Post subject: |
|
|
Newbie
Joined: 25 May 2007 Posts: 7
|
It was a bug that occurred when processing XML messages containing double datatypes AND the broker locale decimal separator is other than a dot.
My Broker locale is Finnish and we use a comma instead of a dot.
I received a fixpack from IBM in august and I suppose it should be available somewhere. Here are the notes associated with the fix:
Notes
-----
This fix is for the following problem(s) :
A BIP5505E Data conversion failed error occurs when
XML messages containing datatype double are processed
by a broker running in a locale in which the decimal
separator is not a dot character. |
|
Back to top |
|
 |
ChristianH |
Posted: Mon Oct 01, 2007 12:42 am Post subject: |
|
|
Novice
Joined: 27 Sep 2007 Posts: 19 Location: London, UK
|
Thanks for the reply mikko!
This would explain the error I was getting as my Broker is running with a German locale.
Could you kindly provide some more information about your fix?
I would like to get it too and I wonder, if it is included in an official fixpack.
Did you get an APAR number with the fix?
Which version of the Broker Runtime are you using? |
|
Back to top |
|
 |
mikko |
Posted: Mon Oct 01, 2007 5:06 am Post subject: |
|
|
Newbie
Joined: 25 May 2007 Posts: 7
|
I'm running Broker version 6.0.0.3
You are probably looking for this: APAR IC53420
This is what the fix includes:
Files included
--------------
%MQSI_FILEPATH%\bin\bipbitstreamutilities.dll
%MQSI_FILEPATH%\bin\bipbitstreamutilities.pdb
Prerequisite level required
---------------------------
Websphere Message Broker for Windows, Version 6.0 at FP03
I also received the fixpack for AIX. |
|
Back to top |
|
 |
ChristianH |
Posted: Mon Oct 01, 2007 5:37 am Post subject: |
|
|
Novice
Joined: 27 Sep 2007 Posts: 19 Location: London, UK
|
|
Back to top |
|
 |
|