|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Message Exit to modify ApplIdentityData? |
« View previous topic :: View next topic » |
Author |
Message
|
LouML |
Posted: Wed Dec 04, 2013 4:53 am Post subject: Message Exit to modify ApplIdentityData? |
|
|
 Partisan
Joined: 10 Nov 2005 Posts: 305 Location: Jersey City, NJ / Bethpage, NY
|
We’re running MQ Server 7.5 on a Solaris Sparc server (Solaris 10).
We have a request from an application group that needs to get done ASAP (as all of their requests seem to be)
We need to send messages to an External Company. They need us to send them a specific value for ApplIdentityData and ReplyToQMgr. Unfortunately, the application that Puts the messages to the QRemote is not coded to set these values (and apparently, cannot be changed to do so).
The External Company suggests in their documentation that the messages should be Put to a QLocal in our queue manager and that we write a script to Get these messages, modify the fields and then Put the messages to the QRemote.
We could certainly do this quite easily, but I was thinking this might be better done with a Message Exit on the sender channel.
Of course, I have no experience with Message Exits. The only exits I’ve used are Security exits (such as the mqmdh001.c sample from DTCC discussed in other threads) that are quite basic.
Does anyone have an opinion as to which method is better?
I’ve gone through the following:
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/index.jsp?topic=%2Fcom.ibm.mq.dev.doc%2Fq028120_.htm _________________ Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
Back to top |
|
 |
mqjeff |
Posted: Wed Dec 04, 2013 5:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
If you were to do this with an exit, I might prefer to do it with an API exit that intercepted the MQPUT.
That way if something breaks, it's much closer to where the app itself lives. You can give better feedback to the app about errors, likely, and you don't run the risk of the channel or the MCA crashing or discarding messages.
But I'd prefer not to use an exit. In general.
But, you know, that's just, like, my opinion, man. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Dec 04, 2013 6:12 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
The ReplyToQueueManager can be forced to whatever the MQ Administrator decides by definging a ReplyTo Alias queue. These little beasties are rarely used or even mentioned much but they are perfect for just this scenario. The app connected to QM1 will code MY.REPLY.QUEUE for the request message's Reply To Queue, and leave the Reply To QM blank, anticipating that the request message will be sent with MQMD_Reply2Q=MY.REPLY.QUEUE and MQMD_ReplyToQM=QM1.
But the ReplyTo Alias can change the Reply2Q and/or the Reply2QM values to whatever the MQ Admin desires the request message to have.
For ApplIdentityData, if the putting app can't/won't explicitly set it to the desired value, I guess you need an exit, or route the message thru an intermediate app like WMB to massage the header or data before forwarding it to the final request queue. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
LouML |
Posted: Wed Dec 04, 2013 7:07 am Post subject: |
|
|
 Partisan
Joined: 10 Nov 2005 Posts: 305 Location: Jersey City, NJ / Bethpage, NY
|
mqjeff wrote: |
If you were to do this with an exit, I might prefer to do it with an API exit that intercepted the MQPUT.
That way if something breaks, it's much closer to where the app itself lives. You can give better feedback to the app about errors, likely, and you don't run the risk of the channel or the MCA crashing or discarding messages.
But I'd prefer not to use an exit. In general.
But, you know, that's just, like, my opinion, man. |
I like the API Exit idea and will look into that to at least gain some knowledge about exits.
PeterPotkay wrote: |
The ReplyToQueueManager can be forced to whatever the MQ Administrator decides by definging a ReplyTo Alias queue. These little beasties are rarely used or even mentioned much but they are perfect for just this scenario. The app connected to QM1 will code MY.REPLY.QUEUE for the request message's Reply To Queue, and leave the Reply To QM blank, anticipating that the request message will be sent with MQMD_Reply2Q=MY.REPLY.QUEUE and MQMD_ReplyToQM=QM1.
But the ReplyTo Alias can change the Reply2Q and/or the Reply2QM values to whatever the MQ Admin desires the request message to have.
For ApplIdentityData, if the putting app can't/won't explicitly set it to the desired value, I guess you need an exit, or route the message thru an intermediate app like WMB to massage the header or data before forwarding it to the final request queue. |
I think we're going with the External Comapny's suggestion about the script. It'll be a lot less work.
Thanks guys for the quick replies. _________________ Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
Back to top |
|
 |
JosephGramig |
Posted: Wed Dec 04, 2013 7:18 am Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
If you have WMB available, clearly it will be the least amount of work and the most reliable solution. This would be a trivial flow. Copy the whole msg and modify two MQMD fields. This is the point of WMB. |
|
Back to top |
|
 |
LouML |
Posted: Wed Dec 04, 2013 8:15 am Post subject: |
|
|
 Partisan
Joined: 10 Nov 2005 Posts: 305 Location: Jersey City, NJ / Bethpage, NY
|
JosephGramig wrote: |
If you have WMB available, clearly it will be the least amount of work and the most reliable solution. This would be a trivial flow. Copy the whole msg and modify two MQMD fields. This is the point of WMB. |
No WMB here. _________________ Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
Back to top |
|
 |
RogerLacroix |
Posted: Wed Dec 04, 2013 6:04 pm Post subject: Re: Message Exit to modify ApplIdentityData? |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
LouML wrote: |
We need to send messages to an External Company. They need us to send them a specific value for ApplIdentityData and ReplyToQMgr. Unfortunately, the application that Puts the messages to the QRemote is not coded to set these values (and apparently, cannot be changed to do so). |
Well, if I was the cook, I would definitely not do it in an exit (even though, I could do it).
The simplest solution (besides WMB) is to go and grab the MMX code (free open source). Go to the 'PutMessage' routine, after the memcpy line, add your 2 lines of code.
i.e.
Code: |
strncpy(md.ApplIdentityData, "blah,blah,blah",MQ_APPL_IDENTITY_DATA_LENGTH);
strncpy(md.ReplyToQMgr, "QMgrName",MQ_Q_MGR_NAME_LENGTH); |
One minute of coding, compile & link and you are done.
Regards,
Roger Lacroix
Capitalware Inc. _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
LouML |
Posted: Thu Dec 05, 2013 1:56 am Post subject: Re: Message Exit to modify ApplIdentityData? |
|
|
 Partisan
Joined: 10 Nov 2005 Posts: 305 Location: Jersey City, NJ / Bethpage, NY
|
RogerLacroix wrote: |
LouML wrote: |
We need to send messages to an External Company. They need us to send them a specific value for ApplIdentityData and ReplyToQMgr. Unfortunately, the application that Puts the messages to the QRemote is not coded to set these values (and apparently, cannot be changed to do so). |
Well, if I was the cook, I would definitely not do it in an exit (even though, I could do it).
The simplest solution (besides WMB) is to go and grab the MMX code (free open source). Go to the 'PutMessage' routine, after the memcpy line, add your 2 lines of code.
i.e.
Code: |
strncpy(md.ApplIdentityData, "blah,blah,blah",MQ_APPL_IDENTITY_DATA_LENGTH);
strncpy(md.ReplyToQMgr, "QMgrName",MQ_Q_MGR_NAME_LENGTH); |
One minute of coding, compile & link and you are done.
Regards,
Roger Lacroix
Capitalware Inc. |
Good idea. We already use MMX to split messages when doing parallel testing. I was going to combine the amqsget/amqsput samples and make one program. _________________ Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
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
|
|
|
|