| Author |
Message
|
| Albator |
 Posted: Mon Oct 04, 2004 11:07 am Post subject: how to have a proof that a message was sent? |
 |
|
Voyager
Joined: 04 Mar 2004
Posts: 75
Location: Toronto, Canada
|
Hi,
One of our clients wants us to prove them that some messages were actually sent to them (we are using MQ 5.3 on Win2k). What is the best and easy way to do that? Note that all the queues are persistent and the message are in text format.
Thanks |
|
| Back to top |
|
 |
| Anirud |
| Posted: Mon Oct 04, 2004 12:38 pm Post subject: |
|
|
Master
Joined: 12 Feb 2004
Posts: 285
Location: Vermont
|
|
| Back to top |
|
|
| siliconfish |
| Posted: Mon Oct 04, 2004 12:57 pm Post subject: |
|
|
Master
Joined: 12 Aug 2002
Posts: 203
Location: USA
|
Hi Anirud - both of those posts are by Albator 
Albator - What do u want to prove them? are u missing some messages?
You can use the CURMSGS and CURSEQNO channel status attributes on the sender and receiver channels to match the message count.
If this is not what you are looking for, please post more details.
_________________
siliconfish |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 04, 2004 1:22 pm Post subject: Re: how to have a proof that a message was sent? |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Albator wrote: |
Hi,
One of our clients wants us to prove them that some messages were actually sent to them (we are using MQ 5.3 on Win2k). What is the best and easy way to do that? Note that all the queues are persistent and the message are in text format.
Thanks |
COA reports. The name says it all. Confirmation of Arrival. It will confirm the message arrived at its destination.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Albator |
| Posted: Mon Oct 04, 2004 1:31 pm Post subject: |
|
|
Voyager
Joined: 04 Mar 2004
Posts: 75
Location: Toronto, Canada
|
The client sends a request, we then send an ack. message upon arrival of the request, process the request and send 1 or more msg(s) containing the result(s).
Now, I assume that our queue manager will log each response msg that is being sent to the remote queue manager in the logs (since the remote queue is set to be persistent). Ideally I would like to find the response message in the log.
I might be wrong but I think that if we need to confirm that the response msgs have been sent to the client, it is better to have the application log the infomation (in this case the msg, date and time) in a file or DB after a successful PUT/Transaction in the queue. Now I have been asked to prove that some response messages have actually been SENT to the client or at least PUT in the remote queue. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 04, 2004 3:39 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Honestly, it sounds like you need to do three things in order to get this external party to take responsibility for their own problems.
First, your application needs to log everything it does, to a file or a database or somewhere. This log should include the Message ID, the timestamp, the queue name, and some piece of business relevant information.
Second, you need to specify COA options on your messages. And then you need to log the receipt of COA reports into a database or a file or somewhere.
Third, you need to put in a channel exit that logs message information as it passes through the channel, including time and message ID and the name of the queue manager on the other side.
COA may not be sufficient to "prove" anything to this external party.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 04, 2004 7:19 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Albator wrote: |
| I might be wrong but I think that if we need to confirm that the response msgs have been sent to the client, it is better to have the application log the infomation (in this case the msg, date and time) in a file or DB after a successful PUT/Transaction in the queue. Now I have been asked to prove that some response messages have actually been SENT to the client or at least PUT in the remote queue. |
Ask these people what proof they want. You showing a log of what messages you supposedly put is not really any proof at all, is it? Couldn't you just write bogus entries to a log and say "See! Look at all the messages I sent you!".
No, you need a reciept from them, that only they could have produced, and they couldn't later deny having sent (non-repudiation of their acknowledgement). A COA is a step in the right direction, because it will have there QM generated MessagID in the report message, along with the details in the body. But couldn't you just as easily have faked that message as well? (Yes, you could.) All of Jeff's suggestions could also be faked on your side.
So what you need to do is ask them, "What is proof positive that I sent you a message?".
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 05, 2004 4:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| All of Jeff's suggestions could also be faked on your side. |
Sure. But Albator's management isn't going to believe it if the other party tells them that. Or at least, they shoudn't, and if they do it's time to change jobs.
And the other side could very easily block COAs from coming back, too. Particularly remembering some of the security issues I remember being talked about here related to COAs and CODs coming back with different user IDs, they could even reasonably argue a case for not allowing COAs. Or Albator's security group could (unreasonably, in this case, but we are talking about security groups) decide that they won't allow the changes needed to let the COAs arrive properly.
This is as much a business relationship issue as it is a technical issue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Oct 05, 2004 3:41 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| jefflowrey wrote: |
| PeterPotkay wrote: |
| All of Jeff's suggestions could also be faked on your side. |
Sure. But Albator's management isn't going to believe it if the other party tells them that. Or at least, they shoudn't, and if they do it's time to change jobs.
And the other side could very easily block COAs from coming back, too. Particularly remembering some of the security issues I remember being talked about here related to COAs and CODs coming back with different user IDs, they could even reasonably argue a case for not allowing COAs. Or Albator's security group could (unreasonably, in this case, but we are talking about security groups) decide that they won't allow the changes needed to let the COAs arrive properly.
This is as much a business relationship issue as it is a technical issue. |
In Peter's defence I think his question was retorical or at the very least a act harmless sarcasm. I also think that this whole issue is another instance of a Business Partner or PM with little or no technical knowledge of MQSeries or anything else for that matter, making insane demands.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 05, 2004 4:24 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| csmith28 wrote: |
In Peter's defence I think his question was retorical or at the very least a act harmless sarcasm. I also think that this whole issue is another instance of a Business Partner or PM with little or no technical knowledge of MQSeries or anything else for that matter, making insane demands. |
I hope Peter doesn't think I was attacking him, or that he needed a defense...
I was merely agreeing with him, and providing some additional perspective on my view point.
I agree that this is a business partner making unreasonable demands.
Having dealt with trying to exchange data with incompetant business partners who make unreasonable demands, I think I have some idea of the situation that Albator is facing. And he may have to take unreasonable measures on his part, in order to provide sufficient quantities of data to convince his management that the business partner in question is unreasonable and incompetant.
None of my suggestions were intended to convince the business partner that they were in the wrong.
They were intended to provide him with enough information that he can go to his management and get them to deal with the business relationship.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Oct 05, 2004 5:24 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
[quote="jefflowrey]
| Quote: |
I hope Peter doesn't think I was attacking him, or that he needed a defense...
|
Good!
Cause you pick on the Potkaymeister and Imma have too fly to Baltimore and GWB you. =]
Lol, just kidding. Besides research shows that you have no connection to terrorist activety.
@Albator: MQSeries is a messenger. It delivers messages. That is what it does and it does it quite well. MQMessages always end up going somewhere. If the application is pooched they sit quietly in the applications QLocal. If the message is ill formed or has invalid information in the Message Discripter or a Qremote has an invalid RNAME the message goes to the SYSTEM.DEAD.LETTER.QUEUE or the the defined DLQ.
Since applications can only GET messages from, or PUT messages to an MQManager, regardless of whether the application is local or remote/Client or Binding. Proof that a message was delivered or not your problem.
Assuming that the application can indeed successfully connect to the MQManager, PUT the message and the message is properly stuctured/addressed the MQManager will indeed deliver the message.
Assuming that the message the application wants to GET was properly addressed and reached the destination Queue, the message will sit there until the applicatio GETS it. It is just that easy.
MQSeries does not have a /dev/null. The message will either go to the Queue it was addressed to or it will go to the defined DLQ.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Last edited by csmith28 on Wed Oct 06, 2004 7:26 am; edited 2 times in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 05, 2004 5:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Not quite right.
Remember for all this to work right you need to make sure of 2 things
a) the qmgr DOES have a DLQ defined
b) the messages being exchanged are PERSISTENT
If any of these 2 don't apply it's anyone's guess. But then if your message is not persistent I guess you don't really care about whether it made it or not...(typically only in a request response scenario with time out on messages..)
Now if you have a qmgr without a DLQ that's a more serious offense...
Enjoy  |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Oct 05, 2004 5:55 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| fjb_saper wrote: |
Not quite right.
Remember for all this to work right you need to make sure of 2 things
a) the qmgr DOES have a DLQ defined
b) the messages being exchanged are PERSISTENT
If any of these 2 don't apply it's anyone's guess. But then if your message is not persistent I guess you don't really care about whether it made it or not...(typically only in a request response scenario with time out on messages..)
Now if you have a qmgr without a DLQ that's a more serious offense...
Enjoy |
In the initial post Albator indicated that the messages were persistent
He did not mention a DLQ.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
|
|
