Overview

Skill Level: Any Skill Level

From Basic to Advanced Level Concepts

This article demonstrates some of the major features of IBM® MQ & its implementation in Enterprise Systems which includes Distributed & Cluster networks, B2B Connectivity using MQIPT, Triggering, DLQ Rules, Pub-Sub, Advanced MQ Securities & MQMFT.

Ingredients

IBM® MQ v8.0 & Above

Platform: Windows & Linux

Prerequisite: Working knowledge on IBM® MQ.

Introduction: IBM® MQ, in a Nutshell transfers business data / messages across different Applications & running on disparate Platforms. In the process of doing so, it uses multiple features to achieve its objective. In this article, I am going to showcase some of the commonly used functionalities of IBM® MQ & its messaging techniques like Point to Point Communication (Distributed) & Clusters joined together in a hybrid network of Queue Managers as shown in the below figure. Using this figure as the Reference Architecture, we are going to implement the commonly used functionalities of IBM® MQ in a Case by Case basis & finally put together all pieces of the puzzle in an Integrated Test Case, used in real world Enterprise environments.

Final

The above Reference Architecture Diagram represents two different Organizations A & B using a Cluster & Distributed MQ Infrastructure respectively. Each of these networks are secured by SSL/TLS Certs signed by Certificate Authorities CA1 & CA. The Gateway Qmgr on both organizations are connected through two different MQIPT Instances placed in the DMZ of both organization. Apart from these high level settings, we have MQ Client configurations, Channel & Application Triggering concepts, Usages of Multiple Certificates, PUB-SUB technique, Message Persistency & Recovery, MQ Security including AMS & MQMFT implementation in this Integrated Test Scenario which is basically a miniaturized version of real world Enterprise Systems.

