Author |
Message
|
EricCox |
Posted: Tue Sep 22, 2015 5:49 am Post subject: XMNSC, Message Broker 8.0.0.2 and TIMESTAMP Failing |
|
|
Master
Joined: 08 Apr 2011 Posts: 292
|
To all,
We had code using XMLNS parser and a TIMESTAMP field in XML content held in a STATE MSG Queue...this was all working.
We changed to the XMLNSC parser and store the TIMESTAMP in XML content. However, now the TIMESTAMP held in the STATE MSG Queue comes back with a T in it. Now when we try to CAST from the string coming out of the STATE MSG to the TIMESTAMP so we can do a calculation, adding up all elapsed time, the Broker throws a parsing error stating it can't convert a string, the T, to a TIMESTAMP. If we remove the T the CAST works and it cruises along.
Does anyone know why the T is now held inside the TIMESTAMP field, which got stored in the STATE MSG Queue?
Is this because the XMLNSC parser changes the way the TIMESTAMP data is output to XML Content? We did not experience this failure before changing to the XMLNSC parser.
I'll post more details as I learn more from the developers investigating.
Thanks,
E |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Sep 22, 2015 5:51 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
The XML standard defines a fixed string format for timestamp data.
If your field in the XML schema is a string, not a timestamp, then this doesn't apply.
The CAST you are using to turn a string into a timestamp is not using a format that matches the data in the string. _________________ chmod -R ugo-wx / |
|
Back to top |
|
 |
EricCox |
Posted: Tue Sep 22, 2015 5:56 am Post subject: with T it must be a string |
|
|
Master
Joined: 08 Apr 2011 Posts: 292
|
The ESQL which puts the timestamp value in the STATE MSG for storage is producing a string. It has a T in the value so it must be handled as a string. A proper timestamp in XML or ESQL can only have characters.
The question is 'why are we now seeing the T in the timestamp value which is retrieved and stored in the XML via ESQL?'.
We did not see this T in this value prior to using XMLNSC. |
|
Back to top |
|
 |
EricCox |
Posted: Tue Sep 22, 2015 5:59 am Post subject: Oops |
|
|
Master
Joined: 08 Apr 2011 Posts: 292
|
Correction:
A proper timestamp in XML or ESQL can only have numbers. A single T inside the timestamp means it has to be handled as string characters.
Again, why and where is the T introduced? |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Sep 22, 2015 6:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
The T will be produced by whatever is creating the timestamp, and casting it to a string.
You should verify that this is in the raw message data before it gets to Broker. I'd be really surprised if it wasn't, particularly since you are treating it as a string.
Even if it is, again, the format of the cast from character to timestamp will allow you to deal with it. _________________ chmod -R ugo-wx / |
|
Back to top |
|
 |
mgk |
Posted: Tue Sep 22, 2015 6:20 am Post subject: |
|
|
 Padawan
Joined: 31 Jul 2003 Posts: 1642
|
|
Back to top |
|
 |
EricCox |
Posted: Tue Sep 22, 2015 6:30 am Post subject: Finding Same |
|
|
Master
Joined: 08 Apr 2011 Posts: 292
|
I'm finding the same in the docs.
Thanks guys. Switching to XMLNSC bites us again.
I appreciate confirming what I'm seeing.
E |
|
Back to top |
|
 |
mqjeff |
Posted: Tue Sep 22, 2015 6:36 am Post subject: Re: Finding Same |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
EricCox wrote: |
Switching to XMLNSC bites us again. |
Don't think of it like that. Think of it like
"Switching to XMLNSC demonstrates where our code had previously not been compliant with the XML standard."
 _________________ chmod -R ugo-wx / |
|
Back to top |
|
 |
mgk |
Posted: Tue Sep 22, 2015 6:37 am Post subject: |
|
|
 Padawan
Joined: 31 Jul 2003 Posts: 1642
|
|
Back to top |
|
 |
Vitor |
Posted: Tue Sep 22, 2015 7:44 am Post subject: Re: Oops |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
EricCox wrote: |
A proper timestamp in XML or ESQL can only have numbers. A single T inside the timestamp means it has to be handled as string characters. |
Not true. That's a valid timestamp value as defined by ISO8601 _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Sep 22, 2015 7:44 am Post subject: Re: Finding Same |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
mqjeff wrote: |
EricCox wrote: |
Switching to XMLNSC bites us again. |
Don't think of it like that. Think of it like
"Switching to XMLNSC demonstrates where our code had previously not been compliant with the XML standard."
 |
 _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|