|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Verification needed - about how to include RFH2 header |
« View previous topic :: View next topic » |
Author |
Message
|
anh |
Posted: Fri Jan 06, 2012 2:04 am Post subject: Verification needed - about how to include RFH2 header |
|
|
Newbie
Joined: 03 Jan 2012 Posts: 3
|
I am very new to JMS & WMQ. Really appreciate if you guys can help to verify the below points. Thank you.
- When a JMS client sends a message via WMQ to another JMS client, the administered receiving queue object should have TARGCLIENT(JMS) which can be set via JMSAdmin. The RFH2 header will be auto created in the respective MQ message.
- When a JMS client sends a message via WMQ to another Non-JMS client, the administered receiving queue object should have TARGCLIENT(MQ). The RFH2 header will NOT be auto created in the respective MQ message.
- When a Non-JMS client sends a message via WMQ to another JMS client, the administered receiving queue object should have TARGCLIENT(JMS). The RFH2 header will be auto created in the respective MQ message.
- I am not sure about the TARGCLIENTMATCHING property of the QCF object. I think TARGCLIENTMATCHING(YES) for JMS-to-JMS communication, and TARGCLIENTMATCHING(NO) for JMS-to-(Non-JMS) communication.
Please help! |
|
Back to top |
|
 |
zpat |
Posted: Fri Jan 06, 2012 2:31 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Target can be NONJMS as well.
JMS apps can also receive non JMS messages - to avoid any dependency that is my preference (MQMD.Format = MQSTR) for all messages.
It's a basic principle of messaging to decouple the sender and receiver as much as possible.
This can be set programmatically, which avoids the dependency on getting the QCF values correct. |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Jan 06, 2012 7:58 am Post subject: Re: Verification needed - about how to include RFH2 header |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
anh wrote: |
I am very new to JMS & WMQ. Really appreciate if you guys can help to verify the below points. Thank you.
- When a JMS client sends a message via WMQ to another JMS client, the administered receiving queue object should have TARGCLIENT(JMS) which can be set via JMSAdmin. The RFH2 header will be auto created in the respective MQ message. |
Correct
anh wrote: |
- When a JMS client sends a message via WMQ to another Non-JMS client, the administered receiving queue object should have TARGCLIENT(MQ). The RFH2 header will NOT be auto created in the respective MQ message. |
Correct
anh wrote: |
- When a Non-JMS client sends a message via WMQ to another JMS client, the administered receiving queue object should have TARGCLIENT(JMS). The RFH2 header will be auto created in the respective MQ message. |
This is not correct. The JMS classes for WMQ will handle the fact that the RFH is absent. Some properties will not be available.
anh wrote: |
- I am not sure about the TARGCLIENTMATCHING property of the QCF object. I think TARGCLIENTMATCHING(YES) for JMS-to-JMS communication, and TARGCLIENTMATCHING(NO) for JMS-to-(Non-JMS) communication.
Please help! |
Wrong. TargetClientMatching is used by the server when doing a request reply scenario.
With TargetClientMatching set to True the reply to information will get created without an RFH header if the request did not have an RFH header (see JMSReplyTo Destination), and created with an RFH header if the requester had an RFH header.
Although that might be a little bit different now with V7 where properties are available in native mode and no longer need an RFH.
Have fun experimenting and learning  _________________ MQ & Broker admin |
|
Back to top |
|
 |
anh |
Posted: Wed Feb 29, 2012 1:23 am Post subject: |
|
|
Newbie
Joined: 03 Jan 2012 Posts: 3
|
Many thanks! I've been reading & reading about JMS RFH2 on IBM info center, but it's not so helpful when I can't experiment with RFH2 in my company system. So I really appreciate your replies! I am still not clear about the below points:
Quote: |
Although that might be a little bit different now with V7 where properties are available in native mode and no longer need an RFH. |
By this, do you mean all the necessary properties are available in MQMD and RFH2 is not needed? In what case that it applies? I can't find such statement in IBM WMQ version 7 info center. Can you pls give me the url of this?
I read the Info center about WMQ classes for JMS -> What's new in WMQ v7 (http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzaw.doc%2Fjm35120_.htm), and my understanding is that:
- A non-JMS application must include RFH2 when it communicates with JMS application. In the case that the non-JMS app doesn't include RFH2, it can use MQSETMP call to set the values of message properties instead of constructing RFH2. Without RFH2, some JMS-specific properties will be lost.
- Also, I'm not so clear about the Info Center statement:
Quote: |
When an application calls MQGET to receive a message from a WebSphere MQ classes for JMS application, the application can choose to receive the message in one of the following ways:
1) The message is delivered with a message descriptor, an MQRFH2 header that contains data derived from JMS header fields and properties, and the application data.
2) The message is delivered with a message descriptor, the application data, and a set of message properties.
|
My question is how the application can choose the format of the coming message? Does it mean even the coming message contain RFH2, the non-JMS app can treat RFH2 as a set of message properties, and then use MQINQMP call to retrieve certain properties? |
|
Back to top |
|
 |
Vitor |
Posted: Wed Feb 29, 2012 3:44 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
anh wrote: |
By this, do you mean all the necessary properties are available in MQMD and RFH2 is not needed? |
Message properties are not stored in the MQMD but do replace the RFH2. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
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
|
|
|
|