| Author |
Message
|
| birger.r |
 Posted: Tue Jun 22, 2010 3:04 am Post subject: Timestamp parsing issue |
 |
|
Novice
Joined: 22 Jun 2010
Posts: 10
|
Hi,
I am using Webspehere Message Broker 6.0.2 on MQ 6.1.
I am having two message flows. Flow 1 is generating a XML message using the MRM parser, Flow 2 is reading this message from a queue and parsing it using the MRM parser as well. The message set is the same. The flows run in two different execution groups, the message set is deployed to both exec groups. I have deployed the same bar file to both execution groups.
Flow 1 is setting two fields:
SET OutputRoot.MRM.stockLevelHeader.readingDate = UTILITY.getDateTimeFromTimestamp(readingDateString);
SET OutputRoot.MRM.stockLevelHeader.documentTimestamp = UTILITY.getDateTimeFromTimestamp(readingDateString);
As you can see, both fields are set to the same value. As long as I use only one of the fields, flow 2 works perfectly. As soon as I have both (and I need for certain reasons both fields), I see in the message that is produced by Flow 1:
<readingDate>2010-06-21T18:05:00+02:00</readingDate>
<documentTimestamp>2010-06-21 18:05:00</documentTimestamp>
Both fields are defined as xs:dateTime in the message set.
Flow 2 is then trying to process the message. I am getting this exception:
BIP5285E: Message Translation Interface Parsing Errors have occurred: Message Set Name : 'MS_GBO' Message Set Level : '1' Message Format : 'XML1' Message Type Path : 'stockLevelMessage' : PRINCE_T_BROKER1.d9cab17e-1501-0000-0080-cb92673353e5: /build/S600_P/src/MTI/MTIforBroker/MtiImbParser2/MtiImbParser.cpp: 619: MtiImbParser::parseRightSibling: ComIbmMQInputNode: GBO2DB_STOCK_LEVEL#FCMComposite_1_5.SUBFLOW/INPUT#FCMComposite_1_6
BIP5404E: XML data conversion error. : PRINCE_T_BROKER1.d9cab17e-1501-0000-0080-cb92673353e5: /build/S600_P/src/cpi/pwf/xml/xmlhandler.cpp: 1896: XMLHandler::convertStringToData: :
BIP5540E: Unable to parse value 2010-06-21 18:05:00 using format string yyyy-MM-dd'T'HH:mm:ssZZZ. Strict Datetime Checking = 0. : PRINCE_T_BROKER1.d9cab17e-1501-0000-0080-cb92673353e5: /build/S600_P/src/cpi/bsutils/pwffrmtr.cpp: 478: PWFDateTimeFormatter::parse: :
I am a bit lost here. Any help / idea is greatly appreciated.
Cheers, Birger. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jun 22, 2010 4:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Why are you using MRM to generate XML?
Are both fields defined identically in the message set?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| birger.r |
| Posted: Tue Jun 22, 2010 4:21 am Post subject: |
|
|
Novice
Joined: 22 Jun 2010
Posts: 10
|
I don't know why MRM it used, but it is a guideline to use it.
Both fields are defined identically. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 22, 2010 4:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The error is correct, the data that is trying to be parsed is NOT matching the pattern you're using.
<documentTimestamp>2010-06-21 18:05:00</documentTimestamp>
is not parsable using yyyy-MM-dd'T'HH:mm:ssZZZ. There's no 'T'.
So either there's a bug in the MRM parser where it decides to output two elements with the exact same definition OR there's a difference in the definition OR one of the elements in the logical tree that's passed to the parser is not matched against the model.
Take a user trace. I forget if 6.0.x Trace node output will include parser specific types, but it's worth a shot. If the element that's being output wrong has a different parser specific type (0x030000 for example) then that's the issue. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 22, 2010 5:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| birger.r wrote: |
| I don't know why MRM it used, but it is a guideline to use it. |
It's not IBM's guideline in v6 & later.
Also if it's only a guideline, don't follow it... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jun 22, 2010 5:33 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
One of the reasons for the XMLNSC upgrade in v6.1 was to provide an XML parser that does what the XML Schema specification says. The MRM parser offers some great parsing and validation features, but IBM has has never claimed that MRM is 100% compliant with the XML Schema standard.
That's why we recommend XMLNSC for XML parsing and writing these days. |
|
| Back to top |
|
|
| birger.r |
| Posted: Tue Jun 22, 2010 5:56 am Post subject: |
|
|
Novice
Joined: 22 Jun 2010
Posts: 10
|
Thanks for your replies.
mqjeff lead me to the solution. One field before these two was set to NULL, but was defined as mandatory. Setting this field to a dummy value helped. |
|
| Back to top |
|
|
|
|
