Author |
Message
|
70033 |
Posted: Fri Sep 10, 2010 1:52 pm Post subject: MQRFH2 vs MQSTR |
|
|
Apprentice
Joined: 22 Dec 2008 Posts: 27
|
I understand that MQRFH2 is to be used when the target client is JMS and the MQRFH2 adds JMS specific fields like JMSDestination,etc to the message.
My question is if i were to send it in this format and if i have a MDB listening on the queue when it does a get will it get the message without all the header information . I am referring to some extra characters that i see in the MQ explorer when i browse the message. If consumed by a java MDB consumer will i still see this extra characters or will i get the message that i originally put.. |
|
Back to top |
|
 |
Gaya3 |
Posted: Fri Sep 10, 2010 2:37 pm Post subject: Re: MQRFH2 vs MQSTR |
|
|
 Jedi
Joined: 12 Sep 2006 Posts: 2493 Location: Boston, US
|
70033 wrote: |
I understand that MQRFH2 is to be used when the target client is JMS and the MQRFH2 adds JMS specific fields like JMSDestination,etc to the message.
.. |
I do not agree completely with you, as you can even pass in MQRFH2 information for different business scenarios as well.
say you would like to pass user id, or file name details to the target location or even to another broker flow a kind of
70033 wrote: |
My question is if i were to send it in this format and if i have a MDB listening on the queue when it does a get will it get the message without all the header information . I am referring to some extra characters that i see in the MQ explorer when i browse the message. If consumed by a java MDB consumer will i still see this extra characters or will i get the message that i originally put.. |
you can configure your MDB to fetch only the payload _________________ Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Sep 10, 2010 6:37 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Read up if you can about linked headers and experiment more with JMS.
A little experimentation would immediately answer your question...
And lucky for you, to prove a concept and experiment you can use JMS in a standalone little app.
Yes there are a few caveats of standalone vs J2EE appserver, but looking at the big picture you can model nearly everything in a standalone app.
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
70033 |
Posted: Mon Sep 13, 2010 7:56 am Post subject: |
|
|
Apprentice
Joined: 22 Dec 2008 Posts: 27
|
I shouldnt have specified mdb in this question actually.. if i had a java consumer(a JMS program doing a get) then would the JMS program need to worry whether the request was send in a MQRFH2 or a MQSTR format? |
|
Back to top |
|
 |
Vitor |
Posted: Mon Sep 13, 2010 8:06 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
70033 wrote: |
. if i had a java consumer(a JMS program doing a get) then would the JMS program need to worry whether the request was send in a MQRFH2 or a MQSTR format? |
Yes. If the application doing the get is using JMS and the message doesn't have a MQRFH2 header many of the JMS properties will be missing. How the receiving application reacts to that is a question of coding; assuming the JMS layer would even pass the message to the consuming application (a question I'll leave to more experienced posters).
Answering your original question, the format of the message (extra characters or not) is opaque to the reading application. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Sep 13, 2010 12:14 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
70033 wrote: |
I shouldnt have specified mdb in this question actually.. if i had a java consumer(a JMS program doing a get) then would the JMS program need to worry whether the request was send in a MQRFH2 or a MQSTR format? |
It really depends now on the content of the MQFRH2 format field, doesn't it?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
|