| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Testing a MQ environment |
« View previous topic :: View next topic » |
| Author |
Message
|
| mpeter |
 Posted: Fri Oct 19, 2007 6:01 am Post subject: Testing a MQ environment |
 |
|
Newbie
Joined: 20 Aug 2007
Posts: 4
|
Hello all,
I'm currently investigating the best way to do automated testing in an MQ environment. We're standing up over 30 different enterprise applications which are in various stages in their development lifecycle. We've started from a blank-slate environment, so there's not a whole lot of legacy concerns Most of these systems run on J2EE or .NET platforms, pass XML or SOAP traffic, and follow a request-reply or fire-and-forget model. Some applications have extremely restricted access to the MQMD/MQRFH2 headers, so we're trying to find a solution that does not require applications to make coding changes. The issue we're trying to address is around testing.
We'd like to run test automation tools that can simulate a message sender (PUT/GET). The issue we're running into is that there's no good way to prevent a source system from also listening to the GET queue and effectively 'stealing' a message that's destined for the automation tool. We'd like to do this with as little disruption to the source system as possible. A few thought's we've had:
- Stop the channel the source application is using. Each application is using a different channel. This sometimes causes issue with the source application, as well as preventing it from accessing the entire MQ environment, rather than just the queue in question
- Remove privileges from a specific queue for a specific application id, using PCF messages. The issue is that right now everyone is using the 'mqm' user, and we're going to have to ask everyone to start using a different app id, which may or may not be possible in all cases.
Does anyone have any thoughts about the two approaches, or can perhaps suggest a more effective alternative approach?
Thanks! |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Oct 19, 2007 6:56 am Post subject: Re: Testing a MQ environment |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mpeter wrote: |
| - Stop the channel the source application is using. Each application is using a different channel. This sometimes causes issue with the source application, as well as preventing it from accessing the entire MQ environment, rather than just the queue in question |
Applications use queues not channels (even J2EE under the covers). If you really have a channel <-> queue correlation that's a bit inefficient. Queues cannot be stopped in the same way channels can.
| mpeter wrote: |
- Remove privileges from a specific queue for a specific application id, using PCF messages. The issue is that right now everyone is using the 'mqm' user, and we're going to have to ask everyone to start using a different app id, which may or may not be possible in all cases. |
Having all the applications running with the mqm user is a hideously bad idea. It's a security exposure the size of a 747 and there is no good reason for it. Nor should it require a coding change to resolve.
Especially if you meant each application uses it's own SVRCONN channel (doh!  ).
There used to be an application called LoadRunner from Mercury that could do the sort of thing you're looking at.
(No recommendation, endorsement or commendation is intended by this statement, nor is this statement intended in any way to indicate the fitness or not of this product for any particular organisation or task)
 [/i]
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Oct 19, 2007 7:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
SupportPac MA0T provides a good testing tool for MQ.
No test tool is going to resolve issues with controlling what application can get what message from a given queue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mpeter |
| Posted: Fri Oct 19, 2007 8:12 am Post subject: |
|
|
Newbie
Joined: 20 Aug 2007
Posts: 4
|
| Quote: |
| Applications use queues not channels (even J2EE under the covers). If you really have a channel <-> queue correlation that's a bit inefficient. Queues cannot be stopped in the same way channels can. |
Perhaps I was not clear. Each application has been given a channel to access the middleware, so stopping the channel effectively prevents a source system from getting or putting messages to a queue.
| Quote: |
Having all the applications running with the mqm user is a hideously bad idea. It's a security exposure the size of a 747 and there is no good reason for it. Nor should it require a coding change to resolve.
Especially if you meant each application uses it's own SVRCONN channel (doh! ). |
We're aware of this, there are no production systems currently active. The plan is to follow the MQ Security Best Practices. Each system has its own SVRCONN, correct.
| Quote: |
| No test tool is going to resolve issues with controlling what application can get what message from a given queue. |
This confirms my suspicions I think.. Either of the approaches should work, but my thought was that stopping/starting a channel is a blunt approach that may cause problems down the road. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 19, 2007 12:14 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Its not clear what you are trying to test exactly. Are you trying to prove a message can go in and out of every specific app queue? If yes, why?
Or in and out of any queue just to prove the QM is up and available?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mpeter |
| Posted: Mon Oct 22, 2007 5:56 am Post subject: |
|
|
Newbie
Joined: 20 Aug 2007
Posts: 4
|
| Quote: |
| Its not clear what you are trying to test exactly. Are you trying to prove a message can go in and out of every specific app queue? If yes, why? |
No, we are not trying to test that functionality. We are interested in doing automated testing on a daily basis of system functionality, which is also called 'regression testing', or sometimes 'environment certification'. It has nothing to do with the middleware, rather it's an attempt to test the system functionality itself.
~ Matt |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Oct 22, 2007 6:07 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I see. You want to test the application, of which MQ is only 1 part of.
The best way to do this is have your automation tool send messages that the app can recognize as test message so you can send them thru anytime you like without disrupting the real messages. Your automation tool becomes just another end user.
IMHO inhibiting queues and/or flipping authorizations is asking for trouble. The best way to test a system is to use it as close as possible to the way the real users would.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
