| Author |
Message
|
| schroederms |
 Posted: Thu Feb 17, 2011 11:16 am Post subject: ISO8601 Time |
 |
|
Disciple
Joined: 21 Jul 2003
Posts: 169
Location: IA
|
I have hundreds of flows that running on version 6 using the XML parser, when grabbing the current_timestamp (like below), the timestamp in the XML looks correct:
<CREATE_GMTDATETIME>2011-02-16 15:34:46.617887</CREATE_GMTDATETIME>
But running the same flow using the XMLNSC parser (in this case on version 7), there now is a T in the timestamps, I guess for some ISO8601 standard. <CREATE_GMTDATETIME>2011-02-17T18:56:34.527129</CREATE_GMTDATETIME>
The problem is that each of the flows are called by many applications, which now can not handle a T in a date/time field, and they are aborting because of it.
I've tried to use a Format to get rid of the T, with no luck.
Does anyone know how this can be removed?
Thanks,
Mike |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Feb 17, 2011 11:24 am Post subject: Re: ISO8601 Time |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| schroederms wrote: |
| I've tried to use a Format to get rid of the T, with no luck. |
I'd have thought you could easily CAST the timestamp into the custom format you need (I say custom because ISO8601 has a T in it). Post some code and describe the "no luck".
I'll leave better minds and/or those with more experience with WMBv7 to discuss the change in behaviour between version and possible solutions. I'll simply point out that the example for CURRENT_TIMESTAMP in both the v6 & v7 versions shows no T in the output (i.e. not the ISO8601 format).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 17, 2011 11:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
How the XMLNSC domain will handle this depends rather a bit on whether or not you are trying to parse an XML document or serialize a message tree.
It will also depend even more on whether or not you are using a message set to work with native types.
In general, the XMLNSC parser expects that date and time data will be in the XML Schema defined native format - unless you have provided an indication using the schema - of what the format should be.
It's not clear from what you've said how much of any of the above applies to your situation. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Feb 17, 2011 12:13 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
There was a joke I heard when I first started writing code for a living (circa 1975). It went something like this.
Q: How do you tell a mature mainframe site?
A: When the number of Cobol routines to copy/manipulate the date exceeds 100.
Seriously, whay you are finding is what upgrade testing is all about.
In order not to end up like the MF site I mentioned above, you need to
consider using ONE common internal format for timestamps.
That might not be possible.
I know that some of the Hursley guys will be along to complain the Broker does abide by ISO standards. It does. But I've used timestamps OOTB since V5 that had a 'T' in the middle. My brain can't remember what 2.0.1 or 2.1 did in this area.
The issue is that the external apps can't cope with OOTB ISO format timestamps. Have you looked in detail at the ISO standard as well as the broker InfoCentre in relation to the may different formats that are ISO compliant. There could be one that meets your needs.
You can force the format in ESQL as well as in Message Sets. For outgoing messages then it may well be prudent to set the timestamp format in the message model.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 17, 2011 12:19 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It's not that Broker abides by the ISO standards.
It's that the XMLNSC parser abides by the XML standards - which is both the wanted and the correct thing to do.
It can be somewhat annoying that the ESQL normal datetime -> character result is in a DIFFERENT format than the XML Standard expects. But that is why the CAST allows for a FORMAT clause to format datetime data in the desired response.
Again, it's not clear what OP is doing or whether or not the ESQL default date->char conversion is at issue.
And any OOTB app that is "XML enabled" or "XML Compliant" and can't handle the XML Standard format might as well be producing a "15%" in a field that's defined as an xsd:decimal. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 17, 2011 12:28 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Again, it's not clear what OP is doing or whether or not the ESQL default date->char conversion is at issue. |
Though the OP does mention using the XML parser in v6 and the XMLNSC in v7. If I've understood where you're going with this, then this could be the source of the discrepancy as the parsers have always had slightly different behaviours (the XMLNSC being closer to the standard).
| mqjeff wrote: |
| And any OOTB app that is "XML enabled" or "XML Compliant" and can't handle the XML Standard format might as well be producing a "15%" in a field that's defined as an xsd:decimal. |
Yes, yes, it sucks to be me. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 17, 2011 12:39 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So even in v7, the XML parser is going to have different behavior than the XMLNSC parser.
The XMLNSC parser behavior is going to be more correct.
But again, you should be able to construct an XSD that will define the "wire level" datetime format of the XML field, and then instruct the XMLNSC parser to construct a tree using native data types rather than as plain Character fields, and the XSD specification will be used.
Or tell the XMLNSC parser that it's a Character field and then use ESQL CAST with FORMAT to turn it into datetime and vice versa. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Feb 17, 2011 1:13 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
There is good news and bad news.
The bad news first. I caused this problem, and I'll hold my hands up to this one. As mqjeff said, XMLNSC changed to writing XML and ISO-compliant date/time formats from v6.1 onwards. The 'T' is the only real difference. If we had not done this, there would have been many more people complaining about an XML parser that writes non-standard dates/times.
The good news? You can revert to the V6 ( and XML/XMLNS ) behaviour by setting an environment variable called 'MQSI_XMLNSC_V6_SERIALIZATION'. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 17, 2011 1:20 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kimbert wrote: |
| You can revert to the V6 ( and XML/XMLNS ) behaviour by setting an environment variable called 'MQSI_XMLNSC_V6_SERIALIZATION'. |
So you had the foresight to install an escape hatch? I'm impressed.
Dodged a trout there. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| schroederms |
| Posted: Thu Feb 17, 2011 1:20 pm Post subject: |
|
|
Disciple
Joined: 21 Jul 2003
Posts: 169
Location: IA
|
| So how do you get it to work in version 7? |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Feb 17, 2011 1:39 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| So how do you get it to work in version 7? |
The environment variable is still available in V7. Give it a try and let us know the result.
| Quote: |
So you had the foresight to install an escape hatch? I'm impressed.
|
To give credit where it is due, a colleague of mine did so. But I remembered it today. |
|
| Back to top |
|
|
| schroederms |
| Posted: Thu Feb 17, 2011 1:43 pm Post subject: |
|
|
Disciple
Joined: 21 Jul 2003
Posts: 169
Location: IA
|
| I'll try tomorrow, cant at the moment. Thanks. |
|
| Back to top |
|
|
| schroederms |
| Posted: Fri Feb 18, 2011 7:45 am Post subject: |
|
|
Disciple
Joined: 21 Jul 2003
Posts: 169
Location: IA
|
Great news, setting the variable to 'Y' removed the T.
You can see by the two simple PING REQUEST / RESPONSE test cases to SAP what I'm seeing.
The first set in red, is when the variable is NOT set. You can see where I'm setting the <ROUTER_MSGTIMES>, I'm using a XMLNSC parser in that flow(THE T EXISTS), and the PING_CREATE_DATETIME, I'm using a XML parser there because of iWAY nodes cannot support XMLNSC (version 6.1.05), and the T does not exist. Running on 6.1.05
The second set in green, all datetimes are looking good, all flows in this case creating this XML are using the XMLNSC parser!
What is the future on this issue? Will this variable exist moving forward? Will we have to "code" around this in the future? I can see this variable being forgotten about moving forward and this popping up again.
Any thoughts in make the T be an option to set if wanted, and not have the default using the T?
thanks for the help!
Mike
<?xml version="1.0" encoding="UTF-8"?>
<REQUEST>
<CONTROL>
<ORIGINATOR>LMS</ORIGINATOR>
<ORIGIN_DATETIME>20110217 13:02:28.269</ORIGIN_DATETIME>
<SERVICE>R3</SERVICE>
<FUNCTION>PING</FUNCTION>
<DESTINATION>
<INSTANCE>QAT</INSTANCE>
<CLIENT>150</CLIENT>
</DESTINATION>
<VERSION>1.0</VERSION>
<PERSISTENCE>N</PERSISTENCE>
<REALTIME>Y</REALTIME>
<AUDIT_LOG>Y</AUDIT_LOG>
<ROUTER_MSGTIMES>
<GMTMSGSTART>2011-02-17T19:02:28.298250</GMTMSGSTART>
<GMTMSGCOMPLETION>2011-02-17T19:02:28.298389</GMTMSGCOMPLETION>
</ROUTER_MSGTIMES>
</CONTROL>
<APP>
<R3>
<PING>0</PING>
</R3>
</APP>
<STATUS>
<CODE>0</CODE>
<DESCRIPTION>SUCCESSFUL</DESCRIPTION>
</STATUS>
</REQUEST>
<?xml version="1.0"?>
<RESPONSE>
<CONTROL>
<ORIGINATOR>LMS</ORIGINATOR>
<ORIGIN_DATETIME>20110217 13:02:28.269</ORIGIN_DATETIME>
<SERVICE>R3</SERVICE>
<FUNCTION>PING</FUNCTION>
<DESTINATION>
<INSTANCE>QAT</INSTANCE>
<CLIENT>150</CLIENT>
</DESTINATION>
<VERSION>1.0</VERSION>
<PERSISTENCE>N</PERSISTENCE>
<REALTIME>Y</REALTIME>
<AUDIT_LOG>Y</AUDIT_LOG>
<ROUTER_MSGTIMES>
<GMTMSGSTART>2011-02-17T19:02:28.298250</GMTMSGSTART>
<GMTMSGCOMPLETION>2011-02-17T19:02:28.298389</GMTMSGCOMPLETION>
</ROUTER_MSGTIMES>
</CONTROL>
<STATUS>
<CODE>0</CODE>
<DESCRIPTION>COMPLETED</DESCRIPTION>
<CREATE_DATETIME>2011-02-17 13:02:28.824391</CREATE_DATETIME>
<CREATE_GMTDATETIME>2011-02-17 19:02:28.824391</CREATE_GMTDATETIME>
</STATUS>
<APP>
<PING_STATUS>
<PING_CODE>0</PING_CODE>
<PING_DESCRIPTION>COMPLETED</PING_DESCRIPTION>
<PING_CREATE_DATETIME>2011-02-17 13:02:28.824391</PING_CREATE_DATETIME>
</PING_STATUS>
</APP>
<UPDATE_MESSAGE_DETAIL>YES</UPDATE_MESSAGE_DETAIL>
</RESPONSE>
<?xml version="1.0" encoding="ISO-8859-1"?>
<REQUEST>
<CONTROL>
<ORIGINATOR>Schroeder</ORIGINATOR>
<ORIGIN_DATETIME>20110216 14:52:34.940</ORIGIN_DATETIME>
<SERVICE>R3</SERVICE>
<FUNCTION>PING</FUNCTION>
<DESTINATION>
<INSTANCE>QAT</INSTANCE>
<CLIENT>150</CLIENT>
</DESTINATION>
<VERSION>1.0</VERSION>
<PERSISTENCE>N</PERSISTENCE>
<REALTIME>Y</REALTIME>
<AUDIT_LOG>Y</AUDIT_LOG>
<ROUTER_MSGTIMES>
<GMTMSGSTART>2011-02-18 15:23:23.285509</GMTMSGSTART>
<GMTMSGCOMPLETION>2011-02-18 15:23:23.285599</GMTMSGCOMPLETION>
</ROUTER_MSGTIMES>
</CONTROL>
<APP>
<R3>
<PING>0</PING>
</R3>
</APP>
<STATUS>
<CODE>0</CODE>
<DESCRIPTION>SUCCESSFUL</DESCRIPTION>
</STATUS>
</REQUEST>
<?xml version="1.0" encoding="ISO-8859-1"?>
<RESPONSE>
<CONTROL>
<ORIGINATOR>Schroeder</ORIGINATOR>
<ORIGIN_DATETIME>20110216 14:52:34.940</ORIGIN_DATETIME>
<SERVICE>R3</SERVICE>
<FUNCTION>RFC_PING_AND_WAIT</FUNCTION>
<DESTINATION>
<INSTANCE>QAT</INSTANCE>
<CLIENT>150</CLIENT>
</DESTINATION>
<VERSION>1.0</VERSION>
<PERSISTENCE>N</PERSISTENCE>
<REALTIME>Y</REALTIME>
<AUDIT_LOG>Y</AUDIT_LOG>
<ROUTER_MSGTIMES>
<GMTMSGSTART>2011-02-18 15:23:23.285509</GMTMSGSTART>
<GMTMSGCOMPLETION>2011-02-18 15:23:23.285599</GMTMSGCOMPLETION>
</ROUTER_MSGTIMES>
</CONTROL>
<STATUS>
<CODE>0</CODE>
<DESCRIPTION>COMPLETED</DESCRIPTION>
<CREATE_DATETIME>2011-02-18 09:23:23.467227</CREATE_DATETIME>
<CREATE_GMTDATETIME>2011-02-18 15:23:23.467227</CREATE_GMTDATETIME>
</STATUS>
<APP>
<PING_STATUS>
<PING_CODE>0</PING_CODE>
<PING_DESCRIPTION>COMPLETED</PING_DESCRIPTION>
<PING_CREATE_DATETIME>2011-02-18 09:23:23.467227</PING_CREATE_DATETIME>
</PING_STATUS>
</APP>
<UPDATE_MESSAGE_DETAIL>YES</UPDATE_MESSAGE_DETAIL>
</RESPONSE> |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 18, 2011 8:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
again, if nothing else, you can tweak the schema you are using with XMLNSC to mark the field as a Character field rather than a timestamp/datetime/gmttimstamp/etc...
Then you can use ESQL to CAST the timestamp to a character value using the FORMAT of your choice. |
|
| Back to top |
|
|
| schroederms |
| Posted: Fri Feb 18, 2011 8:05 am Post subject: |
|
|
Disciple
Joined: 21 Jul 2003
Posts: 169
Location: IA
|
I've been fighting this for some time, and I tried that. I believe when I did that I got the complete char value in my "casted" variable:
"TIMESTAMP xx/xx/xxxx hh:MM:ss" etc, and I'm not sure where I left it.
My point is, this was introduced and causes everything to break immediately downstream. Having to change 200 - 300 flows, everywhere gmt out curr time is used is not to appealing.
My two cents. |
|
| Back to top |
|
|
|
|
