| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Any reason not to grant config mgr rights to broker userid? |
« View previous topic :: View next topic » |
| Author |
Message
|
| rekarm01 |
 Posted: Tue Sep 16, 2008 6:43 pm Post subject: Any reason not to grant config mgr rights to broker userid? |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
I'm using the Configuration Manager Proxy within a Java Compute node, to automatically stop a message flow under specific circumstances. (Please don't ask why - it's a business requirement.)
It fails because the broker user id does not have permission to view/deploy objects (BIP1711W: The ConfigManagerProxy is not viewable by user ... )
Our broker admins are reluctant to add the broker user id to the Config Mgr ACL to grant the necessary permissions, because they think they remember that IBM doesn't recommend doing that. I think they are double checking to verify that.
In the meantime, is there any particular reason why we shouldn't grant config mgr view/deploy access rights to the broker user id? Is there a better way to accomplish what I need to do? |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Tue Sep 16, 2008 10:05 pm Post subject: An Interesting Question |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Using the Proxy API to stop a message flow is a god idea but I don't see doing it directly from the flow a good choice of place to do this action.
Stopping the message flow takes some time to achieve. By this I mean the time you should wait for broker to send its success/fail message on the Stop Operation. This delay has the potential to block the flow that is doing this work from processing any more data.
So with this in mind, I'd just send a message using an MQOutput node to a queue and let something else process the mqsistopmsgflow.
The destination queue would be setup to trigger an Application which would in turn use the Proxy API. Any issues here could be logged directly by the application.
I use this type of methodology at several customers in order to do things which are not easily done inside broker OR should not be done inside a broker flow.
I treat Broker as a high performance message processing system. Trying to get it to do things (in Process Server speak) like 'Human Interaction' is IMHO just plain silly. I'd rather hive these off to separate entities.
I had a case where the customer requirement was for something like yours that involved a flow that was processing 500,000+ messages per business day. It turned out that splitting out the slow stuff from the real purpose of the flow was the right way to go.
Your particular requirement might be different though.
And yes, I'm from the old school of MQ users and can write C or Java code to handle MQ Triggering.
_________________
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 |
|
|
| rekarm01 |
| Posted: Wed Sep 17, 2008 3:56 am Post subject: Any reason to forbid broker-id deploy rights to config mgr? |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| Quote: |
Using the Proxy API to stop a message flow is a good idea but I don't see doing it directly from the flow a good choice of place to do this action.
Stopping the message flow takes some time to achieve. By this I mean the time you should wait for broker to send its success/fail message on the Stop Operation. This delay has the potential to block the flow that is doing this work from processing any more data. |
Our particular requirement is to stop a message flow when it is no longer processing messages normally, but it's throwing certain types of Exceptions instead.
While we're trying to stop the message flow, it can either keep on throwing Exceptions, or it can block and wait for a CMP success/fail response from the config mgr.
It doesn't really matter much either way, but personally, I'd rather have the message flow block and wait, even if that takes some time.
It seems to me that the best way to accomplish that is to put the CMP stop call within the message flow itself.
Maybe one reason to move the CMP call to an external application is so that I can run it with a different user id, ... if that were something I really needed to do.
... Which brings me back to my first question:
Is there any good reason to forbid the broker user id from stopping message flows, via the Configuration Manager Proxy? |
|
| 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
|
|
|
|
