| Author |
Message
|
| bce |
 Posted: Mon Dec 22, 2008 9:18 pm Post subject: Copying the message transmitted through a Channel |
 |
|
Novice
Joined: 07 Dec 2008
Posts: 11
|
HI,
I want to get a copy of all the messages transmitted through a Channel.
Can anyone tell me the best approach to implement this?
Is there any configuration option in WMQ to copy the messages transmitted through a Channel to a Q
Thanks in advance,
bce |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Mon Dec 22, 2008 10:31 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
no, there is no such option.
why do you want to do that? It is application work or application design to archive / backup messages if required (for whatever reason), not MQ work.
if you really want to do that, then you need a channel message exit, that is putting a copy of the message to the "for-whatever-reason-save-queue"
_________________
Regards, Butcher |
|
| Back to top |
|
|
| bce |
| Posted: Tue Dec 23, 2008 1:17 am Post subject: |
|
|
Novice
Joined: 07 Dec 2008
Posts: 11
|
HI Butcher,
Thanks for your response.. we are building a replay server to replay the messages...
what is this channel message exit? do I have to change my programme? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Dec 23, 2008 1:25 am Post subject: Re: Copying the message transmitted through a Channel |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bce wrote: |
| I want to get a copy of all the messages transmitted through a Channel. |
Why? Because you have a actual need, or because management / auditors have this unfocused belief you should? Where will these copies go? What will use them, and what for? What will manage them (on a channel of any frequency, you'll get a lot of copies building up quckly). Why is the auditoring not being done by the sending/receiving apps?
These are questions you need to ask yourself.
If you do decide to go for this, an exit is the way to go. Note that exits are an advanced topic; even a working exit,if badly writtren, will hobble your performance. An exit with a bug in it will bring the MCA, the queue manager or both crashing down.
Robust testing is essential.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Dec 23, 2008 2:07 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
i strongly recommend you answer yourself all of the questions vitor showed you. once you solved issues like this with an exit, you are bound to it in most cases.
| Quote: |
| what is this channel message exit? do I have to change my programme? |
read the intercommunication guide, it has all information about channel exits in there. a message exit is an additional program that is called by the channel every time a message is transferred. no need to change your application programm.
But - if changing of the application is an option, why not perform 2 puts, one for the original message to be send and another one for the "replay" message? or are there any other methiods to keep that backup of the messages, e.g. in a database? this is what you should investigate first before you start to create an exit.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Dec 23, 2008 3:15 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Much easier to code a simple application which gets messages from one queue and puts them to two queues. WMB can do this of course as well.
There is the mirrorq exit which will do this (support pac). |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Dec 23, 2008 3:32 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
afaik mirrorq is an api exit. it is not available on all pattforms, and it will not work on a receiving channel?!?
i agree that a 1-get - 2-put application may be easier as a channel message exit, but - on the other hand - if that program has to be implemented for 100 queues......
_________________
Regards, Butcher |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Dec 23, 2008 3:35 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| There is the mirrorq exit which will do this (support pac). |
Sample code, not supportPac.
Unsupported sample code, in that there is nobody at IBM who owns the code any more.
Queues and topics are interchangable in MQ v7. You can have the app put the message to a Topic that has two subscriber queues for the receivers, without changing the apps.
A replay server should be hardwired into the MQ message flow topology, so that everyone is clear that it is an explicit part of the process and that they understand that the performance impact (no matter how small) of duplicating the messages is providing value by enabling replay. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Dec 23, 2008 3:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| There is the mirrorq exit which will do this (support pac). |
mirrorq is not a support pac; it's a piece of sample code not intended for use in a full-strength prod environment. This means that it needs to be strengthened and brought to standard of any site it's used on.
It also means that it's not supported by IBM in the way a support pac can be. So any issues (and please insert my standard rant on exits here) and you're on your own.
In this specific instance, it wouldn't copy everything on a given channel
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
