Support for connecting to IBM MQ in the cloud and IBM MQ on-premises (V8.0 or later) is now available with IBM App Connect. MQ is a messaging-oriented middleware product that enables you to deploy queue managers and connect your applications to them, for reliable data transfer between different parts of your enterprise application landscape.
You can connect to an MQ queue manager to achieve the following tasks:
- Get messages from a queue.
- Put messages to a queue.
- Subscribe to messages on a topic.
- Publish messages to a topic.
Requirements for connecting to MQ from App Connect
To see which events and actions are available for MQ and use them in your flows, you must connect App Connect to your MQ queue manager by setting up an account with the following connection details:
- The queue manager host and port
- The queue manager name
- Your application MQ user name and password for an MQ on-premises server, or your user name and API key for an MQ cloud deployment
- The server connection channel name
- (Optional) The cipher spec
- (Optional) The network name
- The cipher spec is applicable only for cloud connectivity, and is required if you have enabled SSL on the channel for connectivity. The default value is ECDHE_RSA_AES_128_CBC_SHA256. Currently, App Connect supports only server-side authenticated connections for the channel. Leave this field blank if you do not have SSL enabled.
- The network name is required for connecting to an MQ on-premises deployment. You can configure a private network by using the IBM Secure Gateway Client.
If using an MQ on-premises deployment, you must also add the following line to the queue manager configuration file named
This file is generally located in
var/mqm/qmgrs/QMNAME/qm.ini on UNIX and
C:\ProgramData\IBM\MQ\qmgrs\QMNAME\qm.ini on Windows, where QMNAME is the queue manager name.
You can integrate MQ with any of the applications or APIs in the App Connect catalog, as required for your use case. To illustrate how easy it can be to set up a flow, we are going to describe a simple scenario with two MQ queues: DEV.QUEUE.1 and DEV.QUEUE.2. We will listen on DEV.QUEUE.1 for messages, send the retrieved messages to an HTTP endpoint for processing, and put the response to DEV.QUEUE.2.
We start our event-driven flow by adding an IBM MQ “New message on a queue” event as the trigger for the flow. In the Queue name field, we add the name of our first queue
Then, we add an HTTP node with a POST method and add the endpoint URL to the URL (fully qualified) field. The â€śNew message on a queueâ€ť node will output MQMD headers and message data. Let’s use the Request body field of our HTTP node to map to the
Message data response, which contains the message payload.
Next, weâ€™re going to put the response received from the HTTP node to the queue named DEV.QUEUE.2. To do this, click (+) > IBM MQ > Put message to a queue. In the Queue name field, we add the name of our second queue
DEV.QUEUE.2. In the Payload type field, we select Text because we are going to input a message in text rather than in binary code. In the Message data field, map to the
Response body response from the HTTP node.
Now let’s use the MQMD header section in the IBM MQ node to add MQMD headers. We click Add property to provide the headers that we want to work with. (These header names must be valid because the flow will fail if an invalid header is provided.) In this flow, we add the following headers: “Correlation identifier” (represented by the
CorrelId property) and “Name of the ReplyToQ” (represented by the
We can then click Edit mappings to provide values for the headers that we just added, and can enter either text or mapped values. In this flow, the value for â€śCorrelIdâ€ť is mapped to
Message ID from the â€śIBM MQ / New message on a queueâ€ť response, and the value of â€śReplyToQâ€ť is provided as a text value.
We can now start the flow and test it as follows: