| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Parsing multiple SWIFT like format messages |
« View previous topic :: View next topic » |
| Author |
Message
|
| whydieanut |
 Posted: Fri Jun 27, 2014 1:38 am Post subject: Parsing multiple SWIFT like format messages |
 |
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
Hi all,
I need to parse about 100 odd message types, which share the basic structure, but use different field names.
The messages are structured like below:
There is a tag at the beginning of each group that indicates the name of the group, followed by a <CR><LF>.
Data inside each group is of the form
:field_name:field_value
Each subsequent group begins with a - and then the tag/group name.
Some groups are optional, some are repeatable.
Message 1:
| Code: |
group1
:field1:value1
:field2:value2
-group2
:field3:value3
:field4:value4
:field5:value5
-end |
Message 2:
| Code: |
group1
:field1:value1
:field2:value2
-group3
:field6:value6
:field7:value7
:field8:value8
-group3
:field6:value6
:field7:value7
:field8:value8
-group4
:field9:value9
-end |
I plan to split each group in the message as below:
| Code: |
group1
:abc
-group2
:def
-group3
:xyz |
Data Element Separation: Tagged Delimited
Delimiter: <CR><LF>-
Tag Data Separator: <CR><LF>:
I then plan to split each group's data (abc, def, xyz) into the actual fields as below:
| Code: |
field1:value1
:field2:value2
:field3:value3 |
Data Element Separation: Tagged Delimited
Delimiter: <CR><LF>:
Tag Data Separator: :
Does this look like a reasonable approach? |
|
| Back to top |
|
 |
| kimbert |
| Posted: Fri Jun 27, 2014 1:45 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
It is only a reasonable approach if you are on v7. Otherwise, DFDL will be a much better option.
As always with TDS models, debugging will require debug-level user trace.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| whydieanut |
| Posted: Thu Jul 03, 2014 11:28 pm Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
Kimbert,
I don't have the luxury of using DFDL. We're developing on V6.
But I got the message set working with the above approach.
But there's something else I just figured; I need to get the name of the higher-level tags (group1, group2, etc.) into fields so that they are accessible as values.
One option is to use the same name for the field in my message set, as the tag name.
But if not this, is there any other way to model this message so that the tag names are part of the parsed data?
Since some in-between groups are optional/repeatable, I am not able to use All Elements Delimited (with delimiter as <CR><LF>-) and then treat each group as another complex type with first element as group name and rest of the data as Tagged Delimited. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Jul 04, 2014 6:44 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| We're developing on V6 |
v6 is out of support. Have you purchased an extended support contract from IBM?
| Quote: |
| is there any other way to model this message so that the tag names are part of the parsed data |
DFDL can do it using discriminators. MRM can do it if you are prepared to use 'Use Data Pattern'.
| Quote: |
| Since some in-between groups are optional/repeatable, I am not able to use All Elements Delimited (with delimiter as <CR><LF>-) and then treat each group as another complex type with first element as group name and rest of the data as Tagged Delimited. |
Can you use Tagged Delimited instead?
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| whydieanut |
| Posted: Thu Jul 17, 2014 1:56 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
| kimbert wrote: |
| v6 is out of support. Have you purchased an extended support contract from IBM? |
It's a little complicated. The client wants to continue developing in V6, though our environment is V8. we have tried reasoning that we are missing features of V8 by doing this, but it hasn't worked.
I have got the above format more or less done.
However there's a newer format that I need to parse. For extra fun, someone thought let's have different kinds of Tags and Data Separators like below.
FLD1, FLD2 and FLD5
Tag - [:TAG:/TAGDESC]
Separator - [/]
FLD3
Tag - [:TAG:/TAGDESC]
Separator - [ ]
FLD4
Tag - [:TAG]
Separator - [:]
| Code: |
Sample:
----------
:FLD1:/FLD1NAME/VAL1
:FLD2:/FLD2NAME/VAL2
:FLD3:/FLD1NAME VAL3
:FLD4:VAL4
:FLD5:/FLD1NAME/VAL5 |
Is there any way to gracefully do this without some ugly hacks?
I am looking at 2 options:
1. Grouping consecutive fields with similar tags into a Local Complex Type, and having multiple such complex types within the parent.
2. Data Pattern - but then each field will be further split into a field name and a field value, which I am not too keen on doing. |
|
| Back to top |
|
|
| whydieanut |
| Posted: Wed Jul 23, 2014 7:35 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
I got this done by creating separate Groups for each contiguous set of fields using the same Tag Data Separator.
So in the above example, I created 4 Groups, each Tagged Delimited with appropriate Tag Data Separators.
Group 1: FLD1, FLD2 (Separator - /)
Group 2: FLD3 (Separator - <space>)
Group 3: FLD4 (Separator - 
Group 4: FLD5 (Separator - /)
The parent element has these 4 Groups added as Group References, and Delimiter set to CRLF.
This seems to work fine for most cases.
But there's a problem when a group has a field that is optional.
FLD4 is optional, and so I set it to MinOccurs 0.
FLD5 is mandatory, and so it has a MinOccurs of 1.
Now when I send in a message without FLD4, the parser throws an error saying FLD5 has been deemed complete occurring lesser than MinOccurs (1 in this case).
Is this by design or is it a bug?
Is there any other way of parsing this message and also validating for mandatory fields? |
|
| 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
|
|
|
|
