views:

482

answers:

3

My application communicate with other system via IBM Websphere MQ. Sometime no message income to my queue but other system said They already sent to me. So I want to know how to keep history for all messages that income to my queue.

A: 

Keep in mind that it may still be coming across the network as the MQ architecture may have many middle-ware queues. Similarly, there's no requirement for a message to immediately get transmitted across a channel - the sender may batch up the messages and send them with a trigger.

The best way to ensure you log everything that arrives is to do this is with an interceptor queue.

This is the queue (let's call it A) that the channel writes to and, until this change, your application read from. You then have a transfer process the reads from A, logs the message then writes it to the second queue (B). This second queue is what your application now reads from.

paxdiablo
A: 

You can put a logging statement at your end of the queue, so that as soon as you get the message, you dump the contents into a log. That way if the other system says they sent a message, all they have to do is tell you when, and you can look in your log and see if there's a message received from them at about that time.

Elie
This answer may be appropriate for some other vendor's queuing transport but it does not apply to WebSphere MQ.
T.Rob
I was not referring to the queueing system itself, but to the application that is supposed to be picking up the messages from the queue.
Elie
That's a little more useful but doesn't solve the problem. It's possible for a variety of reasons for the message to traverse the channel yet fail to land on the queue. Alternatively, it may land on the queue and expire or get requeued as poison before the app sees it. Having the application log the message provides positive confirmation of receipt but fails to account for negative confirmations. A channel or API exit would be able to log the arrival of messages that *didn't* make it to the app.
T.Rob
Granted - but it could be an easy way to provide that positive confirmation. As you say, a channel or API exit would provide verification for more scenarios, but may be a little more complicated to implement.
Elie
+1  A: 

The only other way I can think of would be to use a channel exit.

andypiper