| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How can I monitor my send queue? |
« View previous topic :: View next topic » |
| Author |
Message
|
| marmstro |
 Posted: Tue Jun 25, 2002 12:20 pm Post subject: How can I monitor my send queue? |
 |
|
Newbie
Joined: 25 Jun 2002
Posts: 1
Location: Cleveland, OH
|
I'm running MQ on Solaris, using WebSphere Commerce Suite 4.1's MQSeries Adapter to send XML purchase orders to our AS/400. Sometimes the XML is not properly parsed on the AS/400 side, so I would like to be able to save off copies of the XML messages that are being sent on the Solaris box for later analisys.
Any info/help would be appreciated.
P.S. My experience level with MQ is just enough to follow the manual to set up the queues and channels. |
|
| Back to top |
|
 |
| nimconsult |
| Posted: Wed Jun 26, 2002 1:00 am Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
There is no out-of-the-box solution to keep a trace of the message you send to another platforms.
You can use these different alternatives:
(1) The sender application posts the messages on two queues: one with your effective destination and one local queue to keep a trace of your message. If you want strict data consistency you will put the two messages within syncpoint, to make sure that either both messages or none is stored on the two queues.
(2) The sender application posts the messages on a distribution list (see MQ Series documentation), which is roughly equivalent to the previous point.
(3) You do not keep a trace of EVERY message, but only a trace of the messages that fail. For this purpose, you define what I call an "application dead-letter queue", which is a normal MQ Series queue in which an application rejects invalid messages. You must adapt your server application to store invalid messages in this reject queue. The advantage of this solution is that you use less machine ressources, you can easily raise alerts on the presence of invalid messages, you are not overloaded with information that you do not need, you directly point to the problem in case of alert.
(4) If you have no way to modify neither the client nor the server applications, then put an additional process in the middle that logs messages and forward them to the actual server.
'hope this helps
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| 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
|
|
|
|
