| Author |
Message
|
| srikanth av |
 Posted: Wed Jul 19, 2006 3:11 am Post subject: Parser Exception when using RCD node in MB5.0 |
 |
|
Apprentice
Joined: 30 Jun 2005
Posts: 37
|
Hi,
My environment is MB v5.0,Window 2000,MQ 5.3
In a flow i am using ResetContentDescriptor node which sets the MRM domain properties for output message for which the current domain is XMLNS.In RCD node i am resetting domain,message set,message type and also message format.
Here i am getting parser exception like this.
ImbRecoverable Exception caught from Worker ->parseNext
Can anyone suggest where i am going wrong and how to rectify this problem.
Thanks in advance.
_________________
a v srikanth |
|
| Back to top |
|
 |
| shalabh1976 |
| Posted: Wed Jul 19, 2006 3:40 am Post subject: |
|
|
Partisan
Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India
|
Are you sure that the input message is in a format that can be parsed by the MRM parser ?
Have you checked the InputExceptionList ?
_________________
Shalabh
IBM Cert. WMB V6.0
IBM Cert. MQ V5.3 App. Prog.
IBM Cert. DB2 9 DB Associate |
|
| Back to top |
|
|
| srikanth av |
| Posted: Wed Jul 19, 2006 3:52 am Post subject: |
|
|
Apprentice
Joined: 30 Jun 2005
Posts: 37
|
I am sure the input message can be parsed by MRM parser.
Actually i am able to see the "ImbRecoverable Exception caught from Worker ->parseNext " exception in the body of the message under MRM domain when i debug and at this moment i don't see any Exceptionlist populating and control is going to subflow which is throwing exception finally.
After RCD node i am losing some amount of data in the body of the message due the above exception.
_________________
a v srikanth |
|
| Back to top |
|
|
| jbanoop |
| Posted: Wed Jul 19, 2006 4:05 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
Cofirm that the same can be parsed by MRM for the messageset that you created by testing it on the input node itself.
Set the properties of the input node to parse it at the input node itseld.
If it fails (which i suspect it will) then the issue is with input and/or the message set you have defined.
RCD just changes the values of the 3 fields in MQMD. When the message returns to the flow (from the RCD) the parse happens with the changed values and that is where your code is failing.
Hope it helps,
Anoop |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jul 19, 2006 4:43 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| jbanoop is correct - you are definitely getting a parsing error. MRM parsing exceptions always come in groups of three, but you have only quoted the final one. I suggest that you take a user trace of the parse - then you will see the other two parsing exceptions, and you will get a better idea of what gone wrong. |
|
| Back to top |
|
|
| srikanth av |
| Posted: Wed Jul 19, 2006 6:47 am Post subject: |
|
|
Apprentice
Joined: 30 Jun 2005
Posts: 37
|
Hi,
As you said i have developed a flow with MRM as domain in MQInput node,Compute node,MQOutput node and tested the flow.
I am getting the same parser exception as above in the message body under MRM domain but i don't see exceptionList populating and also i am able to see the entire message in the output queue.
So why i am getting the parser exception when i debug.Can anyone throw some light on this!!!
_________________
a v srikanth |
|
| Back to top |
|
|
| jbanoop |
| Posted: Wed Jul 19, 2006 9:37 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
srikanth av: What you are observing is correct.
And i suspect that becuase of the parse error, the output node is bypassing any reparsing it would do and dumping the message out.
Kimbert: How is it that the message is allowed to pass through the input node (with validation turned on and failure behaviour set to exeption and parse timing immediate) with the parsing error ?
Yes It would throw an exception when the message body is tried to be accessed but shouldnt it just go to the failure terminal ?
Is it to enable partially parsed messages to be processed ? :-/
Regards,
Anoop |
|
| Back to top |
|
|
| shrek |
| Posted: Thu Jul 20, 2006 3:44 am Post subject: |
|
|
Acolyte
Joined: 19 Feb 2005
Posts: 61
Location: Gudivada,India
|
| Can you please post the user trace? Thanks |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jul 20, 2006 6:40 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Kimbert: How is it that the message is allowed to pass through the input node (with validation turned on and failure behaviour set to exeption and parse timing immediate) with the parsing error ? |
I don't know. It sounds very strange to me. I'd like to know a little more about the message flow.
srikanth av: Can you cut down the message flow to the bare bones - MQInput node with Parse Timing set to 'Immediate'. Out terminal goes to an output queue, and error terminal to an error queue. Take a user trace of that scenario, and post here. |
|
| Back to top |
|
|
| srikanth av |
| Posted: Thu Jul 20, 2006 9:30 am Post subject: Error identified in the input message |
|
|
Apprentice
Joined: 30 Jun 2005
Posts: 37
|
Hi,
I have identified the error in my input message.In my input message there is a timestamp value which the broker is unable to parse.Actaully in the xml schema the datatype of the value is declared as xs:dateTime,which the broker is unable to parse it to TimeStamp value.
I have modified my MQInput node settings like this Validate "Content and Value ,Failure Action is set to "Local Error Log" and timing "Immediate".Then the it is throwing exception and the trace is like this:
-----------------------------------------------------------------------------------
XML data conversion error.
Error converting characters at position 2761 to logical type 'DateTime' in message 'BizData_Payload'.
Unable to parse value 2006-06-15T09:30:47.0Z using format string yyyy-MM-dd'T'HH:mm:ssZZZ. Error code: 9.
Check and possibly correct the string being passed to the datetime parser.
-----------------------------------------------------------------------------------
Please tell me what is the wrong with the above timestamp String value i am passing to the flow.
I have tried in another like,i have modified my message definition file such that i put xs:String instead of xs:dataTime for timeStamp value.Then it is working.But is there any another solution.
Your suggestions are very appreciated.
Thanks
_________________
a v srikanth |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Jul 20, 2006 11:47 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
|
| Back to top |
|
|
| srikanth av |
| Posted: Fri Jul 21, 2006 8:06 am Post subject: |
|
|
Apprentice
Joined: 30 Jun 2005
Posts: 37
|
Hi,
Thank you very much Kimbert for your information.
When i tried with "2006-06-15T09:30:47 -05:00" as timestamp value then it is working.That means the above one matches with "yyyy-MM-dd'T'HH:mm:ssZZZ" format string the dateTime parser uses.
I need some more infomation like,is the dateTime parser always uses the above format string or is there any way so that we can specify the format string for the dateTime parser.Because in my task i am getting timestamp values like "2006-06-15T09:30:47.0Z " this one only and the broker need to parse those values.
Can anyone give some more information on this.
Thanks in advance.
_________________
a v srikanth |
|
| Back to top |
|
|
| kspranava |
| Posted: Fri Jul 21, 2006 8:38 am Post subject: |
|
|
Centurion
Joined: 27 Apr 2003
Posts: 124
|
Hi srikanth av,
You can set your own time formats by enabling the option 'Use default time format' and supply a format. This option is available in the physical layer format of the message set.
Thanks,
kspranava. |
|
| Back to top |
|
|
| jbanoop |
| Posted: Sat Jul 22, 2006 12:18 am Post subject: |
|
|
Chevalier
Joined: 17 Sep 2005
Posts: 401
Location: SC
|
Kimbert:
Flow is just an input node (with parser set to XML) connected to output node.
Broker version is
BIP8996I: Version: 500
BIP8997I: Product: WebSphere MQ Integrator
BIP8998I: CMVC Level: S500-CSD05
BIP8999I: Build Type: Production
The user trace follows. Seems both show up similarly.
With proper XML
-----------------
2006-07-22 11:07:50.599880 3532 UserTrace BIP2638I: The MQ output node 'ConfigurationMessageFlow.outputNode' attempted to write a message to queue 'SYSTEM.BROKER.UTILITY.44C1C01E02260020' connected to queue manager 'WBRK5_QM'. The MQCC was '0' and the MQRC was '0'.
2006-07-22 11:07:50.599960 3532 UserTrace BIP2622I: Message successfully output by output node 'ConfigurationMessageFlow.outputNode' to queue 'SYSTEM.BROKER.UTILITY.44C1C01E02260020' on queue manager 'WBRK5_QM'.
2006-07-22 11:08:18.207029 2616 UserTrace BIP6060I: Parser type 'Properties' created on behalf of node 'TestFailureBehaviour.TEST.IN' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2006-07-22 11:08:18.207143 2616 UserTrace BIP6061I: Parser type 'MQMD' created on behalf of node 'TestFailureBehaviour.TEST.IN' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value 'MQHMD' from previous parser.
2006-07-22 11:08:18.207258 2616 UserTrace BIP6061I: Parser type 'XML' created on behalf of node 'TestFailureBehaviour.TEST.IN' to handle portion of incoming message of length '3478' bytes beginning at offset '364'. Parser type selected based on value 'XML' from previous parser.
2006-07-22 11:08:18.207323 2616 UserTrace BIP2632I: Message received and propagated to 'out' terminal of MQ input node 'TestFailureBehaviour.TEST.IN'.
2006-07-22 11:08:35.857528 3532 UserTrace BIP2632I: Message received and propagated to 'out' terminal of MQ input node 'ConfigurationMessageFlow.InputNode'.
2006-07-22 11:08:35.857666 3532 UserTrace BIP6060I: Parser type 'Properties' created on behalf of node 'ConfigurationMessageFlow.InputNode' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2006-07-22 11:08:35.857746 3532 UserTrace BIP6061I: Parser type 'MQMD' created on behalf of node 'ConfigurationMessageFlow.InputNode' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value 'MQHMD' from previous parser.
2006-07-22 11:08:35.857913 3532 UserTrace BIP6061I: Parser type 'XML' created on behalf of node 'ConfigurationMessageFlow.InputNode' to handle portion of incoming message of length '228' bytes beginning at offset '364'. Parser type selected based on value 'XML' from previous parser.
With junk (Not XML) (showing parsing errors in the debugger)
-----------------------------------------------------------------------
3532 UserTrace BIP2638I: The MQ output node 'ConfigurationMessageFlow.outputNode' attempted to write a message to queue 'SYSTEM.BROKER.UTILITY.44C1C01E02280020' connected to queue manager 'WBRK5_QM'. The MQCC was '0' and the MQRC was '0'.
2006-07-22 11:10:18.241046 3532 UserTrace BIP2622I: Message successfully output by output node 'ConfigurationMessageFlow.outputNode' to queue 'SYSTEM.BROKER.UTILITY.44C1C01E02280020' on queue manager 'WBRK5_QM'.
2006-07-22 11:10:42.169963 2616 UserTrace BIP6060I: Parser type 'Properties' created on behalf of node 'TestFailureBehaviour.TEST.IN' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2006-07-22 11:10:42.170085 2616 UserTrace BIP6061I: Parser type 'MQMD' created on behalf of node 'TestFailureBehaviour.TEST.IN' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value 'MQHMD' from previous parser.
2006-07-22 11:10:42.170188 2616 UserTrace BIP6061I: Parser type 'XML' created on behalf of node 'TestFailureBehaviour.TEST.IN' to handle portion of incoming message of length '281' bytes beginning at offset '364'. Parser type selected based on value 'XML' from previous parser.
2006-07-22 11:10:42.170253 2616 UserTrace BIP2632I: Message received and propagated to 'out' terminal of MQ input node 'TestFailureBehaviour.TEST.IN'.
2006-07-22 11:10:46.102745 2616 UserTrace BIP2638I: The MQ output node 'TestFailureBehaviour.TEST.OUT' attempted to write a message to queue 'TEST.OUT' connected to queue manager ''. The MQCC was '0' and the MQRC was '0'.
2006-07-22 11:10:46.102848 2616 UserTrace BIP2622I: Message successfully output by output node 'TestFailureBehaviour.TEST.OUT' to queue 'TEST.OUT' on queue manager ''.
2006-07-22 11:10:51.495876 3532 UserTrace BIP2632I: Message received and propagated to 'out' terminal of MQ input node 'ConfigurationMessageFlow.InputNode'.
2006-07-22 11:10:51.495998 3532 UserTrace BIP6060I: Parser type 'Properties' created on behalf of node 'ConfigurationMessageFlow.InputNode' to handle portion of incoming message of length 0 bytes beginning at offset '0'.
2006-07-22 11:10:51.496078 3532 UserTrace BIP6061I: Parser type 'MQMD' created on behalf of node 'ConfigurationMessageFlow.InputNode' to handle portion of incoming message of length '364' bytes beginning at offset '0'. Parser type selected based on value 'MQHMD' from previous parser.
2006-07-22 11:10:51.496593 3532 UserTrace BIP6061I: Parser type 'XML' created on behalf of node 'ConfigurationMessageFlow.InputNode' to handle portion of incoming message of length '228' bytes beginning at offset '364'. Parser type selected based on value 'XML' from previous parser.
Anoop |
|
| Back to top |
|
|
| kimbert |
| Posted: Sat Jul 22, 2006 12:51 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
OK - that user trace doesn't tell me very much, for the following reasons:
1. No parsing occurred, because message broker never parses unless
a) The message flow accesses a field in the message. ( and even then it stops once the field reference has been resolved )
b) Validation is enabled, and Validation Timing is 'immediate' (v5)
c) Parse Timing is set to 'Immediate' ( v6 only )
2. Even if your message flow did trigger some parsing, the results would not be very helpful because you have changed the domain in the MQInput node from 'MRM' to 'XML'. Was there a reason for this change?
3. The really strange part is that you seem to be getting a parser exception, and yet the message is not going to the failure terminal. Please insert Trace nodes between the out/failure terminals and their MQOutput nodes. Set pattern to '${Root} and Destination to User Trace. ( Sorry for not mentioning about the trace node in my previous post ) |
|
| Back to top |
|
|
|
|
