MQ

MQ

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
Back to discussions
Expand all | Collapse all

Naming convention for SRVCONN channels

  • 1.  Naming convention for SRVCONN channels

    Posted Wed August 26, 2020 11:44 AM
    I'm creating some naming standards for our group to follow for the various MQ objects.  There is a SO post on this topic here that I've found very helpful.  For the most part this exercise has been straight forward, with one exception.  I'm struggling with how best to name the SRVCONN channels we create.

    The author suggests using something like APP.QMNAME.SVRCONN, where APP is the application name (maybe) and QMNAME is the name of the queue manager.  Our app names can be quite long, and given that channel names are limited to 20 characters I could see running over.  Also, multiple clients might use the same channel when connecting to a queue manager.  Having the application name included seems misleading in this regard.

    I'm curious to know what others are doing for these channel types.  I could drop the APP portion, but then the name wouldn't be unique if we needed another SRVCONN channel defined for the same queue manager.  Perhaps I've misread the author's intent and APP is generic, intended to imply this is the channel that all applications use to connect with the queue manager, and not unique to a specific application.

    Thanks,
    Jim

    ------------------------------
    Jim Creasman
    ------------------------------


  • 2.  RE: Naming convention for SRVCONN channels

    Posted Wed August 26, 2020 03:58 PM
    So you're limited to 20 characters/bytes some of which should be used to define the intended user of the server connection channel.

    ------------------------------
    Francois Brandelik
    ------------------------------

    Original Message


  • 3.  RE: Naming convention for SRVCONN channels

    Posted Wed August 26, 2020 04:10 PM

    We use CLIENT.<application>.SVRCONN to name our server connection channels.

    This means that the channel name is always the same across DEV, QA, PRD, just the host/serveralias and port differ.

    We use an designated MQ Gateway, so all clients/applications only ever connect to the QMGWxxx.

     

    I am not a fan of putting the QMName into the channel name unless I really have to, such as for Cluster and sender/receiver channels.

     

    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
    Hirschel Wasserman

     

    This email and any attachments are intended only for the named recipient and may contain confidential and/or privileged material. Any unauthorized copying, dissemination or other use by a person other than the named recipient of this communication is prohibited. If you received this in error or are not named as a recipient, please notify the sender and destroy all copies of this email immediately.

    Insurance Corporation of British Columbia | 151 W. Esplanade | North Vancouver | V7M 3H9
    Contact Us




    Original Message


  • 4.  RE: Naming convention for SRVCONN channels

    Posted Wed August 26, 2020 04:30 PM
    If you APPlication names are really long, then develop a (managed) list of abbreviations. For example, we use PC for PolicyCenter

    ------------------------------
    hirschel wasserman
    ------------------------------

    Original Message


  • 5.  RE: Naming convention for SRVCONN channels

    Posted Wed August 26, 2020 04:51 PM
    Hirschel,

         Thanks for the reply.  What happens if you have multiple applications using the channel?  Or, do you define a single channel for each application that connects to the QM?  For example, in our case we have a single subscriber application and multiple applications that publish to a topic.  All are viewed as different applications from our organizations point of view since each runs as a separate service.  These connect to the QM over the same channel.

    Jim

    ------------------------------
    Jim Creasman
    ------------------------------

    Original Message


  • 6.  RE: Naming convention for SRVCONN channels

    Posted Wed August 26, 2020 06:14 PM

    Hi Jim

    For security, even though its all internal network, each application has its own channel; there are CHLAUTH records in place which only allow application server (by IP address) to access their designated channel.

    Without knowledge of your specifics, and your auth requirements, the channels and the queue/topics are mostly independent from each other.

    We insert an MCAUSER into the channel definition, and this MCA has the required permission to Publish/PUT/GET etc as needed.

     

    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
    Hirschel Wasserman

     

    This email and any attachments are intended only for the named recipient and may contain confidential and/or privileged material. Any unauthorized copying, dissemination or other use by a person other than the named recipient of this communication is prohibited. If you received this in error or are not named as a recipient, please notify the sender and destroy all copies of this email immediately.

    Insurance Corporation of British Columbia | 151 W. Esplanade | North Vancouver | V7M 3H9
    Contact Us




    Original Message


  • 7.  RE: Naming convention for SRVCONN channels

    Posted Thu August 27, 2020 07:01 AM
    Hi Jim,
    in case you are working with Jira, I would use the jira project key as APP.
    I would shorten the postfix SRVCONN to my own 3 or 4 char string.
    You may also want to have a look into this document.
    https://mqgem.wordpress.com/2015/05/26/naming-mq-objects/
    If you are working in a multicloud environment I would postfix the cloud e.g. app.qmgr.srvconn.cloud

    ------------------------------
    Matthias Jungbauer
    ------------------------------

    Original Message


  • 8.  RE: Naming convention for SRVCONN channels

    Posted Fri August 28, 2020 02:57 AM
    Hi Jim,

    What we do is we have a prefix for every queuename, topic, subscription which matches also the prefix for our channelnames. This prefixes we also use for adding permissions to these MQ objects. The prefix references to the MQ client which is submitting the messages.
    For example:
    Our WCS (Websphere commerce server) is using the  WCS.SVRCONN channel and the WCS.CUSTOMER_ORDER.DAT queue.
    In this example MQ permissions are added referencing  WCS.** .
    Hope this helps
    Kind regards

    ------------------------------
    Bernard Pittens
    Integration Engeneer
    Sligro Foodgroup B.V.
    Veghel
    ------------------------------

    Original Message


  • 9.  RE: Naming convention for SRVCONN channels

    Posted Fri August 28, 2020 12:13 PM

    Hi Jim,

    I have seen quite a few naming conventions for SVRCONNs  - but as I typically only see these when things are not working well my insight might be a bit jaded. 

    1) Have a different SVRCONN per application or application group.  If one application has a code change that causes issues, it is easier to avoid impact to other applications by stopping that channel.

    2) Do not include the queue manager name, as that can get confusing if you change names or targets over the years. Or if your client application can connect to multiple cloned or very similar queue managers. 

    3) Do use some indication of the type of channel.  I have seen customers use 'SVRCONN' or 'CLIENT' in the name to make them easier to spot.  If that needs to be shortened, that's fine 'SVRC' - as long as it is consistent.  That can make is easier to spot a problem pattern.  

    4) Don't make the convention too elaborate - it will get abandoned and cause confusion a year or more from now. 
     



    ------------------------------
    Lyn Elkins
    IBM
    Eads TN
    elkinsc@us.ibm.com
    ------------------------------

    Original Message


  • 10.  RE: Naming convention for SRVCONN channels

    Posted Tue September 08, 2020 09:30 AM
    Thanks everyone for your input on this question.  It was great to get all the feedback.  I wanted to follow up with our decision regarding the client channel names to provide some closure on this thread.  We are planning to use a format of CLNT.qmgr.domain, where "CLNT" identifies the channel as a client-to-server connection, "qmgr" is the queue manager name and "domain" identifies a particular organizational area within our company that also maps to how we organize our services (i.e., the clients).  We'll see how this works and modify as needed.

    ------------------------------
    Jim Creasman
    ------------------------------

    Original Message