|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Which parser and message type |
« View previous topic :: View next topic » |
Author |
Message
|
reachsatish |
Posted: Wed Jul 25, 2007 3:21 pm Post subject: Which parser and message type |
|
|
Newbie
Joined: 18 Jul 2007 Posts: 6
|
I am new to WMB v6.0. We get messages in one of the following 7 formats -
#ABCD 0001ABCDE000707160124ABC1 /
#ABCD 0001ABCDE000707020445ABC1 ABC2 /
#ABCD 0001ABCDE000707020445ABC1 ABC2 ABC3 /
#ABCD 0001ABCDE000707020445ABC1 ABC2 ABC3 ABC4 /
#ABCD 0001ABCDE000707020445ABC1 ABC2 ABC3 ABC4 ABC5 /
#ABCD 0001ABCDE010707160224ABC1 /071970000/0036ABCD/
#ABCD 0001ABCDE000707160224ABC1 /071970224/WXYZABCD59300707160224/
The first 38 characters are always fixed length and same format for all 7 message types.
The first 5 message types, the last field (8 bytes) gets repeated upto 5 times. The last 2 formats have extended data. The extended portion is fixed.
I have 2 questions -
1. Which format is good to handle the above messages - TDS or CWF?
2. Do we need to have 7 different message types or can do with fewer message types?
I went through the WMB help and could not figure out what to do. Please help.
Thanks
Satish
Last edited by reachsatish on Thu Jul 26, 2007 12:24 pm; edited 2 times in total |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Jul 25, 2007 5:21 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
If you have a repeating field that repeats an unknown number of times, then you can't use CWF. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
kimbert |
Posted: Thu Jul 26, 2007 1:49 pm Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Quote: |
If you have a repeating field that repeats an unknown number of times, then you can't use CWF. |
...unless it is the final field in the message, and you are on v6. Or unless you have a repeat count field which occurs at some point before it in the message.
reachsatish: You need TDS - that much is clear. Can you please answer the following questions:
- Your example messages do not have a fixed 38-character header, which seems to contradict your statement.
- There are spaces in your example messages. Some of them are in the 'fixed' header. It's unusual to include redundant space in fixed-length data. Do the real messages contain spaces?
- Is it true that the extended data always begins with a / and ends with a /, and individual items of extended data are separated by / ? |
|
Back to top |
|
 |
jefflowrey |
Posted: Thu Jul 26, 2007 3:34 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
kimbert wrote: |
...unless it is the final field in the message, and you are on v6. Or unless you have a repeat count field which occurs at some point before it in the message. |
OR the first part of it is fixed, and can be used as a "message key" (and you're on v6)...
OR all of the repeats are guaranteed to occur within the boundaries of a fixed width (heavily padded) field - in which case you can use CWF and treat it as a single field, and then use SUBSTRING to parse it.
OR...
But it's entirely easier to go with TDS at this point. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
reachsatish |
Posted: Fri Jul 27, 2007 7:47 am Post subject: |
|
|
Newbie
Joined: 18 Jul 2007 Posts: 6
|
kimbert wrote: |
Can you please answer the following questions:
- Your example messages do not have a fixed 38-character header, which seems to contradict your statement.
- There are spaces in your example messages. Some of them are in the 'fixed' header. It's unusual to include redundant space in fixed-length data. Do the real messages contain spaces?
- Is it true that the extended data always begins with a / and ends with a /, and individual items of extended data are separated by / ? |
- The format for the 38 characters are always same. It is as follows -
1 - Always #
next 4 - origin
next 4 - sub-origin (usually spaces)
next 4 - Message Number
next 5 - System
next 10 - date time
next 4 - destination
next 4 - sub-destination (usually spaces)
- Yes, the real data contains spaces. It is maily for sub-origin and sub-destination which is not used most of the times.
- Yes, the extended data always begins with / and ends with /. In fact the whole message always ends with a /. In case of extended data additional / will be added.
All the above is just header part of the message. The whole message will be 'header/payload/trailer' We plan to seperate the header, payload and trailer using ESQL and the use the PARSE the header and trailer. The payload is not inspected in WMB. It is sent downstream system where it is handled.
Thanks for your help.
Thanks
Satish |
|
Back to top |
|
 |
kimbert |
Posted: Mon Jul 30, 2007 3:24 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
This is quite a difficult message format, but you can do this with a single message definition.
I'm assuming that
- the first occurrence ( ABC1 ) is always present
- the spaces which separate ABC1 ABC2 are not required in the field value.
( so the message tree will contain 'ABC1' instead of 'ABC1 ' )
Based on these assumptions, I suggest that you start with the following model.
I expect it will need some fine-tuning. If you do not get the expected result, you should inspect the message
tree immediately after the input node. Use a Trace node or the debugger for that.
Code: |
Message Element
MessageType [Local complex type, Data Element Separation='Tagged Delimited',
Delimiter='UNUSED']
FixedHeader Element
FixedHeaderType [Local complex type, Data Element Separation=Fixed Length]
subfield1
subfield2
etc
ABCGroup [Group, Composition=sequence,
Data Element Separation=All Elements Delimited,
Delimiter = ' /'
Group Terminator= ' /']
ABCElement [ minOccurs=1, maxOccurs=5,
Repeating Element Delimiter='<SPACE>']
ExtendedDataGroup [Group, Composition=Sequence
minOccurs=0,
Data Element Separation=All Elements Delimited,
Delimiter='/',
Group Terminator='/']
ExtendedData1
ExtendedData2
|
If this does not work, please carefully note the full text and the error number of any errors reported by the TDS parser. Taking a User Trace
can be an excellent way of diagnosing parsing errors. |
|
Back to top |
|
 |
reachsatish |
Posted: Mon Jul 30, 2007 9:46 am Post subject: Thanks for the pointers |
|
|
Newbie
Joined: 18 Jul 2007 Posts: 6
|
Kimbert,
Thanks for the very detailed explination. My team does not have experience in TDS. I have a consultant coming in next week and I will ask him to try this. I will update you on the results and final model.
Thanks
Satish |
|
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
|
|
|
|