MOM - message delivery status mechanisms and directions on topic

Hello,
I have communication between Websphere MQ(which is on central server) and a e.g 5  "clients" that are also separate servers. Central server and client (server) exchange messages. Do you have any recommendations on how to create mechanism that will enable tracking of delivery status of messages on both sides (central server - client server) - I need to know weather sent message is delivered or not, which message failed and where (from which client or to which client). It should go through topic - subscribe - publish methodology ... ? I am totally newbee at this topic. I would appreciate any kind of advice, direction points, suggestions, maybe useful, constructive and effective (million dollar :) links, some directions on Websphere MQ ... I searched the web, but I can't seem to find my way through it (I feel pretty much helpless ...)
Please advise,
thank you in advance!
Best regards!
iceberg100Asked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

iceberg100Author Commented:
Anyone? :D
0
giltjrCommented:
Well first, if you have configured MQ correctly (meaning using persistent queues) it is guaranteed to deliver the message.

If you use non-persistent queues, then if MQ is stopped or falls over, I believe your message is gone.

Even though MQ guarantees delivery, you have no clue when it will deliver it.  It could be 1 second after the message is put on the queue, or it could be 3 months later.

Have you read:

     http://www.redbooks.ibm.com/abstracts/SG247128.html
     http://www.redbooks.ibm.com/abstracts/sg246506.html

MQ give you various ways to trigger processes when various events happen.  
0
iceberg100Author Commented:
Hi, thank for your reply and sorry for my late replay.

MQ is guaranteed to deliver message, but in some cases it just doesn't, so I would like to have a "monitoring"  program that would notify me when that scenario appears and tell me also info about where did it appear (in which communication, because there are multiple clients). And queue is not an option, it has to be done over publish / subscribe. I have checked links that you gave me, but I still couldn't find answer to my question. Please advise.
0
Become a CompTIA Certified Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

giltjrCommented:
I will need to refresh my memory on publish/subscribe, but IIRC you can't tell.  As you could publish once and have any number of subscribers.  I did not think (at least when this first came out) there was a way to tell when a subscriber received a message.  
0
giltjrCommented:
I did a quick read.  First, what version of MQ are you running?  MQ V7 changed a few things dealing with publish subscribe.

It appears that even with publish/subscribe you still have local queues, remote queues, and channels.  In a "normal" server-to-server setup. if you have 5 customers you would define 5 remote queues on your side, one for each customer, and you would decide which message was to be written to which queue and could write the message up to 5 times.  When you write to a remote queue for a server-to-server connection MQ pushes the messages down the channel for thatt queue.

With publish/subscribe you have "6" queues.  One that is the publish queue and 5 that are the subscribe queues.  The subscriber tells a "broker manager" what information they want.  You write to the publish queue and the broker manager then distributes the message to the subscribe queues based on the subscriber's requirements.

You should have the ability to query the status of the "subscriber" queue.  I am also going to assume that the "subscriber" queue have channels associated with them.  You should be able to query the channels to see what the current depth is.  This is the number of messages that have  not been delivered yet.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
iceberg100Author Commented:
Ok, thanks for your advice.
It guided me in some direction, that is way i am closing this question and giving you the points.
0
iceberg100Author Commented:
Answers gave me some directions that could help me in further research.
0
giltjrCommented:
Thank you and good luck with this project.
0
iceberg100Author Commented:
Thanks, I will need it :)
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java App Servers

From novice to tech pro — start learning today.