Step-by-step

  1. Create a Distributed MQ Network

    We start our journey with the simple tasks of creation & configuration of Qmgrs in a Distributed setup for Org.B. As part of this exercise, we are going to create 3 Qmgrs (QMA, QMB & QMG) & interconnect each other with distributed SDR / RCVR Channels. As shown in the below diagram. Create the necessary MQ Objects & ensure that all the channels are Running. The below diagram represents the how IBM MQ works in a Distributed network & the associated components involved in the process.

    Distributed

    MQ Object Definitions: The below MQ object definitions create Qmgrs, Listeners, Channels & XMITQ queues & Interconnect them:

    Create Qmgrs
    #############
    crtmqm QMA | crtmqm QMB | crtmqm QMC

    Define Listener & associated Channel Configurations:

    runmqsc QMA
    #############
    DEFINE LISTENER(QMA.LSR) TRPTYPE(TCP) PORT(1414) CONTROL(QMGR)

    DEFINE CHANNEL(‘QMA.TO.QMB’) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1415)’) XMITQ(‘QMB’) DISCINT(300)
    DEFINE QLOCAL(QMB) USAGE(XMITQ) REPLACE
    DEFINE CHANNEL(‘QMB.TO.QMA’) CHLTYPE(RCVR) TRPTYPE(TCP)

    DEFINE CHANNEL(‘QMA.TO.QMG’) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1416)’) XMITQ(‘QMG’) DISCINT(300)
    DEFINE QLOCAL(QMG) USAGE(XMITQ) REPLACE
    DEFINE CHANNEL(‘QMG.TO.QMA’) CHLTYPE(RCVR) TRPTYPE(TCP)

    runmqsc QMB
    #############
    DEFINE LISTENER(QMB.LSR) TRPTYPE(TCP) PORT(1415) CONTROL(QMGR)

    DEFINE CHANNEL(‘QMB.TO.QMA’) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1414)’) XMITQ(‘QMA’) DISCINT(300)
    DEFINE QLOCAL(QMA) USAGE(XMITQ) REPLACE
    DEFINE CHANNEL(‘QMA.TO.QMB’) CHLTYPE(RCVR) TRPTYPE(TCP)

    DEFINE CHANNEL(‘QMB.TO.QMG’) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1416)’) XMITQ(‘QMG’) DISCINT(300)
    DEFINE QLOCAL(QMG) USAGE(XMITQ) REPLACE
    DEFINE CHANNEL(‘QMG.TO.QMB’) CHLTYPE(RCVR) TRPTYPE(TCP)

    runmqsc QMG
    #############
    DEFINE LISTENER(QMG.LSR) TRPTYPE(TCP) PORT(1416) CONTROL(QMGR)

    DEFINE CHANNEL(‘QMG.TO.QMA’) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1414)’) XMITQ(‘QMA’) DISCINT(300)
    DEFINE QLOCAL(QMA) USAGE(XMITQ) REPLACE
    DEFINE CHANNEL(‘QMA.TO.QMG’) CHLTYPE(RCVR) TRPTYPE(TCP)

    DEFINE CHANNEL(‘QMG.TO.QMB’) CHLTYPE(SDR) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1415)’) XMITQ(‘QMB’) DISCINT(300)
    DEFINE QLOCAL(QMB) USAGE(XMITQ) REPLACE
    DEFINE CHANNEL(‘QMB.TO.QMG’) CHLTYPE(RCVR) TRPTYPE(TCP)

    Thus we have setup a Distribueted MQ network for Organization B as shown in the below figure.

    ORGB

  2. Enable Channel Triggering

    The logic behind using Channel Triggering is to keep the Channel Up & Running only when it is requird i.e. on demand basis to save unnecessary usage of system resouces. When not in use, the Channel will automatically move into Inactive State. There are basically 2 ways by which we can enable Channel Triggering i.e. either using USERDATA or TRIGDATA. The below figure shows the Steps involved in Channel Triggering activity.

    ChlTrigger

    1. Using USERDATA Paramater in Process Definition.

    runmqsc QMA
    #############
    DEFINE PROCESS(QMB) USERDATA(‘QMA.TO.QMB’)
    ALTER QLOCAL(QMB) PROCESS(‘QMA’) INITQ(‘SYSTEM.CHANNEL.INITQ’) TRIGTYPE(FIRST)

    DEFINE PROCESS(QMG) USERDATA(‘QMA.TO.QMG’)
    ALTER QLOCAL(QMG) PROCESS(‘QMG’) INITQ(‘SYSTEM.CHANNEL.INITQ’) TRIGTYPE(FIRST)

    Similarly, repeat the same Steps for the other two Qmgrs QMB & QMG.

    2. Using TRIGDATA Parameter in XMITQ.

    runmqsc QMA
    #############
    ALTER QLOCAL(QMB) USAGE(XMITQ) TRIGGER TRIGDATA(‘QMA.TO.QMB’) INITQ(SYSTEM.CHANNEL.INITQ)
    ALTER QLOCAL(QMG) USAGE(XMITQ) TRIGGER TRIGDATA(‘QMA.TO.QMG’) INITQ(SYSTEM.CHANNEL.INITQ)

    Similarly, repeat the same Steps for the other two Qmgrs QMB & QMG.

    Which option to be used is a matter of Individual choice. However, using TRIGDATA parameter reduces additonal Process Definitions.

    Note: Set the DISCINT parameter at the Sender Channel to lower value based on your requirement. In this case, I have taken 15 seconds. If the Channel is not in use for the mentioned time specified in the DISCINT interval, the Channel will automatically go into Inactive State. However, it will start running automatically as & when any message comes into the Trigerred XMITQ.

  3. Enable Application Triggering

    Like Channel Triggering, the idea behind Application Triggering is to dynamically invoke any Application Program(s) when certain conditions are met at the queue level. The following diagram represents the various steps involved in Application Triggering process:

    AppTrigger

    MQ Object Definitions: The following objects needs to be created for Application Triggering to be enabled. 

    runmqsc QMA
    #############
    DEFINE QR(TO.QMB) RNAME(QMB.LQ) RQMNAME(QMB) XMITQ(QMB)

    runmqsc QMB
    #############
    DEFINE PROCESS(APP) APPLICID(C:POC.bat)
    DEFINE QL(QMB.LQ) TRIGGER PROCESS(APP) INITQ(SYSTEM.DEFAULT.INITIATION.QUEUE) TRIGDPTH(1) TRIGTYPE(EVERY)

    Now, we need to run the Trigger Monitor Program which polls the given Application Queue for any incoming messages. Based on the Triggering criteria set, Application program(s) will be invoked. You can either run this runmqtrm as background process in UNIX or can set it as a Service on Windows platform.

    runmqtrm -m QMB -q SYSTEM.DEFAULT.INITIATION.QUEUE

    In our example, we are putting messages from a Remote Queue (TO.QMB) defined under QMA which points to the target Local Queue (QMB.LQ) defined under QMB. Trigger is enabled & set to EVERY (QMB.LQ). When triggering condition fulfilled, it will invoke the batch file POC.bat which basically contain the command dspmqist. Hence, as soon as message arrives in the Trigger enabled Application Queue QMB.LQ, it invokes the program file POC.bat & displays the output of dspmqinst command as shown in the below screenshot.

    AppTrigger1

  4. Setup MQ Client (MQSERVER)

    In this section, we are going to setup the MQSERVER environment variable to be able to read messages as a MQ Client (using sample program amqsputc)  from a Triggered Local Queue defined under Qmgr QMB.

    Create a SVRCONN Channel under QMB & set values for the MQSERVER environment:

    Windows: set MQSERVER=QMB/TCP/127.0.0.1(1500)

    UNIX: export MQSERVER=QMB/TCP/’127.0.0.1(1500)’)

    runmqsc QMB
    #############
    DEFINE CHANNEL(QMB) CHLTYPE(SVRCONN)

    ALTER QMGR CHLAUTH(DISABLED) ===> Disable MQ Channel Security (MQ v7.5 & above)

    ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL) 
    REFRESH SECURITY TYPE(CONNAUTH) ===> Disable ID/Password Security (MQ v8.0 & above)

    Note: Please note that we have disabled MQ Security for the time being in-order to ensure MQ Client program is getting invoked through Application Triggering & read the message from the Triggered Local Queue as shown below. We will activate MQ Security in the coming Sections.

    In our example, we are putting messages from a Remote Queue (TO.QMB) defined under QMA which points to the target Local Queue (QMB.LQ) defined under QMB. This QMB.LQ is already a Triggered Queue as configured in the previous Section 3. As soon as any Message comes into this local queue, it will invoke the program POC.bat & read the message from the Queue using MQ Client program amqsgetc as shown in the below screenshot.

    MQSERVER

  5. Configure DLQ & Handler Rules

    In this section, we will discuss about Dead Letter Queue or DLQ & it’s usage. Imagine a situation where the sending Application is unable to put messages into destination queue for reasons unknown. Where will those messages go or how can we handle those scenarios ? Here comes the role of DLQ which is basically a type of Local Queue with special purpose. The undelivered messages will be automatically moved by the Qmgr into the DLQ from where MQ Administrators have to take further actions. From MQ Best Practice perspective, it is always recommended to have a DLQ defined for each Qmgr in your network. However, there are scenarios where DLQ is not used for a practical purpose. A classic example would be an Application having dependency in Message Sequencing!

    After defining a Local Queue as DLQ, we need to associate the same with its Qmgr using the below command:

    runmqsc QMA
    #############

    DEFINE QL(QMA.DQ)

    ALTER QMGR DEADQ(‘QMA.DQ’) ==> Associating DLQ with the Qmgr

    ##############################################################

    There is a Program called DLQ Handler (runmqdlq) which can be involved with certain parameters (DLQ Rules Table) to be able to recover the messages from the DLQ. In our example, we are going to create 3 distinct scenarios where-in the sending Application is unable to put the message into the respective Application Queues due to following three reasons:

    1. Queue FULL Condition  2. Unknown Queue Object Name &  3. Queue set to Put Inhibited Condition

    For the sake of demonstration, we have created 3 different Local Queues under Qmgr QMA by the name QFULL, PUTD & POC. Each of these Queues are representing the 3 conditions mentioned above. From the remote Qmgr(QMB), I have put 3 different messages into respective Remote Queues which will first reach the respective destination Qmgr. However, since I have deliberately altered the Queue parameters (MAXDepth set to 0 for QFULL, Put Inhibited for PUTD & wrong Destination Queue name specified in the Remote Queue definitions POC) for demostrating the usage of DLQ…these Messages won’t reach the destination queue but will be moved to the Qmgr’s DLQ i.e. QMA.DQ as shown below in the screenshot.

    DLQ1

    I have already created a Rules table where I mentioned what action needs to be taken for the messages sitting in the DLQ. Before I run the DLQ handler program, I have to alter the Queue Parameters so that Messges from DLQ will now move into respective Application Queues i.e. changed the PUT Inhibited to Allowed, MAX Depth to 100 etc. After this, I have run the dlq.bat file which basically contains the runmqdlq commands. It takes input from the Rules table as shown in the below screenshot & move the messages back to its original Application Queues by removing the DLH header.

    Note 1: One can automate this tasks of recovering the Messages from DLQ by keep running the DLQ handler program as backgroud process or as MQ Service. However, it is not recommended to do that because if we don’t rectify the original issues (could be QFULL, MAX Depth, etc.), the DLQ handler program will fail anyway!

    Note 2: The question on how to identify the reason why a message went to DLQ is not covered in this article. However, you can learn those techniques from another article on DLQ Administration here => Learn about DLQ Administration Techniques

    DLQ2

  6. Message Duplication using Pub-Sub

    Imagine a situation where an External Organization is sending messages to Organization B. As per the requirement, this messages needs to be consumed by two different Applications. However, the external Org. can send message to one Destination only & can NOT send to both. In this scenario, we can use a combination of multiple techniques to duplicate the incoming messages and send the same to 2 or more destinations. In our Scenario, we are going to use MQ Pub-Sub technique at the gateway Qmgr QMG to duplicate incoming messages into 2 different subscriptions (SUB1 & SUB2) on the gateway qmgr whose destination queues are SUB1 & SUB2 defined under QMA & QMB respectively. Alternatively, we can use the QLoad utility (integrated & renamed as dmpmqmsg in MQ v8.0 onwards) as the Triggered Program which will duplicate & move the same messages into two different Remote Queues which points to Local Queues on QMA & QMB.

     PUB-1

    MQ Object Definitions: The below Object definitions demonstrates MQ Pub-Sub techniques of duplicating incoming messages & sending it across to multiple destinations within an Organization.

    runmqsc QMG
    #############
    DEFINE QALIAS(DESTINATION) TARGET(T1) TARGTYPE(topic)
    DEFINE TOPIC(T1) TOPICSTR(‘TOPIC1’)

    DEFINE SUB(SUB1) TOPICSTR(‘TOPIC1’) DEST(SUB1) DESTQMGR(QMA)
    DEFINE SUB(SUB2) TOPICSTR(‘TOPIC1’) DEST(SUB2) DESTQMGR(QMB)

    runmqsc QMA
    #############
    DEFINE QL(SUB1)

    runmqsc QMB
    ###############
    DEFINE QL(SUB2)

    PUB-SUB

    Note: Strictly speaking, even though the message payload or actual data has been duplicated…however, these messages will have a different MsgId & CorrelId. Hence, this solution is not recommended for Request / Reply scenario.

  7. Setup SSL Connectivity for Org. B

    In this section, we are going to secure the Distributed MQ network of Organization B using SSL/TLS Certificates used in MQ channels signed by Certificate Authority 1 (CA1). To do this activity, first we have to create the Certificate Authority 1 (CA1) & generate its public certificate to be used for distribution. I have already mentioned the Internal CA creation steps in another article End to End MQ Security (Section 4). We have to repeat similar Steps in this Section as well.

    SSL-ORGB1

    Create Certificate Authority 1 (CA1) & Extract the Public Certificate file.

    Steps:

    1. Create the keystore for CA1
    #############################
    runmqckm -keydb -create -db CA1 -pw Passw0rd -type cms -expire 365 -stash

    2. Create Self Signed CA Certificate
    ##################################
    runmqckm -cert -create -db CA1.kdb -pw Passw0rd -label ssl_ca1 -dn “CN=Certificate Authority 1,O=IBM,C=India” -expire 365

    3. Extract Public (Self Signed) CA Certificate
    ##########################################
    runmqckm -cert -extract -db CA1.kdb -pw Passw0rd -label ssl_ca1 -target ssl_ca1.arm -format ascii

    Now, we have to create the keystores for QMA, QMB & QMC. Generate CSR files, Extract & get it Signed by the CA1. Once these 3 steps are completed, we will Add the Root CA Certificate (ssl_ca1.cer) into the Queue Manager’s keystores along with Receiving the CA Signed certificates (e.g: qma.cer) into respective Qmgr’s key-repositories. After that, we have to alter the SSLKEYR parameter of the QMGRs to point to correct keystores without the .kdb extension & set the CERTLABL parameter at the Qmgr level. Then, select the Same TLS Cipher Spec algorithm between SDR / RCVR channel pairs. Lastly, Refresh the Security Cache before starting the Channels.

    Similar steps related to Certficate generation of Qmgrs & get it signed by Internal CA has been mentioned in another article Multiple Certificates in IBM MQ v8.0 (Section 3). There are two major changes from MQ v8.0 onwards viz. the Cert Lable Name does not need to follow the strict naming convention of ibmwebsphere<Qmgr Name in Lower Case> & the introduction of the new parameter called CERTLABL at both Qmgr & Channel level.

    Steps for Qmgr QMA:

    1. Create the keystore QMA
    ########################
    runmqckm -keydb -create -db QMA -pw Passw0rd -type cms -expire 365 -stash

    2. Create the CSR for QMA
    ##########################
    runmqckm -certreq -create -db QMA.kdb -pw Passw0rd -label QMA Cert -dn “CN=QMA Qmgr,O=IBM,C=India” -file qma.arm

    3. Sign QMA’s CSR using CA1
    ###########################
    runmqckm -cert -sign -file qma.arm -db CA1.kdb -pw Passw0rd -label ssl_ca1 -target qma.cer -format ascii -expire 364

    4. ADD CA1’s Public Cert into QMA’s Keystore
    #########################################
    runmqckm -cert -add -db QMA.kdb -pw Passw0rd -label ssl_ca1 -file ssl_ca1.cer -format ascii -trust enable

    5. RECEIVE the CA Signed Certificate into QMA’s Keystore
    ###################################################
    runmqckm -cert -receive -db QMA.kdb -pw Passw0rd -file qma.cer -format ascii

    6. Set the Certificate Label parameter at Qmgr Level
    ###########################################
    ALTER QMGR CERTLABL(‘QMA Cert’)

    7. Select the TLS Cipher Spec Algorithm
    ######################################
    ALTER CHANNEL(QMA.QMB) CHLTYPE(SDR) SSLCIPH(TLS_RSA_WITH_3DES_EDE_CBC_SHA)
    ALTER CHANNEL(QMB.QMA) CHLTYPE(RCVR) SSLCIPH(TLS_RSA_WITH_3DES_EDE_CBC_SHA)

    ALTER CHANNEL(QMA.QMG) CHLTYPE(SDR) SSLCIPH(TLS_RSA_WITH_3DES_EDE_CBC_SHA)
    ALTER CHANNEL(QMG.QMA) CHLTYPE(RCVR) SSLCIPH(TLS_RSA_WITH_3DES_EDE_CBC_SHA)

    8. Refresh Security Cache
    #######################
    REFRESH SECURITY TYPE(SSL)

    Similarly, repeat Step 1-8 for the other Qmgrs QMB & QMG. If all goes fine, you will see the below channels running as per the below screenshot. Thus, we have secured the distributed MQ network of Organization B using SSL/TLS.

    SSL-ORGB

  8. Create MQ Cluster

    In this section, we are going to create a MQ Cluster for Organization A called CLUS. Designate QM1 & QM2 as the FULL Repository Qmgr and Q3 as the Partial Repository as shown in the below figure. I am not going to elaborate on the theoritical aspects of Clusters since detailed instruction on how to create Cluster on Windows platform is already mentioned in another article Advanced MQ Clustering.

    ORGA

    MQ Object Definitions: The below MQ object definitions create Qmgrs, Listeners, MQ Cluster & Channels.

    Steps:

    Create Qmgrs
    #############
    crtmqm QM1 | crtmqm QM2 | crtmqm QM3

    runmqsc QM1
    #############
    DEFINE LISTENER(QM1.LSR) TRPTYPE(TCP) PORT(1414) CONTROL(QMGR)
    ALTER QMGR REPOS(‘CLUS’)
    DEFINE CHANNEL(TO.QM1) CHLTYPE(CLUSRCVR) CONNAME(127.0.0.1(1414)) CLUSTER(‘CLUS’)
    DEFINE CHANNEL(TO.QM2) CHLTYPE(CLUSSDR)   CONNAME(127.0.0.1(1415)) CLUSTER(‘CLUS’)

    runmqsc QM2
    #############
    DEFINE LISTENER(QM2.LSR) TRPTYPE(TCP) PORT(1415) CONTROL(QMGR)
    ALTER QMGR REPOS(‘CLUS’)
    DEFINE CHANNEL(TO.QM1) CHLTYPE(CLUSSDR)    CONNAME(127.0.0.1(1414)) CLUSTER(‘CLUS’)
    DEFINE CHANNEL(TO.QM2) CHLTYPE(CLUSRCVR) CONNAME(127.0.0.1(1415)) CLUSTER(‘CLUS’)

    runmqsc QM3
    #############
    DEFINE LISTENER(QM3.LSR) TRPTYPE(TCP) PORT(1416) CONTROL(QMGR)
    DEFINE CHANNEL(TO.QM1) CHLTYPE(CLUSSDR)    CONNAME(127.0.0.1(1414)) CLUSTER(‘CLUS’)
    DEFINE CHANNEL(TO.QM3) CHLTYPE(CLUSRCVR) CONNAME(127.0.0.1(1416)) CLUSTER(‘CLUS’)

  9. Secure Organization A Cluster

    In this section, we are going to secure the existing Cluster for Organization A using SSL/TLS Certs signed by Certificate Authority 2. To complete this activity, first we have to create the Certificate Authority 2 (CA2) & generate its Public Certificate to be used for distribution. I have already mentioned the Internal CA creation steps along with securing an existing MQ Cluster in another article End to End MQ Security(Section 5). We have to repeat similar Steps in this Section as well.

    ORGA-SSL

    Create Certificate Authority 2 (CA2) & Extract the Public Certificate file.

    Steps:

    1. Create the keystore for CA2
    #############################
    runmqckm -keydb -create -db CA2 -pw Passw0rd -type cms -expire 365 -stash

    2. Create Self Signed CA2 Certificate
    ###################################
    runmqckm -cert -create -db CA2.kdb -pw Passw0rd -label ssl_ca2 -dn “CN=Certificate Authority 2,O=IBM,C=India” -expire 365

    3. Extract Public (Self Signed) CA2 Certificate
    ###########################################
    runmqckm -cert -extract -db CA2.kdb -pw Passw0rd -label ssl_ca2 -target ssl_ca2.arm -format ascii

    Now, we have to create the keystores for QM1, QM2 & QM3. Generate CSR files, Extract & get it Signed by the CA2. Once these 3 steps are completed, we will Add the Root CA Certificate (ssl_ca2.cer) into the Queue Manager’s keystores along with Receiving the CA Signed certificates (e.g: qm1.cer) into respective Qmgr’s key-repositories. After that, we have to alter the SSLKEYR parameter of the QMGRs to point to correct keystores without the .kdb extension & set the CERTLABL parameter (introduced in MQ v.8.0).

    There are two major changes from MQ v8.0 onwards viz. the Cert Lable Name does not need to follow the strict naming convention of ibmwebsphere<Qmgr Name in Lower Case> & the introduction of the new parameter called CERTLABL at both Qmgr & Channel level.

    Steps:

    1. Create the keystore for QM1 Qmgr
    ################################
    runmqckm -keydb -create -db key -pw Passw0rd -type cms -expire 365 -stash

    2. Create the CSR for QM1
    #########################
    runmqckm -certreq -create -db key.kdb -pw Passw0rd -label QM1 Cert -dn “CN=QM1 Queue Manager,O=IBM,C=India” -file qm1.arm

    3. Sign QM1’s Certificate using CA2
    #####################################
    runmqckm -cert -sign -file qm1.arm -db CA2.kdb -pw Passw0rd -label ssl_ca2 -target qm1.cer -format ascii -expire 364

    4. ADD CA2’s Public Certificate into QM1’s Keystore
    ####################################################
    runmqckm -cert -add -db QM1.kdb -pw Passw0rd -label ssl_ca2 -file ssl_ca2.cer -format ascii -trust enable

    5. RECEIVE the CA2 Signed Certificate into QM1’s Keystore
    #########################################################
    runmqckm -cert -receive -db QM1.kdb -pw Passw0rd -file qm1.cer -format ascii

    6. Alter SSLKEYR parameter in TEST1 Qmgr
    #########################################
    ALTER QMGR SSLKEYR(‘/var/mqm/qmgrs/QM1/ssl/key’)

    7. Set the Certificate Label Parameter
    #####################################
    ALTER QMGR CERTLABL(‘QM1 Cert’)

    8. Only Define a SSL Enabled Cluster Receiver Channel **
    #####################################################
    DEFINE CHANNEL(TO.QM1.S) CHLTYPE(CLUSRCVR) CLUSTER(CLUS) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1414)’) SSLCIPH(TLS_RSA_WITH_3DES_EDE_CBC_SHA)

    9. Refresh SSL Security
    #######################
    REFRESH SECURITY TYPE(SSL)

    Repeat Steps 1-9 for the other two Qmgr QM2 & QM3. Once Completed, then define the SSL/TLS enabled Cluster Sender Channels for QM1, QM2 & QM3. This Sequence of Cluster Channel creation is actually Critical for its proper functioning. Otherwise, the Channels may fail to Start (Retrying). Once the Cluster Channels started Running, Stop the non-SSL Cluster channels, take them out of the Cluster & delete them.

    You can refer another tech. article on End to End Message Security (Section 5) where I have mentioned similar steps related to enabling Security in an existing MQ Cluster.

    ORGA-SSL-Output

  10. Setup MQ Client (CCDT)

    We have already established MQ Client connectivity (Organization B) using MQSERVER Environment variable in Section 4 of this article. In this Scenario, we are going to configure another MQ Client connectivity using a slightly different technique (CCDT) for Organization A’s cluster network. For this purpose, we have dedicated Qmgr QM1 for the administration of AMQCLCHL.TAB file. Client connection channel works in pair with its corresponding SVRCONN channel similar to SDR / RCVR channels. Since, QM1 is the single point administration for CCDT file, we are going to define the Client Channel definitions for QM1, QM2 & QM3 under Qmgr QM1 as shown below.

    CCDT

    Steps:

    runmqsc QM1
    #############
    DEFINE CHANNEL(QM1) CHLTYPE(SVRCONN)

    DEFINE CHANNEL(QM1) CHLTYPE(CLNTCONN) CONNAME(‘127.0.0.1(1598)’) QMNAME(QM1)

    DEFINE CHANNEL(QM2) CHLTYPE(CLNTCONN) CONNAME(‘127.0.0.1(1599)’) QMNAME(QM2)

    DEFINE CHANNEL(QM3) CHLTYPE(CLNTCONN) CONNAME(‘127.0.0.1(1600)’) QMNAME(QM3)

    #################################################################################

    runmqsc QM2
    #############
    DEFINE CHANNEL(QM2) CHLTYPE(SVRCONN)

    runmqsc QM3
    #############
    DEFINE CHANNEL(QM3) CHLTYPE(SVRCONN)

    Set the Environment Variables for CCDT:

    Windows:
    set MQCHLTAB=AMQCLCHL.TAB
    set MQCHLLIB=C:CCDT

    UNIX:
    export MQCHLTAB=AMQCLCHL.TAB
    export MQCHLLIB=/home/mqm/CCDT

    Note: We have disabled the default MQ Securities in order to test the Client connectivity testing as shown below.

    ALTER QMGR CHLAUTH(DISABLED) ===> Disable MQ Channel Security (MQ v7.5 & above)

    ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL) 
    REFRESH SECURITY TYPE(CONNAUTH) ===> Disable ID/Password Security (MQ v8.0 & above)

    Test Result: The below screenshot shows the MQ Client Environment variables setting along with MQ Client (amqsputc program) connectivity with  QM1 & QM2 qmgrs.

    CCDT1

  11. Advanced Clustering Techniques

    In this section, I am not going to duplicate my work on advanced Clustering tasks for Organization A since I have already covered some of the most frequently used concepts of Clusters in another tech. article on Advanced Clustering using IBM MQ. Please consider this article on Advanced Clustering to be same as Organization A (in this Test Case Scenario) wherein I have demonstrated the usage of Gateway Qmgrs, Workload balacing, Qmgr Aliasing, Sending Messages In & Out of Clusters & multi-hopping techniques between Distributed & Clustered networks!

  12. Usage of Multiple Certificates

    Think about our Test Case Scenario where Orignization (A) needs to communicate securely with another Business Partner Orginzation B as mentioned in the below diagram. Now, Organization A ‘s Cluster network is secured by SSL/TLS Certificates signed by CA2 where Orginazation B’s distributed network is secured using Certificates signed by CA1 as shown in the below diagram. QM3 & QMG represents the Gateway Qmgrs of the respective organizations.

    As per the requirement, both these Organizations (A & B) do not want to use Certificates signed by either CA1 or CA2 but want to communictae with each other through SSL/TLS enabled channels. In this scenario, we have go for third party Certificate Authority i.e. CA3 (as agreed by both organizations). Hence, the Gateway Qmgrs needs to update their keystores with additional Certs signed by CA3 along with changes in other associated configurations. This newly introduced feature (CERTLABL) of IBM MQ v8.0 supports usage of multiple certificates by a single Qmgr signed by different Certificate Authorities.

    I have already demonstrated the same scenarios in another tech. article Multiple usage of Certificate hence, won’t repeat the configuration steps here. One important point to be noted in this case is that the issue of using multiple certificates per Qmgr can be solved in lower versions of MQ (6.x & 7.x) as well by placing MQIPT in the DMZ area of each organizational network which we will be discussioing briefly in the next section.

    Multi-Certs-1

     

  13. Configuring MQIPT at DMZ

    IBM® MQ Internet Pass-Thru (MQIPT)  is a MQ base product extension that can be used to implement messaging solutions between remote sites across the internet. It makes the passage of IBM® MQ channel protocols in to and out of a firewall simpler and more manageable, by tunnelling the protocols inside HTTP or by acting as a proxy. There are multiple usages of MQIPT. One of them is using as a proxy, MQIPT is placed in the De-Militarized Zone (DMZ) on an Internet firewall and relays MQ protocol flows from a WebSphere MQ client or queue manager on the external Internet, to a destination queue manager inside the firewall. This enables inbound IBM® MQ communication through the firewall from an address that is in the secure DMZ.

    In this article, we are going to use MQIPT as proxy in the DMZ area of both organizations A & B as shown in the below diagram. MQIPT1 Instance is configured to run on port 1500 and MQIPT2 on port 1501. The gateway Qmgrs of both organizations i.e QM3 & QMG are going to Interconnect with each other through two different instances of MQIPT placed in the respective DMZ area of both Organizations. One important aspect of this connectivity is that both Gateway Qmgrs will never know about their Actual Machine IP Address or Port Number. MQIPT is used here as a Proxy between actual machines.

    There are multiple Scenarios in which MQIPT can be configured. In this section, we are going to use one simple Case as described below.

    MQ1

    The Installation process of MQIPT package is very simple. Just Download the MQIPT from here. It is a Category 3 Support pack (Product Extensio – freely available for download) & place the same in /opt/mqipt folder in Linux machine. You can have multiple instances of MQIPT in the same machine as well. In my Test Case, I have kept two instances of MQIPT i.e. MQIPT1 & MQIPT2 in two different directories as shown below.

    -bash-4.1$ ls -ld /opt/mqipt*
    drwxr-xr-x. 3 root root 4096 May 16 12:05 /opt/mqipt1
    drwxr-xr-x. 3 root root 4096 May 16 12:15 /opt/mqipt2
    -bash-4.1$

    There is a master Configuration file mqipt.conf under each MQIPT instance (/opt/mqipt1/mqipt) which is the essential to start the MQIPT product. We have change / alter the parameter values to suite our config. requirements. Here are the Sample mqint.conf files for MQIPT1 & MQIPT2 instances:

    MQIPT1
    ########
    [route]Name=MQIPT1
    Active=true
    ListenerPort=1500
    Trace=0
    Destination=oc2841280285.ibm.com
    DestinationPort=1501 ==> Listener Port of MQIPT2 Instance

    ####################################################################

    MQIPT2
    ########
    [route]Name=MQIPT2
    Active=true
    ListenerPort=1501
    Trace=0
    Destination=oc2841280285.ibm.com
    DestinationPort=1430 => Qmgr QMG’s Listener Port

    ####################################################################

    As per the below screenshot, I have started both instances of MQIPT, placed in the DMZ of Organization A & B. MQIPT1 accepts the MQ Connection at Port 1500 & transfer the data to MQIPT2 (placed in the DMZ of Organization B) on Port 1501. Using the Configuration file mqipt.conf, the incoming request is then forwarded to the Qmgr QMG running on port 1430. Hence, the Sender / Receiver Qmgrs does not need to know about each other IP Address or Port number as MQIPT is acting as the Proxy in between them. Similarly, mutiple other configurations like Channel Concentrator or handling HTTP request is possible using MQIPT.

    MQIPT1

  14. End to End Message Security (AMS)

    IBM® MQ Security is vast topic consisting of multiple layers covering all the aspects of modern day Application Security i.e. Authentication, Authorization, Encryption & Digital Signature. Object Authority Manager (OAM) is used for user level Authorizations, SSL/TLS enabled Channels are used for user Authentication & Message Encryption in transit, Channel Authentication Rules (CHLAUTH) is used for multiple purposes like Authentication & Authorizations and lastly the most advanced MQ Security aspect is the introduction of AMS which support Message Level Encrpytion & Digital Signature, while the messages are seating idle in the AMS enabled Local Queue before being consumed by Authorized Applications. Apart from these, we can also use custom Channel Exit Programs instead of SSL/TLS which depends on individual Organizational requirements.

    Let us consider the below diagram which basically represents our Organization A in details from MQ Security perspective. There are two Application users Alice & Bob who connects to Organization A’s Cluster network Qmgrs using SSL/TLS enable Client Connection Channels & authorized by OAM. This Cluster network is again Secured using TLS Certificates used at MQ Channel level & Signed by the Certificate Authority. There are CHLAUTH Rules set to authenticate/authorize valid users/IP address to connect to respective Qmgrs. Lastly, the most Advanced Security feature of IBM MQ is to encrypt the Application messages while seating in the AMS enabled Queues. Thus, End to End Message Security has been implemented in this Test Case starting with Alice putting the messages through SSL/TLS enable Client Channel, authenticated & authorized by OAM & CHLAUTH Rules at the Qmgr level. The messages are then put into AMS enabled Cluster Alias Queue (AMS_A) which travels through Secure Cluster Channels & reaches AMS enabled Cluster Local Queue (AMS_E). Only Authorized user Bob is able to the Decrypt the Encrypted messages from AMS_E Local Queue through SSL enabled Client connect Channel Authenticated & Authorized by OAM & CHLAUTH Rules set at the Qmgr QM3 level.

    The detailed technical Implementation of this scenarios has been mentioned in another tech. article End to End Message Security.

    Security-1

  15. Message Persistency & NPMCLASS

    The reason why IBM® MQ is still the most preferred choice for Enterprise Messaging even after 25+ years since its inception is because of its Reliability apart from its other notable characteristics. As they say, MQ never loose message…if designed properly. There are instances where we can still loose messages in case of wrong configurations. A prime example would be undelivered non-persistent messages will get Lost over a FAST Channel (NPNSPEED) with NO DLQ defined on the Remote Qmgr. The best possible combination that guarantees Message survial even in case of Catastrophic failure is Linear Logging along with Persistent Messaging. We are going to explore these theoretical aspects through couple of Test Cases as mentioned below.

    At the Queue Level, we have a parameter called NPMCLASS which can take either of the two valuse (HIGH/NORMAL). NORMAL is the default value and indicates that nonpersistent messages on this  queue are only lost following a failure, or a queue manager shutdown. These messages will be discarded in the event of a Qmgr restart. Whereas HIGH setting enables nonpersistent messages on this queue to be retained across a Qmgr restart. Nonpersistent messages may still be lost in the event of a failure.

    Case 1: Put a non-persistent Message in a Local Queue POC with NPMCLASS set to NORMAL. Message will get lost in case of Qmgr restart or failure. The below screenshot demonstrates the same.

    NORMAL

    Case 2: Put a non-persistent Message in a Local Queue with NPMCLASS set to HIGH. Message will survive a Qmgr restart. However, it may still get lost in case of other failures. NPNCLASS(HIGH) tries for its Best Effort Service for survival of messages but does not guarantee it. The below screenshot demonstrates the same.

    HIGH

    Case 3: This is the most Important of all the 3 Test Cases wherein we are going to validate Linear Logging with Persistent Messaging & NPMCLASS(HIGH) put together in a single Test case as shown below. In this scenario, I am going to put exactly two messages into the POC queue defined under Qmgr POC using Liner Logs. Under normal circumstance, both messages will survive Qmgr restart.

    PERSISTENCY

    Now, somehow the POC queue got damaged & I am unable to access the Queue using sample programs as shown in the below screenshot.

    DAMAGED

    Since, we are using Linear Logs, it is technically possible to recover the damages objects. However, only Persistent message will survive Qmgr restart & Non-Persistent message will be discarded as shown below. So, nonpersistent message with NPMCLASS(HIGH) could not survive damaged Queue object / media failure. Thus, only Linear Logs with Persistent Message will gaurantee message survial in ALL kinds of failure.

    PERSISTENCY-1

  16. MQMFT in a Cluster

    The details of the MQMFT implementation over an existing MQ Cluster has been discussed in details in a separate article Click here. The below diagram has been used as the Reference Architecture for our implementation.

    Configuration Details
    ###################
    COLO – Coordination + Logger Qmgr
    QM1 – Agent + Command Qmgr
    QM2 – Agent + Command Qmgr
    QM3 – Agent + Command Qmgr
    QM4 – Agent + Command Qmgr

    MQMFT-Clus-1

  17. MQMFT in a Distributed Network

    Details of the technical implementation of MQMFT over a distributed MQ network has been discussed in a separate article Click here. The below diagram has been used as the Reference Architecture for our implementation.

    Configuration Details
    ####################
    COLO – Coordination + Logger Qmgr
    QMA – Agent + Command Qmgr
    QMB – Agent + Command Qmgr
    QMG – Agent + Command Qmgr

    QMA14-1

  18. Conclusion

    IBM® MQ is an unparallel product in the history of Enterprise Messaging. Through this article, I humbly presents some of the frequently used features of MQ in Enterprise environments. Having said that, I must mention that there are much more functionalities available in MQ (which can be used in multiple combinations across various platforms) than what is being demonstrated here. Some of the notable features which I could not cover in this article like HA Configurations (Mult-Instance) Qmgrs, QSG on z/OS platforms, detailed Implementation of Pub-Sub techniques, Integration of MQ with other IBM Products like IIB, WAS, DataStage & much more. I am sure, there are enough resouces available in public platforms to cover those missing topics.

    I sincerly hope that readers of this article will benefit in someway through some the important concepts discussed here! Additionally, you can refer my other tech articles on IBM® MQ:

    1. Working with IBM® MQ Managed File Transfer (MQMFT)…

    2. Configuration of Multiple Certificates per Qmgr using IBM® MQ v8.0

    3. End to End Message Security using IBM® MQ

    4. Advanced Clustering Techniques using IBM® MQ

  19. Related Topcis & References

    1. End to End Message Security using IBM MQ

    2. Advanced Clustering Techniques using IBM MQ

    3. Configuration of Multiple Certificates using IBM MQ v8.0

    4. IBM MQ Primer

    5. AMS Installation & Configuration

    6. MQ-IPT

    7. IBM MQ Managed File Transfer (MQ-MFT)

    8. Download IBM MQ Trial Version

Join The Discussion