| Author |
Message
|
| geewee |
 Posted: Tue Jul 31, 2012 8:29 am Post subject: setting rfh2 usr props using java client |
 |
|
Apprentice
Joined: 31 Jul 2012
Posts: 28
|
We are on V7. The consuming application is an unmodified V6 application, migrated to V7, so it does not set any MQGMO options.
In V7 there is support for message properties. These properties are kind of like user extendable MQMD. This is a new feature introduced in V7, did not exist in V6.
In V6 application-defined properties would typically be added to the RFH2 usr folder. This is used to transport any application-defined properties associated with the message. This folder is present only if the application has set some application-defined properties.
when a message containing message properties are sent to older queue managers, the message properties are exposed as MQRFH2 headers.
Using PROPCTL channel options it is possible to control which message properties are included in a message sent from V7 queue manager to earlier versions of queue manager.
Using MQGMO message property option settings it is possible to control how properties are returned to application on MQGET.
Using PROPCTL queue options it is possible to control how message properties are returned to an application without setting MQGMO message property options. PROPCTL is set to default value COMPAT.
I am free to do whatever is necessary on the java client side, so using base classes or JMS would be just fine. But it is not possible to modify consuming application, or the queue/channel configuration. I am just introducing an additional java client sending messages to this same integration queue, and regression testing existing integrations is not an option.
I do see, through testing, that when I use rfhutil, and add properties in Usr Prop tab, I am able to get expected behaviour on consuming application, see initial posting.
On the consuming app side I can see the properties are available in MQRFH2 usr
usr
prop1
CHARACTER:val1
I am currently populating the message properties using java base classes, and I can see them available on consuming application side, in the MQRFH2 usr folder. But they contain a dt element (data type), which is the first child element:
usr
prop1
dt:CHARACTER:string
CHARACTER:val1
So when consuming app is using getFirstChild to retrieve value of prop1 it get string, and not the expected value val1.
String value = prop1Element.getFirstChild().getValueAsString();
I can see a posting on this mqmessage.setStringProperty adding a dt="string"
dt=string
but no info on how to avoid this addtional data type element.
Will this addtional data type element be added also if using JMS?
Last edited by geewee on Wed Aug 01, 2012 10:28 am; edited 2 times in total |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Jul 31, 2012 8:37 am Post subject: Re: setting rfh2 usr props using java client (base or jms) |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| geewee wrote: |
| The User Guide for RFHUtil explains that the usr folder is for use with properties stored as RFH2 headers (old V6 style) and that the User Props tab is for V7. |
You need to pay attention to this.
Broker uses the old style of properties - the RFH header. The code you have in your JavaCompute node reads those.
You need to make sure your message produces the old style. This doesn't strictly require that you write your own RFH2, but you need to spend some time researching this difference and make sure you understand what it's saying and how it affects the message and what steps need to be taken.
Let me repeat.
You need to UNDERSTAND the difference between message properties and the user folder in the MQRFH2 header, and UNDERSTAND how MQ v6 and MQ v7 handle these (or don't) and what options are available to work with them. |
|
| Back to top |
|
|
| geewee |
| Posted: Wed Aug 01, 2012 1:54 am Post subject: |
|
|
Apprentice
Joined: 31 Jul 2012
Posts: 28
|
thanks for the reply.
I have updated the initial posting to make the issue more clear, but your comment is still valid.
I will experiment a little further on how to generate properties without this addtional data type element, that is causing the problems. Maybe the JMS libraries can do this without adding this additional data type element/attribute |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 01, 2012 5:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| geewee wrote: |
thanks for the reply.
I have updated the initial posting to make the issue more clear, but your comment is still valid.
I will experiment a little further on how to generate properties without this addtional data type element, that is causing the problems. Maybe the JMS libraries can do this without adding this additional data type element/attribute |
Make easier on you... When you look at the element using a compute node, look for the first child with TYPE element... or even if you know it with NAME xyz.... This way no matter whether or not you have an extra datatype attribute you should get what you expect...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| geewee |
| Posted: Wed Aug 01, 2012 10:51 pm Post subject: |
|
|
Apprentice
Joined: 31 Jul 2012
Posts: 28
|
The java compute is looking for prop1 value using the two lines of code below, first looking for element by name, and then trying to retrieve value of element as first child.
MbElement prop1Element = inputRfh.getFirstElementByPath("prop1");
String prop1val = prop1Element.getFirstChild().getValueAsString();
I am not able to change this java compute node code, but what would be the way of coding this to actually retrieve the value of prop1-element, and skip over the current existing dt child on this element.
Could of course use getLastChild, but it looks like different api's append children to this prop1Element in a non-consistent way.
com.ibm.mq.MQMessage,setStringProperty add this additional dt description. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 02, 2012 4:33 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Check the API. If you can't specify the type as you go to the first child and don't know the name (repeat of previous line) you will need to iterate over the children, check the type / name as you go through them and exit when you found the right one...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Aug 02, 2012 4:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
Check the API. If you can't specify the type as you go to the first child and don't know the name (repeat of previous line) you will need to iterate over the children, check the type / name as you go through them and exit when you found the right one...
Have fun |
I think you're missing the point.
He or she can not change the code that reads the property.
He or she can only change the code that write the property, and is having difficulty getting it to write the property in a manner that is compatible with the old code that reads it.
The only positive suggestion I have at this point is to set PROPCTL to FORCE. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 02, 2012 8:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
| fjb_saper wrote: |
Check the API. If you can't specify the type as you go to the first child and don't know the name (repeat of previous line) you will need to iterate over the children, check the type / name as you go through them and exit when you found the right one...
Have fun |
I think you're missing the point.
He or she can not change the code that reads the property.
He or she can only change the code that write the property, and is having difficulty getting it to write the property in a manner that is compatible with the old code that reads it.
The only positive suggestion I have at this point is to set PROPCTL to FORCE. |
Worth a try. However as I recall using propctl=compat when the property was written V7 style in java base and read in the RFH2 it contained the type identifier as an attribute...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
