| Author |
Message
|
| Api123 |
 Posted: Wed Jun 02, 2010 5:29 am Post subject: copy of orignal message |
 |
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
Hi All,
I'm new to MQ design, we have a scenario to design a multi-hopping environment, Vendor (Lq) <--Us(xmitq) <--ourClients (Lq) and reverse. We sit in the middle with xmitq configured. This looked fine till the business required logging capabilities
(Copy of the original payload + couple of MQMD fields) for every message.
Is there is away to have a copy of a message from xmitq with out coding a channel exits (I thought this will be over kill)?
The second approach I thought of; is to have ourClient put messages in our local queue, then we use trigger to copy messages to xmitq and a local queue (logging queue) ourClients(Lq) --> Us(Lq)-->xmitq--> Vendor(Lq) and reverse. I’ve coded a trigger and this is working fine. I'm I doing something wrong here?
One more: Can a server-side channel (Receive/ Message/ Send) Exits be written in .net or Java?
Our Environment is Windows 2008 R2, WMQ version 7.0.1.0
Thanks in Advance,
AJ |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Jun 02, 2010 5:49 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
This has been discussed many, many times here. Click the Search button at the top of the page.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Api123 |
| Posted: Wed Jun 02, 2010 7:52 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
| Thanks bruce2359. I was hoping some one will shed some light on the second approach.if it’s a viable approach. And yes I did use search |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Jun 02, 2010 8:02 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Since you are V7.0.1.0, you should use Pub/Sub which has been discussed here. Also, go ahead and apply 7012.
Both your approaches are inappropriate at V7. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 02, 2010 8:02 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The second approach I thought of; is to have ourClient put messages in our local queue, then we use trigger to copy messages to xmitq and a local queue (logging queue) ourClients(Lq) --> Us(Lq)-->xmitq--> Vendor(Lq) and reverse. |
A practical and low-tech solution.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 02, 2010 8:31 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Api123 wrote: |
| I was hoping some one will shed some light on the second approach.if it’s a viable approach. |
No it isn't
| Api123 wrote: |
| And yes I did use search |
It's a shame you didn't find anything on such an oft-discussed topic.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Api123 |
| Posted: Wed Jun 02, 2010 8:37 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
Thanks Joseph, I remember working with SUB\PUB with TIBRV. I don’t have control over the Vendor’s configuration. They expect asynchronous message point-to-point. Do you still think SUB\PUB applies here? I’ll give Publish/Subscribe user’s guide a shot
AJ |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 02, 2010 9:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Quote: |
| The second approach I thought of; is to have ourClient put messages in our local queue, then we use trigger to copy messages to xmitq and a local queue (logging queue) ourClients(Lq) --> Us(Lq)-->xmitq--> Vendor(Lq) and reverse. |
A practical and low-tech solution. |
If the copying application builds the xmit header itself.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jun 02, 2010 9:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Api123 wrote: |
| Do you still think SUB\PUB applies here? |
It's a possibility for what you're trying to achieve.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Api123 |
| Posted: Wed Jun 02, 2010 10:26 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
| Thanks Vitor, as I mentioned our Vendor in this configuration will not participate in SUB\PUB. Are you implying point-to-point between Us and vendor, SUB\PUB between Us and ourClients |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 02, 2010 12:30 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Extracted from one of PeterPotkay's posts:
| Quote: |
App A is putting to a local q called Q1. App B is pulling from Q1. You have MQ 7 and want to duplicate the messages but do not want to change the sending or receiving app code.
Define a topic called Q1T, with a topic string of Q1
Define a sub to topic object Q1T, with a destination of Q1
Define a Q Alias called Q1Alias, target type topic with a target of Q1T
A put to Q1Alias will now produce a message to the Q1 local queue
Define another sub to topic object Q1T, this time with a destination of Q2
A put to Q1Alias will now produce 2 messages, one to Q1 and one to Q2.
The only change in the original setup is that App A puts to Q1Alias instead of Q1. App A and App B don't know they are using Pub Sub. The subscriptions are created by the MQ Admin using admin commands. |
A cheap and cheerful way of duplicating messages...and it works when a sub is a QR too.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Api123 |
| Posted: Wed Jun 02, 2010 12:52 pm Post subject: |
|
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
| Thanks All, you guys been much help |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Wed Jun 02, 2010 3:20 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Vitor wrote: |
| If the copying application builds the xmit header itself. |
The copying app will not need to build the xmit header if it opens a queue / queue manager combination and the xmitq has the same name as the destination queue manager. An alternative is to use intermediate qremote objects.
The copying app can also put the message to a local queue to provide the logging requirement.
Its worth considering using a long running program rather relying on triggering.
Another possibility is to define a message logging exit on the sending channel, eg SupportPac MA0Z.
I think that its overkill to introduce pub/sub into a point-to-point design merely to provide logging an intermediate point.
_________________
Glenn |
|
| Back to top |
|
|
| wschutz |
| Posted: Wed Jun 02, 2010 3:35 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Applications should NEVER write directly to the xmitq.
Its trivial to write an application that reads the customer's queue and writes one message to a "logging" local queue and the other messages to a remote queue, which points to the final destination queue .
You can define an MQ service to start the "copying" program, or trigger it if you like (which delays the delivery of the message somewhat).
_________________
-wayne |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 03, 2010 1:50 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| wschutz wrote: |
| Its trivial to write an application that reads the customer's queue and writes one message to a "logging" local queue and the other messages to a remote queue, which points to the final destination queue . |
It's even more trivial to use v7 pub/sub and not write any application at all. |
|
| Back to top |
|
|
|
|
