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
    Note:

    • 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 qm.ini:

Channels: PasswordProtection=optional

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.

Scenario

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 DEV.QUEUE.1.

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 ReplyToQ property).

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:

  1. Put a message to “DEV.QUEUE.1” on our queue manager.
  2. Check if the response message is available in “DEV.QUEUE.2”.

  3. Finally, return to the App Connect dashboard and locate the tile for the flow. Notice that the flow tile shows a green tick to indicate that the flow ran successfully.

5 comments on"Support for IBM MQ in IBM App Connect"

  1. The issue persists.
    Now i have another issue but this is while writing to queue: “The IBM MQ Put message to a queue action failed to execute the custom action.”
    I opened i case but the support told me is an on prem MQ issue…

    • Mohammed Asif Kundgol January 11, 2019

      Hello Paolo, Apologies for the delay in response.
      Just want to know, where have you installed the secure gateway agent? I hope it is not on your workstation. Recently we came across a similar case where it turned out that the user had installed the agent on his Mac and everytime the Mac was offline, the flows used to fail with “MQRC_CONNECTION_BROKEN [2009]”. You will have to make sure the agent is running all the time.

      Regarding the second issue, we had made some changes to address the problem. What we had found is that despite the error, the message was actually successfully put into the destination queue. So I suggest for a retry.

  2. why im getting a “MQRC_CONNECTION_BROKEN [2009]” error while reading from a queue on my on premise queue manager?
    when a flow writes on the same queue it works.

    • “MQRC_CONNECTION_BROKEN[2009]” is seen when either the Q manager is restarted or the secure gateway client is restarted and the service internally tries re-establish connection. If it can’t connect within a certain time, this error is thrown. Can you restart your secure gateway agent once and then restart the flow?

  3. Aris van Ommeren November 07, 2018

    What happens in case of errors? Can we define a DLQ?

Join The Discussion

Your email address will not be published. Required fields are marked *