| Author |
Message
|
| railbroker1 |
 Posted: Thu Mar 28, 2013 6:42 am Post subject: Message Set with dynamic CWF / TDS Format |
 |
|
Newbie
Joined: 28 Mar 2013
Posts: 8
|
Hi,
i am quite new to websphere message broker and have a question about designing a message set for custom wire format.
We use WMB 7.0.0.5. We receive String messages with fixed length header fields. One field is a bit mask, which indicates which set of optional fields are sent in the rest of the message.
For example:
"129039<Bitmask>1000110</Bitmask>Field1Field5Field6"
or
"129039<Bitmask>001100</Bitmask>Field3Field4"
Is it possible to design a message set which can handle this an parse such custom input formats dynamically to the logical format? Tried some approaches with CWF and TDS with no success so far.
Appreciate your help.
Thanks! |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Mar 28, 2013 7:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Replace the word "bitmask" with the word "tag" and reconsider. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Mar 28, 2013 7:22 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
You need a structure like this
| Code: |
Message
sequence dataElementSeparation='Fixed length'
element name="id" type='string' length='6'
sequence dataElementSeparation='Fixed length' groupIndicator='<Bitmask>' groupTerminator='</Bitmask>'
element name="count1' type='integer' length=1
element name="count2' type='integer' length=1
element name="count3' type='integer' length=1
element name="count4' type='integer' length=1
element name="count5' type='integer' length=1
element name="count6' type='integer' length=1
sequence dataElementSeparation='Fixed length'
element name='element1' minOccurs='0' maxOccurs='1' repeatReference='count1'
element name='element2' minOccurs='0' maxOccurs='2' repeatReference='count1'
element name='element3' minOccurs='0' maxOccurs='3' repeatReference='count1'
element name='element4' minOccurs='0' maxOccurs='4' repeatReference='count1'
element name='element5' minOccurs='0' maxOccurs='5' repeatReference='count1'
element name='element6' minOccurs='0' maxOccurs='6' repeatReference='count1'
|
...or upgrade to v8 and use the DFDL parser ( couldn't resist the temptation ) |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Mar 28, 2013 7:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kimbert wrote: |
| You need a structure like this |
I guess I didn't consider the "<bitmask>" and "</bitmask>" to be literal values, merely logical indicators....
And I guess I would consider this to be a tagged-fixed length choice of sequences resolved using a tag, rather than using a group indicator... |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Mar 28, 2013 8:10 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
@mqjeff: if the number of indicator bits was small then you could use a choice with Tagged Fixed Length. For a 2 indicator bits, you would need 4 branches in the choice. For 3 indicator bits, you would need 8 branches. In this case you would need 64 branches, which is not practical.
Incidentally, there are other formats that use indicator bits in this way. ISO8583 uses (up to ) two binary 64-bit fields that contain indicator bits for all of the the structures in the message. MRM can't handle the bit fields, but DFDL can. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 29, 2013 3:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kimbert wrote: |
| @mqjeff: if the number of indicator bits was small then you could use a choice with Tagged Fixed Length. For a 2 indicator bits, you would need 4 branches in the choice. For 3 indicator bits, you would need 8 branches. In this case you would need 64 branches, which is not practical. |
That assumes that there is a definition for each possible value of bitmask...
If there *is* actually a definition for each possible value of bitmask, then practicalities don't really apply. 64 message definitions of some kind need to be created and 64 message definitions need to be chosen from.
Using a multipart message might be better than using a choice, but both are relatively "impractical" by the standards you appear to be applying.
Although, again, "practical" really implies "meets the business requirements", and I don't think your standards cover that.
Also, I would hope that for as long as you and I have been discussing MRM and given how I am occasionally shown to do impressive things, that you would expect and remember that I'm well aware that MRM does not support bitlevel fields and that DFDL does.
... Where's that post I made ten years ago about MRM not being able to process MIME documents because it can't derive a delimiter from the contents of a message? ... ? |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Mar 29, 2013 11:49 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| The explanation about MRM and bit fields was for the benefit of future readers. It would indeed have been rather patronising if directed at mqjeff. Apologies for not making that clear. |
|
| Back to top |
|
|
| railbroker1 |
| Posted: Thu Apr 04, 2013 1:27 am Post subject: |
|
|
Newbie
Joined: 28 Mar 2013
Posts: 8
|
Thank you guys for the valuable input!
I solved the requirement by using a tds message set with the grouping feature for the bitmask (as kimbert supposed in the second reply to my post).
Thanks a lot! |
|
| Back to top |
|
|
|
|
