| Author |
Message
|
| vimal |
 Posted: Mon Mar 06, 2017 10:19 am Post subject: MQRF2 in MQv7 |
 |
|
Novice
Joined: 03 Sep 2009
Posts: 10
|
| A JMS application is putting a message in a MQv7 queue manager queue but the payload includes the JMS headers as xml elements. I am trying to avoid the JMS elements in the payload. Please advise. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Mar 06, 2017 10:26 am Post subject: Re: MQRF2 in MQv7 |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vimal wrote: |
| Please advise. |
1) Realize that the "xml elements" are not in the payload but in an RFH2 header as your subject line correctly states
2) If the consuming application is non-JMS & can't handle this (and can't be corrected to handle this) have the JMS application set TARGCLIENT to indicate this and suppress the JMS information
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vimal |
| Posted: Mon Mar 06, 2017 11:37 am Post subject: MQRF2 in MQv7 |
|
|
Novice
Joined: 03 Sep 2009
Posts: 10
|
| The MQ queue does not have a corresponding JMS queue defined. Since the property you mentioned is a jms queue property, I suppose I should create one. I created one jms queue from a file system context with both targclient and msgbody properties set to MQ but that did not change the message data. Please advise. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 06, 2017 11:42 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Like I said, the JMS properties are not part of the message data but are part of the headers.
If you've set the JMS property to MQ and are still receiving a JMS format message then I would theorize that whatever you've done to set the property is incorrect and/or is not being honored by the JMS application.
You should investigate and fix either or both.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vimal |
| Posted: Mon Mar 06, 2017 1:13 pm Post subject: |
|
|
Novice
Joined: 03 Sep 2009
Posts: 10
|
| Source is an JMS application putting a message to a MQ queue, which inturn triggers a process defined for a legacy MQ application. Since it is expecting an MQ message, is not able to digest the JMS message because of the JMS properties in the message. Is there something I can do at the MQ resource level w/o touching the source or destination applications? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Mar 06, 2017 1:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vimal wrote: |
| Is there something I can do at the MQ resource level w/o touching the source or destination applications? |
No. Message format is entirely under the control of the application which puts the message to the queue. If the sending application is sending a JMS message to an application which expects a non-JMS message, then they have to work it out.
It's a tricky one. On the one hand, the "correct" solution is for the receiving application to ignore the RFH2 it's not interested in (which is an easy enough piece of code). On the other hand, your use of the word "legacy" implies that this application won't (or can't) be changed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 07, 2017 5:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Do you want to send the message WITH an RFH2 header?
Ignore the TARGCLIENT on the JMS Destination.
Do you want to send the message WITHOUT an RFH2 header?
Set the TARGCLIENT on the JMS Destination to the appropriate value.
| Vitor - I Don't Know Java wrote: |
| 2) If the consuming application is non-JMS & can't handle this (and can't be corrected to handle this) have the JMS application set TARGCLIENT to indicate this and suppress the JMS information |
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
|
|
