| Author |
Message
|
| md7 |
 Posted: Wed Feb 29, 2012 4:30 pm Post subject: MQ Client - Which server-connection channel? |
 |
|
Apprentice
Joined: 29 Feb 2012
Posts: 49
Location: Sydney.AU
|
Hi Guys first post here. My apologies if this has been posted before but I did a quick search and was unable to to find the answer I was looking for.
I'm running an MQ Server 7.0 environment and there are several external parties connecting with MQ Client 7. I have created a server-connection channel for each external party they have specified this channel in their environment variable MQSERVER on their Windows server. This works all fine but now there is a requirement to secure these channels with SSL.
I have tested this in our test environment have got it working by creating a matching client-connection channel and exporting the AMQCLCHL.TAB file to the client servers. By doing this makes the environment variable MQSERVER redundant. This all works fine when there is 1 MQ client. My question is when there is more than 1 MQ client how do you specify which server-connection channel that client is going to use? Thanks for any responses |
|
| Back to top |
|
 |
| exerk |
| Posted: Thu Mar 01, 2012 4:25 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Create a CCDT for each of your clients. Use the MO72 SupportPac to manage them. I'm sure others will be along to offer alternative advice.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Mar 01, 2012 5:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Using a client channel table does indeed make MQSERVER redundant. But that's what you're trying to do, because the default clntconn built by MQSERVER is not sufficient for your requirements.
The channel that is selected from the client channel table is matched based on the QM name that the application gives to MQCONN/MQCONNX.
So where you create one table with many clntconns, you set the QMNAME on each clntconn to a known value and then specify the correct value in the application configuration.
If the application is not setting *any* QM name on the MQCONN/MQCONNX, then you need different channel tables for EACH application.
And each application will use the channel table that is pointed to by the MQCHL* environment variables that are set in the environment running the application. Note that you should never set any MQ env variables at the system level, and always set them in an application specific context. |
|
| Back to top |
|
|
| md7 |
| Posted: Thu Mar 01, 2012 1:32 pm Post subject: |
|
|
Apprentice
Joined: 29 Feb 2012
Posts: 49
Location: Sydney.AU
|
| exerk wrote: |
| Create a CCDT for each of your clients. Use the MO72 SupportPac to manage them. I'm sure others will be along to offer alternative advice. |
Thanks for your reply. This maybe the approach I take |
|
| Back to top |
|
|
| md7 |
| Posted: Thu Mar 01, 2012 1:40 pm Post subject: |
|
|
Apprentice
Joined: 29 Feb 2012
Posts: 49
Location: Sydney.AU
|
| mqjeff wrote: |
Using a client channel table does indeed make MQSERVER redundant. But that's what you're trying to do, because the default clntconn built by MQSERVER is not sufficient for your requirements.
The channel that is selected from the client channel table is matched based on the QM name that the application gives to MQCONN/MQCONNX.
So where you create one table with many clntconns, you set the QMNAME on each clntconn to a known value and then specify the correct value in the application configuration.
If the application is not setting *any* QM name on the MQCONN/MQCONNX, then you need different channel tables for EACH application.
And each application will use the channel table that is pointed to by the MQCHL* environment variables that are set in the environment running the application. Note that you should never set any MQ env variables at the system level, and always set them in an application specific context. |
I'm not too sure what you mean by "specify the correct value in the application configuration." Our application is publishing messages to a specific topic and then we have multiple external parties subscribing. The number of external parties changes quite often. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Mar 01, 2012 1:57 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
When the application establishes a Connection, it specifies, in some manner, the name of the queue manager that it wishes to connect to.
Or, it does *not* specify that name, and ends up specifying the channel name, host name and port #.
If the application does specify a queue manager name, then it must match the QMNAME value on the CLNTCONN object you create in the channel table.
If the application does not specify a queue manager name, then it must stop specifying the hostname, channel, and port.
There is at least some discussion on this in the Clients manual. If you're using .NET or JMS, then it's a bit different, but not a lot. |
|
| Back to top |
|
|
| md7 |
| Posted: Mon Mar 05, 2012 3:58 pm Post subject: |
|
|
Apprentice
Joined: 29 Feb 2012
Posts: 49
Location: Sydney.AU
|
Hi Guys, thanks for your help.
I have been able to modify the Channel table using Support Pac M072. So now am able to have mulitple MQ clients connect using SSL connecting with their respective server-connection channels. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Mar 05, 2012 7:51 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| md7 wrote: |
Hi Guys, thanks for your help.
I have been able to modify the Channel table using Support Pac M072. So now am able to have mulitple MQ clients connect using SSL connecting with their respective server-connection channels. |
 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Mar 05, 2012 8:08 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Think of a channel as a door with a lock and key. What you have accomplished is somewhat like having one house with many different outside doors, each with a different (unique) lock and key. Giving one key to one individual really grants access to all of the valuables in the house.
Make sure that you also have security rules that restrict specific userids and applications to specific queues (and other objects).
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| md7 |
| Posted: Mon Mar 05, 2012 9:40 pm Post subject: |
|
|
Apprentice
Joined: 29 Feb 2012
Posts: 49
Location: Sydney.AU
|
| bruce2359 wrote: |
Think of a channel as a door with a lock and key. What you have accomplished is somewhat like having one house with many different outside doors, each with a different (unique) lock and key. Giving one key to one individual really grants access to all of the valuables in the house.
Make sure that you also have security rules that restrict specific userids and applications to specific queues (and other objects). |
Thanks for tha analogy 
Yes, I have granted specific user ID's (actually groups) permissions to specific MQ objects etc. |
|
| Back to top |
|
|
|
|
