| Author |
Message
|
| elesair |
 Posted: Mon Oct 08, 2007 12:54 am Post subject: Message sorting based on header information |
 |
|
Newbie
Joined: 08 Oct 2007
Posts: 6
|
Hi there,
I am trying to put some custom information into a message header, so that the receiving application can sort the messages based on the information contained therein. I was wondering the best way to do this. I have tried to modify the correl id and msg id fields with no success. Also the applIdData field, but i don't have the permission on the Q manager (not administered by me) to set all id context.
Which fields in the MQMD would be the best to modify, or if there is a better way to add meta data to the message so that the receiving app can sort them.
P.s its Mq v 5.2 running on a solaris server
Many thanks,
A. |
|
| Back to top |
|
 |
| AkankshA |
| Posted: Mon Oct 08, 2007 1:13 am Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
| Quote: |
| I have tried to modify the correl id and msg id fields with no success. |
What happens when u do this?? hope you are taking the bytes n format into account
| Quote: |
| or if there is a better way to add meta data to the message so that the receiving app can sort them. |
Sort them based on... may be priority or something...
| Quote: |
| P.s its Mq v 5.2 running on a solaris server |
pls upgrade
_________________
Cheers |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 08, 2007 1:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Ok, in order:
1) Don't run v5.2. It's way, way old, out of support and just wrong. Upgrade.
2) Don't set either of the id fields, especially with business data. There are numerous posts on why this is a bad idea.
3) If you can't set context (as per your post) then you're stuffed. Put an RFH2 header in the message and include your data in the <usr> section
4) You do mean that the application is reading them off, storing them externally and sorting them there don't you? You're not planning on sorting the messages and holding them in the queue in order are you?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| elesair |
| Posted: Mon Oct 08, 2007 1:23 am Post subject: |
|
|
Newbie
Joined: 08 Oct 2007
Posts: 6
|
Hi, thanks for the quick reply,
1) I'm pretty sure its 5.2, might be 6 (again im not the admin, dont have cli access to the mq commands, this is extremely frustrating!!)
2) Yeah just read those posts on not messing with msgId and correlId
3) Supposedly its a security concern to allow us to set id context, we're not using ssl to connect, so the mq admins won't let us have permissions to modify it. I'll have a google for RFH2, don't know what it is.
4) Yeah to clarify, i'm not sorting them on the queue, the receiving application picks them off and will process the files based on their meta-data.
The other option is just to create a queue for each type of message (around 4 different types) and route them in our application internally first of all, then output to different queues. This is not ideal though, as the whole idea of the project is to reduce the total number of connections to as few as possible.
Many thanks
Al. |
|
| Back to top |
|
|
| elesair |
| Posted: Mon Oct 08, 2007 1:29 am Post subject: |
|
|
Newbie
Joined: 08 Oct 2007
Posts: 6
|
| Quick update : just asked the MQ admins, its 5.3 we're using, if that makes any difference. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 08, 2007 1:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| elesair wrote: |
| I'll have a google for RFH2, don't know what it is. |
Rules and Formatting Header version 2. It's described in the Application Programming Guide / Reference.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Mon Oct 08, 2007 1:40 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
Hi
Did you see some attribute called RFH_MSgtype after adding RFH header
Please use that bias the messages
Regards
Gayathri
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| elesair |
| Posted: Mon Oct 08, 2007 1:45 am Post subject: |
|
|
Newbie
Joined: 08 Oct 2007
Posts: 6
|
Hmm then it would appear that i am stuffed. Theoretically though, if i could set the id context what would be the procedure for doing this? Which fields would be the best to use?
Al |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 08, 2007 1:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| elesair wrote: |
Which fields would be the best to use?
|
ApplIdentityData which you've already selected is the one to use. Possibly the AccountingToken if you're not using that for something else (typically it's not used).
Personally I'd use the RFH2 as that removes the limit on data length and allows some structure to the data. In this case it also allows your admins to leave their security alone & not panic. But that's just me and does depend on the actual requirement you're trying to meet.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 08, 2007 2:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| elesair wrote: |
| Hmm then it would appear that i am stuffed. |
Why? If you've got a legitimate business requirement to be setting context, push back on the admins and get them to relax their rules. You're not asking them to throw the system wide open.
Bottom line - the system exists to service the business. If the constraints of the system affect the business, they need to relax. If you take the opposing view to it's logical extreme, the system would be made totally secure by removing all access and therefore all access risks. System stability & availablity could be raised to 100% by installing it on a machine which is then immediately switched off and sealed in a secure vault. It would never crash or need maintenance again (though I accept the definition of "available" would need a little revision!  )
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| elesair |
| Posted: Mon Oct 08, 2007 2:09 am Post subject: |
|
|
Newbie
Joined: 08 Oct 2007
Posts: 6
|
| Oh if only enlightened people like you administered MQ here! Yeah i'm going to lean on them, its holding up our development and is quite frankly ridiculously paranoid of them. Again many thanks for everyone's help. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 08, 2007 2:46 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
As well you did not specify what your programing language is...
Some languages / API's allow more flexibility/ease of use than others...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| elesair |
| Posted: Mon Oct 08, 2007 3:52 am Post subject: |
|
|
Newbie
Joined: 08 Oct 2007
Posts: 6
|
So just to get this straight we want to open the queue with MQOO_PASS_IDENTITY_CONTEXT and put options as MQPMO_PASS_IDENTITY_CONTEXT?
Cheers
Al |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 08, 2007 5:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Or set context, depending.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
