Author |
Message
|
tony_f |
Posted: Fri Sep 30, 2011 2:21 am Post subject: How to set expiration on Event Monitor messages |
|
|
Novice
Joined: 30 Sep 2011 Posts: 19
|
Hi
I have added event monitoring to the input terminal of an MQ Output node and it has created a topic the subscription to which outputs to a local queue. My question is ; how can I set the subscription messages to expire, say after three days? |
|
Back to top |
|
 |
lancelotlinc |
Posted: Fri Sep 30, 2011 4:24 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
|
Back to top |
|
 |
tony_f |
Posted: Fri Sep 30, 2011 4:37 am Post subject: |
|
|
Novice
Joined: 30 Sep 2011 Posts: 19
|
lancelotlinc wrote: |
Code: |
SET OutputRoot.MQMD.Expiry = <whatever value> |
|
Hi Thanks for the response.
I thought maybe I could do that, but that would also affect the expiry time of any other message I output in the node wouldn't it? I was hoping there was some way of just setting the expiry for the monitor messages. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Fri Sep 30, 2011 5:04 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
|
Back to top |
|
 |
Vitor |
Posted: Fri Sep 30, 2011 5:07 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
lancelotlinc wrote: |
Code: |
SET OutputRoot.MQMD.Expiry = <whatever value> |
|
I thought the monitor messages were published by the broker and independant of any node settings...
Does this work on other monitoring enabled nodes? How would you implement this on an MQInput node (or any node with no ESQL support)? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Fri Sep 30, 2011 5:07 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
lancelotlinc wrote: |
Use separate nodes for separate purposes. |
How do you use a separate node to issue monitoring events??  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Fri Sep 30, 2011 5:10 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
I'm suggesting one way to set an Expire on messages. I am hoping the OP has enough training from IBM on how to use Broker to accomplish his goal. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
Vitor |
Posted: Fri Sep 30, 2011 5:23 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
lancelotlinc wrote: |
I'm suggesting one way to set an Expire on messages. |
But that's not what the OP is asking; he's trying to influence event messages not normal ones.
lancelotlinc wrote: |
I am hoping the OP has enough training from IBM on how to use Broker to accomplish his goal. |
I think your hopes will be met, as he's correctly identified that setting expiry on the MQMD in the MQOutput affects the output message.
What he (and I) am having trouble with is how setting the MQMD in the message tree affects the monitor event message publication. I accept it's a while since I had any broker training but I'm not familiar with this mechanism, and don't see how it could apply to monitor messages from nodes where the header is not directly editable. Also how your suggestion for "separate nodes" can be made to apply to monitoring.
Throw a fish eh? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
zpat |
Posted: Fri Sep 30, 2011 5:52 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
I don't think you can influence the exiry value or the persistence etc of automatically generated node event messages.
Easiest thing to do is immediately process them in another simple message flow which adjust the MQ header to be the way you want it and puts them to another queue for storage.
Last edited by zpat on Fri Sep 30, 2011 5:57 am; edited 1 time in total |
|
Back to top |
|
 |
smdavies99 |
Posted: Fri Sep 30, 2011 5:55 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
zpat wrote: |
I don't think you can influence the exiry value or the persistent etc of automatically generated node event messages.
Easiest thing to do is immediately process them in another simple message flow which adjust the MQ header to be the way you want it and puts them to another queue for storage. |
 _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
Vitor |
Posted: Fri Sep 30, 2011 5:58 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
smdavies99 wrote: |
zpat wrote: |
I don't think you can influence the exiry value or the persistent etc of automatically generated node event messages.
Easiest thing to do is immediately process them in another simple message flow which adjust the MQ header to be the way you want it and puts them to another queue for storage. |
 |
But I'm still looking out for a fish from lancelotlinc _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Fri Sep 30, 2011 6:11 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
You could do this with an intermediate flow, as an ESB is designed to be the intermediary.
Always dream of the possible. If you continuously say its impossible, you'll not achieve new heights.
So, my suggestion was a leading one, hoping the OP would create creative solutions to the problem at hand and be an independent enough thinker to dream a little bit. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
Vitor |
Posted: Fri Sep 30, 2011 6:44 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
lancelotlinc wrote: |
So, my suggestion was a leading one, hoping the OP would create creative solutions to the problem at hand and be an independent enough thinker to dream a little bit. |
What?
How creative do you need to be to get from the suggestion of inserting a line of code in the node you're monitoring to get to writing an intermediate flow to process the messages? I mean seriously, that's a leap.
lancelotlinc wrote: |
You could do this with an intermediate flow |
Ok, fish me with your creativity. How else could you do this? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Fri Sep 30, 2011 6:57 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
|
Back to top |
|
 |
Vitor |
Posted: Fri Sep 30, 2011 6:59 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Again, how do you get the event publisher to use this? How do you get the published event message to behave like you're building a message and putting it? I accept there are any number of way to set expiry on a user generated message but how do you apply them to event publications? _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|