| Author |
Message
|
| cute_pav |
 Posted: Thu Nov 07, 2002 7:01 am Post subject: Messageflow design aspects for multi messages |
 |
|
Acolyte
Joined: 04 Jan 2002
Posts: 65
Location: usa
|
Hi,
I need your views and implementation details for the following senario:
Need to process multiple messages with the same kind through MQSI.These messages are individual messages for input and need to process all messages based on the 1st message success.
pavan |
|
| Back to top |
|
 |
| cute_pav |
| Posted: Mon Nov 11, 2002 8:08 am Post subject: |
|
|
Acolyte
Joined: 04 Jan 2002
Posts: 65
Location: usa
|
As a first thought I am also going for usage database node but I am guessing this is very expensive for my flow in performance perspective.
As I understand other options like grouping and segmentations are only applicable when Inputnode uses MQGet(how message to be handled).
But anyone shed their views and experiences on :
once broker takes out the message(using the above grouping options) and translates as individual messages, Is that maitains its state and order?.
pavan |
|
| Back to top |
|
|
| Miriam Kaestner |
| Posted: Mon Nov 11, 2002 9:40 am Post subject: |
|
|
Centurion
Joined: 26 Jun 2001
Posts: 103
Location: IBM IT Education Services, Germany
|
| cute_pav, what are you going to do with the whole group of messages in case the first one fails in message flow? |
|
| Back to top |
|
|
| cute_pav |
| Posted: Mon Nov 11, 2002 11:01 am Post subject: |
|
|
Acolyte
Joined: 04 Jan 2002
Posts: 65
Location: usa
|
keastner,
All the successive messages should be failed if the first message fails and
also the same if that case is true.
pavan |
|
| Back to top |
|
|
| Paul D |
| Posted: Tue Nov 12, 2002 5:45 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 200
Location: Green Bay Packer Country
|
| This is just an idea, haven't tried it. what if you roll the messages together using any of the following (DB table, postit, Dx or MQGet), and then after they are all joined together, send the message down x wires for processing. If any of these fail and roll back, will it roll back all? Does it keep all of them under syncpoint? Does that work for you? Things to research and try, or maybe some else has experience with this? |
|
| Back to top |
|
|
| wmqiguy |
| Posted: Tue Nov 12, 2002 1:37 pm Post subject: |
|
|
Centurion
Joined: 09 Oct 2002
Posts: 145
Location: Florida
|
I also have not done this, but might spark an idea or two. 
Depending on volume, I would lean towards taking the DB hit.
Having said that, Let's brainstorm.
Does the sending application have the ability to send to two different queues such as:
Q.FIRST
Q.ALLTHEREST
If so, I would have the application send the first message to Q.FIRST and all of the rest to Q.ALLTHEREST.
Message flow pulls from Q.FIRST. If successful, it sends message merrily on its way, but also places a message on Q.TRIGGER.ALLTHEREST. This queue would then be triggered to a script/application that moves messages from Q.ALLTHEREST to Q.FIRST for processing by WMQI.
Kind of convoluted logic, but might do the trick.
Another possibility would be to have the application send just the first message and then have WMQI, if successful, send a trigger message back that would trigger the application to send the rest.
All kinds of what-ifs, though.
Good Luck and let us know what method you went with.
Todd |
|
| Back to top |
|
|
| Yanghui |
| Posted: Wed Nov 13, 2002 1:20 am Post subject: |
|
|
Disciple
Joined: 08 May 2002
Posts: 151
Location: Dublin, Ireland
|
Hi, all,
My understanding is that the key of the solution is to save the result of the first msg processing somewhere and use it as a guide for the following messages. Let's say there are two possible results of the first msg. One is SUCCESS and another is FAIL. You can use a queue FirstMsgResultQ to store it. During the following msgs process, you can use MQGET to get and use the result. Don't forget to make a copy of the result and send back on the FirstMsgResultQ if it's not the last msg of the group. (Actually I am thinking that MQBROWSE node could be more useful in this case. What a pity that we don't have one. It must be quite easy to transplant from MQGET to MQBROWSE. Any idea?)
Don't forget to cover the possibility that the result msg couldn't be misused. So, it's better to have one mechanism to make the solution more robust.
Just an idea, a kind of brainstorm as well.
Regards
-Yanghui |
|
| Back to top |
|
|
|
|
