| Author |
Message
|
| SOLOHERO |
 Posted: Fri Mar 07, 2008 3:17 pm Post subject: Timestamp |
 |
|
Centurion
Joined: 01 Feb 2007
Posts: 107
|
Hi Guys,
Here is a scenario.
I created messageset using schema which has mixed date time formats like yy-mm-dd and some are GMT standard like(yyyy-MM-dd'T'HH:mm:ssZZZ) format , but when i get a request from consumer they are sending in 'yyyy-MM-dd'T'HH:mm:ss' format we are using XSLT for transformation. so i am not casting it in esql , and we dont want to manuplate string in XSLT ,
Problem: When we are transforming the consumer supplied datetime format , i am getting validation error cause broker is expecting (yyyy-MM-dd'T'HH:mm:ssZZZ) which is GMT and we are sending 'yyyy-MM-dd'T'HH:mm:ss' format.
Is there any thing i can do in message set properties to parse this message .
Thanks in advance
_________________
Thanks |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Mar 07, 2008 3:48 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well you are figuring out that a time stamp is not a timestamp unless it is qualified by the timezone...
So you may need to model your message and assume a default qualifier for your timezone. Modelling the message should allow you to set the dateformat at the element level...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| SOLOHERO |
| Posted: Fri Mar 07, 2008 4:46 pm Post subject: |
|
|
Centurion
Joined: 01 Feb 2007
Posts: 107
|
i cant modiyf the message cause consumer is not intrested in modifying it so consumer is sending '2008-02-20T12:00:00'(Eg format ) and in the schema it is defined as '2005-08-23T12:03:12+02:00'(Eg Format) .
_________________
Thanks |
|
| Back to top |
|
|
| kimbert |
| Posted: Sat Mar 08, 2008 7:09 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
This is a known defect, and there will be a fix in a future fix pack.
| Quote: |
| Is there any thing i can do in message set properties to parse this message . |
Yes. Open the message set properties, and deselect 'Derive DateTime format from logical type'. Once you've done that you specify a default format for all datetimes, and you can override it for individual elements/attributes if you need to. |
|
| Back to top |
|
|
| SOLOHERO |
| Posted: Sat Mar 08, 2008 8:33 pm Post subject: |
|
|
Centurion
Joined: 01 Feb 2007
Posts: 107
|
hi,
Future fix pack ..currently i got interimfix 11. do u mean this problem is fixed in 6.1
_________________
Thanks |
|
| Back to top |
|
|
| SOLOHERO |
| Posted: Sat Mar 08, 2008 8:37 pm Post subject: |
|
|
Centurion
Joined: 01 Feb 2007
Posts: 107
|
sorry i missed the messageset properties part explanation.
i agree with what you are saying if i change the indvidual field date time format. and if i get another version of schema i have to do the same so this is too much of manual work i dont think this is a recommended option.
Thanks for all your replies..
_________________
Thanks |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Mar 10, 2008 12:26 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| do u mean this problem is fixed in 6.1 |
No, I mean that the fix will be in a future fix pack for 6.0.2. As things stand, the only fix is the modify the DateTime template as described in my previous post.
| Quote: |
| this is too much of manual work |
Don't forget that the default applies to all dateTimes in the schema, so if you only use one type of dateTime field you can just change the default. |
|
| Back to top |
|
|
| SOLOHERO |
| Posted: Mon Mar 10, 2008 12:37 am Post subject: |
|
|
Centurion
Joined: 01 Feb 2007
Posts: 107
|
yes, i understand that but we are using multiple formats like DOB and so..
So, i dont thik default value is agud idea.
Let me talk to my consumers again if they can send gmt format.
Thanks a lot for all your replies guys.
_________________
Thanks |
|
| Back to top |
|
|
| long.hoang |
| Posted: Thu May 14, 2009 4:51 pm Post subject: |
|
|
Novice
Joined: 18 Sep 2007
Posts: 13
|
Hi,
I'm running into the same issue with Consumer supplying "2009-01-25T09:30:47" and the broker parsed it to "2009-01-25T09:30:47.000+11:00" but the client just want the date as it (without time zone)
- Tried "Use default dateTime format" as yyyy-MM-dd'T'THH:mm:ss and other date-only field (DOB) failed parsing (even with no "Strict DateTime checking)
- Tried "Use default dateTime format" as "IU" as someone suggest and time zone is stilled added
Changing every element fields is an enormous effort for us and we would like to avoid it 
Could you please let me know if the fix you guys mentioned has been released yet and would it help my case?
Thanks. |
|
| Back to top |
|
|
| long.hoang |
| Posted: Thu May 14, 2009 4:58 pm Post subject: |
|
|
Novice
Joined: 18 Sep 2007
Posts: 13
|
we running:
- IBM WebSphere Integration Developer 6.0.1.1 Interim Fix 007
- IBM WebSphere Message Broker Toolkit 6.0.2 Interim Fix 011 |
|
| Back to top |
|
|
| long.hoang |
| Posted: Sun May 17, 2009 4:01 pm Post subject: |
|
|
Novice
Joined: 18 Sep 2007
Posts: 13
|
We found a walk-around for this issue by putting an RDC-to-XMLNS node right after the RDC-To-MRM node (it does not work if the RDC-To-XMLNS node come after a Compute node)
The timestamp come out of the RDC-To-XMLNS node exactly as it was supplied by the Consumer. Not sure if this was intended but it sure beats changing all fields in the messageSet and retest all flows |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon May 18, 2009 2:06 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| We found a walk-around for this issue by putting an RDC-to-XMLNS node right after the RDC-To-MRM node (it does not work if the RDC-To-XMLNS node come after a Compute node) |
Sounds like a good way to burn lots of CPU 
If you do not need to process the date in your message flow, why not change the definition of the date/dateTime fields to xs:string instead of xs:dateTime? |
|
| Back to top |
|
|
| simon.starkie |
| Posted: Sun Jun 21, 2009 8:00 pm Post subject: |
|
|
Disciple
Joined: 24 Mar 2002
Posts: 180
|
Same problem here.
BIP5540E: Unable to parse value '2001-12-17T09:30:47.0Z ' using format string 'yyyy-MM-dd'T'HH:mm:ss ZZZ ' . Strict Datetime Checking = 1
This is an XML SOAP message
It was created from the WSDL with XMLSpy.
The problem involves standard xs:Date elements used by web services as shown here:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:m0="http://www.ncpdp.org/schema/SCRIPT">
<SOAP-ENV:Body>
<m:sendRegisterRx xmlns:m="http://oppr.kp.org/webservice/KPHCService">
<m0:Message version="" release="" HighestVersionSupported="">
<m0:Header>
<m0:To Qualifier=""/>
<m0:From Qualifier=""/>
<m0:MessageID>!</m0:MessageID>
<m0:RelatesToMessageID></m0:RelatesToMessageID>
<m0:SentTime>2001-12-17T09:30:47.0Z</m0:SentTime>
<m0:Security>
<m0:UsernameToken>
<m0:Username></m0:Username>
<m0:Password Type=""/>
<m0:Nonce></m0:Nonce>
<m0:Created>2001-12-17T09:30:47.0Z</m0:Created>
</m0:UsernameToken>
<m0:Sender>
<m0:SecondaryIden
We have a kludgey workaround so development could begin.
But it's very inconvenient and obviously won't be acceptable for Production.
The workaround involves adding the extra timezone digits.
For example:
From:
<Created>2001-12-17T09:30:47.0Z</Created>
To:
<Created>2001-12-17T09:30:47.000Z</Created>
| long.hoang wrote: |
Hi,
...
- Tried "Use default dateTime format" as yyyy-MM-dd'T'THH:mm:ss and other date-only field (DOB) failed parsing (even with no "Strict DateTime checking)
|
We tried that also.
Opened the message set properties,
deselected 'Derive DateTime format from logical type',
then specified a default format for all datetimes.
Also tried disabling Strict.
But still got the same error.
| kimbert wrote: |
| Quote: |
| do u mean this problem is fixed in 6.1 |
No, I mean that the fix will be in a future fix pack for 6.0.2. As things stand, the only fix is the modify the DateTime template as described in my previous post.
| Quote: |
| this is too much of manual work |
Don't forget that the default applies to all dateTimes in the schema, so if you only use one type of dateTime field you can just change the default. |
The workaround didn't work.
Which suggests the possibility that there may be another problem perhaps?
Regardless, this issue is a showtopper for us.
When can we please expect have a fix from IBM? |
|
| Back to top |
|
|
| simon.starkie |
| Posted: Mon Jun 22, 2009 10:03 am Post subject: |
|
|
Disciple
Joined: 24 Mar 2002
Posts: 180
|
Spent some time tinkerin' with the workaround.
I found that changing the default Date/Time format to yyyy-MM-dd works best for us for now now.
Obviously, this is not a long term solution since the application will need proper time values eventually.
So we still need a fix.
In the mean time, the workaround accomodates our input dates which can vary as indicated below (I think these are all legitimate ws:Date values).
<Created>2001-12-17T09:30:47.000Z</Created>
<DateOfBirth><Date>1967-08-13</Date></DateOfBirth> |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Jun 23, 2009 12:09 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| If you are using v6.1, you could switch to XMLNSC. |
|
| Back to top |
|
|
|
|
