| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| File transformation ... What is typical/best practice |
« View previous topic :: View next topic » |
| Author |
Message
|
| RINU |
 Posted: Thu Sep 02, 2004 2:56 pm Post subject: File transformation ... What is typical/best practice |
 |
|
Newbie
Joined: 21 Jul 2004
Posts: 6
|
Hi,
I am relatively new to WBI... recently seen a demo of some WBI
usage scenarios...
1 COBOL message in --> 1 xml message out
For the demo a whole flat file was coverted into 1 message and wbi produced the whole xml file as a single message out.
Is it typical... Why not read one record in to create equivalent 1 xml message out rather than whole file.
Just wondering What are the deciding factors to pick between these two approaches.. is it file size or am I missing something altogether here?
thanks
RINU |
|
| Back to top |
|
 |
| kirani |
| Posted: Thu Sep 02, 2004 5:45 pm Post subject: Re: File transformation ... What is typical/best practice |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
| RINU wrote: |
Just wondering What are the deciding factors to pick between these two approaches.. is it file size or am I missing something altogether here?
|
I guess some of the factors one should consider,
1) Reduce number of I/O by processing group of records in a package.
2) Review the scope of UOW for failure considerations.
3) How the receiving system wants it.
4) Easy to understand and maintain.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| PGoodhart |
| Posted: Tue Sep 07, 2004 6:38 am Post subject: |
|
|
Master
Joined: 17 Jun 2004
Posts: 278
Location: Harrisburg PA
|
Actually there are more senarios then you think.
XML message -> DB entries and 1 copybook (Good for dealing with variable length messages with variable number of records.)
Multiple XML Messages -> 1 copybook (When the messages are much more verbose then necessary, for instance if you just need a list of user ids and you have XML messages with all the demographic data in them.)
There really are a bunch of possiblities.
As previously stated making decisions depends on several things. Just remember that more granular output consumes more system resources on both sides (broker and application), but is also more flexible.
_________________
Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
| Back to top |
|
|
| RINU |
| Posted: Tue Sep 07, 2004 9:10 am Post subject: |
|
|
Newbie
Joined: 21 Jul 2004
Posts: 6
|
Thanks for the tips.
Actually the scenario mentioned above involved a file with multiple record formats. Something like ...
| Quote: |
HDR Header Record
GROUP1 Record 1
GROUP1 Record 2
GROUP1 Record n
SUMMARY GROUP1
GROUP2 Record 1
GROUP2 Record 2
GROUP2 Record n
SUMMARY GROUP2
...
GROUPn Record 1
GROUPn Record 2
GROUPn Record n
SUMMARY GROUPn
TRAILER
|
Which need to be converted into an XML like (there is a buch of transformation) ...
| Quote: |
<HEADER>
...
</HEADER>
<GROUP DATA>
<SUMMARY>
</SUMMARY>
<DETAIL>
</DETAIL>
</GROUP1 DATA>
..group data repeats for each group
<TRAILER>
</TRAILER>
|
Usage scenario shown to me in the first post - 1 message (whole custom file) - > 1 message out (whole xml file) was because the xsd for the xml is for whole file and Well formed check will be for the whole xml.
When asked regarding the record by record processing option
(1 message (1 record in input file -> 1 message out (1 xml record>
the option given was to first save the individual file records into a database and access the databse to create the xml file... the reason given was MQGET node will not go back to pick up another message until the first one is handled.. but with DB it is ok.
To me the whole file in -> whole file out is ok for small files.. but then for the larger files I was thinking WBI should be able to handle at least a group (<GROUP DATA>) at a time as the groups themselves can contain a large number of detail records...
... and I didnt think very well of the database replication.. Do anyone see another alternative here?
thanks,
RINU |
|
| 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
|
|
|
|
