| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| EDIFACT parsing problem |
« View previous topic :: View next topic » |
| Author |
Message
|
| martinrydman |
 Posted: Mon Jan 17, 2005 6:48 am Post subject: EDIFACT parsing problem |
 |
|
Centurion
Joined: 30 Jan 2004
Posts: 139
Location: Gothenburg, Sweden
|
Hi,
I'm using the IBM Dublin supplied TDS MRM for EDIFACT. We need to get to some of the first fields in this definition to determine if the bitstream needs to be amended with a UNA segment.
I was hoping to rely on the fact that the parser only parses the parts of the tree that I access, so my strategy was this:
-Input the message via MQInput with the EDIFACT MRM as default
-Inspect some of the UNB and UNH elements to determine if an UNA must be added as the first segment
-Reset the content to BLOB, add UNA, reset again to MRM
Now, it seems that as soon as I call CopyEntireMessage, the whole tree is parsed before (while?) it is copied, because I get a CPI Converter Input Data Invalid error, exactly the problem the whole UNA-scheme is designed to solve.
So my question is: When the tree gets copied using CopyEntireMessage, is it also completely parsed? If so, I will have to resort to analyzing the bitstream outside of the MRM domain, and when UNA is safely in place, reset it to MRM.
Or can I inspect fields using a compute-node without touching the tree. I.e. only look at InputRoot, without touching OutpuRoot. What happens if I copy nothing?
/Martin |
|
| Back to top |
|
 |
| wooda |
| Posted: Wed Jan 19, 2005 5:43 am Post subject: |
|
|
Master
Joined: 21 Nov 2003
Posts: 265
Location: UK
|
Hi Martyn -
CopyEntireMessage is the same as SET OutputRoot = InputRoot;
This in itself will not cause a parse.
Accesing invidual fields in the input message will cause the input to be parsed.
And altering individual fields in the output will cause the output to be built up by serializing individual fields in the message (instead of just copying the input bitstream).
So in your case I imagine the error occurs when you are inspecting the input message UNB/UNH headers.
Please could insert your ESQL in here so we can see exactly what you are doing.
Or better still as usertrace of the flow in operation would be helpful.
In answer to your question.
| Quote: |
So my question is: When the tree gets copied using CopyEntireMessage, is it also completely parsed? If so, I will have to resort to analyzing the bitstream outside of the MRM domain, and when UNA is safely in place, reset it to MRM.
Or can I inspect fields using a compute-node without touching the tree. I.e. only look at InputRoot, without touching OutpuRoot. What happens if I copy nothing? |
CopyEntireMessage will not in itself cause a parse unless you also alter the message. If you inspect the Input tree but don't change the output tree (apart from CopyEntireMessage) then you will cause a parse of the input tree in order for you to examine fields in the input but this will not effect the output tree. |
|
| Back to top |
|
|
| martinrydman |
| Posted: Wed Jan 19, 2005 8:17 am Post subject: |
|
|
Centurion
Joined: 30 Jan 2004
Posts: 139
Location: Gothenburg, Sweden
|
Hi, Wooda
thanks! I fiddled quite a bit with my problem, but didn't get lucky. So I resorted to plan B, i.e. get the message as BLOB, convert it to CHAR, extract the bits i needed using ESQL string functions, adding the UNA to the string and then BLOB:ing it again. After that, a ResetContentDescriptor was able to process the message successfully.
I guess that if I get the message using MRM-domain to get the fields I wanted, then try to reset it to BLOB will force a parse of the tree.
Anyway, now it works.
/Martin |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
