You can be a purest any day of the week. Just try debugging this crap at 3AM with an idiot on the other end of the phone from home. My basic rule is KISS. And that applies directly to me and what I need to keep my life simple. :-)
bobbee
From: John Scott <[EMAIL PROTECTED]> Reply-To: MQSeries List <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Transaction Names Date: Wed, 23 Jun 2004 17:49:25 +0100
Doesn't this tie your applications to each other a bit more. If your message from SAP to ARIBA needs to be changed to another application, you have to update SAP so that it puts a message on the SAP.ANO.TRANS_NAME queue?
If SAP writes to SAP.TRANS_NAME MQ can deliver that to ARIBA.TRANS_NAME where ARIBA reads the message.
If in the future you need to re-route it through WMQI or WBIMB you can change the destination of the SAP queue without changing its name.
You could use your queue naming convention to show the MQ admin the from/to, but I would still setup alias queues SAP.TRANS_NAME for SAP to put them on your physical SAP.ARIBA.TRANS_NAME queue.
Anyway I am digressing from my little problem onto a subject I am sure is as religious as whether C++ is better or worse than Java.
Regards John Scott IBM Certified Specialist - MQSeries Argos Ltd
-----Original Message----- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: 22 June 2004 19:43 To: [EMAIL PROTECTED] Subject: Re: Transaction Names
I always preferred SendingApp.ReceivingApp.BusinessReason where the third parameter looks like your transaction portion of the name. Business name could be defined as the business process_Interface so a message going from SAP to ARIBA for warehousing of the GL arbitrage accounts would look like the following:
SAP.ARIBA.WAREHOUSE_GL-ARBITRAGE
Obviously the naming portion after the sending and receivng portion has a certain amount of artistic license build into the actual naming but it allows a certain amount of traceability. I would think that this is the idea that would need to be promoted. Obviously there could probably be many examples where this design may not work but it could be used as a start.
bobbee
>From: John Scott <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Transaction Names >Date: Tue, 22 Jun 2004 09:29:10 +0100 > >I have already posted this question on mqseries.net, but I wondered if I >would get some more responses on the list server... > >I am not looking for ideas on general MQSeries naming standards, I already >have those and there are enough examples in the archives to keep anybody >happy. > >Our queue naming standard is basically APP_NAME.TRANSACTION_NAME. > >Where APP_NAME is the name of the application that is allowed access to the >queue. We use alias/remote queue definitions to wire up > >MYAPP.TRANSACTION_NAME -> YOURAPP.TRANSACTION_NAME > >I am now looking in detail at the TRANSACTION_NAME. When I look at the >queues we have I see a mixture of TRANSACTION_NAME styles - some of them >are >named after what the message content is (i.e. ORDER_AMENDMENT) and others >are named after what the applications (typically the receiving application) >does with the data (i.e. UPDATE_ORDER). > >Thus we would have a queue called: > >MYAPP.ORDER_AMENDMENT >or >MYAPP.UPDATE_ORDER > >I wanted to canvas whether people preferred the "what it is" over "what it >does" or vica-versa. > >Which style do you use and why? > >Regards >John Scott >IBM Certified Specialist - MQSeries >Argos Ltd. > >************************************************************** > >Click here to visit the Argos home page http://www.argos.co.uk > >The information contained in this message or any of its attachments may be >privileged and/or confidential, and is intended exclusively for the >addressee. Unauthorised disclosure, copying or distribution of the contents >is strictly prohibited. > >The views expressed may not be official policy, but the personal views of >the originator. > >If you have received this message in error, please advise the sender by >using the reply facility in your e-mail software. > >All messages sent and received by Argos Ltd are monitored for viruses, >high-risk file extensions, and inappropriate content. > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive
_________________________________________________________________ Watch the online reality show Mixed Messages with a friend and enter to win a trip to NY http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
**************************************************************
Click here to visit the Argos home page http://www.argos.co.uk
The information contained in this message or any of its attachments may be privileged and/or confidential, and is intended exclusively for the addressee. Unauthorised disclosure, copying or distribution of the contents is strictly prohibited.
The views expressed may not be official policy, but the personal views of the originator.
If you have received this message in error, please advise the sender by using the reply facility in your e-mail software.
All messages sent and received by Argos Ltd are monitored for viruses, high-risk file extensions, and inappropriate content.
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
_________________________________________________________________
From will you? to I do, MSN Life Events is your resource for Getting
Married. http://lifeevents.msn.com/category.aspx?cid=married
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
