Set up a simple two way IBM MQ service on z/OS Connect EE

How you set up a two-way IBM MQ service in z/OS® Connect EE, against an existing pair of IBM MQ queues called MQ_REQUEST_Q and MQ_REPLY_Q.

Before you begin

Ensure that we have set up all the components correctly, as described in Enabling z/OS Connect and the MQ Service Provider and Checking that z/OS Connect is correctly set up.

About this task

This is slightly more involved than setting up a one-way service, as you require a back end application to consume the request messages sent using z/OS Connect, and generate reply messages.

This task assumes that the MQ_REQUEST_Q and MQ_REPLY_Q queues are used by an existing backend application, for example a CICS® or IMS transaction, that takes a request message from MQ_REQUEST_Q and generates a reply message which is placed on MQ_REPLY_Q.

Procedure

1. Define an IBM MQ messaging provider connection factory, and two IBM MQ messaging provider queues to the z/OS Connect EE server. The IBM MQ messaging provider queues map to the existing MQ_REQUEST_Q and MQ_REPLY_Q queues. You do this by adding the following to the bottom of server.xml, of the z/OS Connect EE server that we have created, but inside the server element.

   <jmsConnectionFactory id="cf2" jndiName="jms/cf2"   
                         connectionManagerRef="ConMgr2">       
        <properties.wmqJms
           transportType="BINDINGS"
           queueManager="MQ21"/>
   </jmsConnectionFactory>
   
   <connectionManager id="ConMgr2" maxPoolSize="5"/>
   
   <jmsQueue id="requestQueue" jndiName="jms/requestQueue">
        <properties.wmqJms baseQueueName="MQ_REQUEST_Q"/>
   </jmsQueue>
   
   <jmsQueue id="replyQueue" jndiName="jms/replyQueue">
        <properties.wmqJms baseQueueName="MQ_REPLY_Q"/>
   </jmsQueue>
   

   Notes:
   1. Change the value of the queueManager attribute to the correct target queue manager name.
   2. You might need to carry out further configuration of these elements, depending on the nature of the backend application. See Configure the MQ Service Provider for more information.
   3. The maxPoolSize attribute might need to be adjusted depending on the number of concurrent requests. For more information on this attribute see Configure connection pooling for JMS connections.
2. Define the two-way IBM MQ service by adding the following to server.xml, of the z/OS Connect EE server that we have created, but inside the server element.

   ________________________________________
   <zosconnect_zosConnectService id="zosconnMQ2"
                           invokeURI="/twoWay"
                           serviceName="twoWay"
                           serviceRef="twoWay" />
   
    <mqzosconnect_mqzOSConnectService id="twoWay"
                         connectionFactory="jms/cf2"
                         destination="jms/requestQueue"
                         replyDestination="jms/replyQueue"
                         waitInterval="10000"/>
   ________________________________________
   

   Notes:
   1. You might need to carry out further configuration of these elements, depending on the nature of the backend application. For example, you might need data transformation. See Configure the MQ Service Provider for more information.
   2. You might need to adjust the value of waitInterval, See waitInterval for further information.
   3. In this example, it is assumed that messages placed on the reply destination, by the backend application, have a correlation ID that is the same as the message ID on the request destination.

      If that is not the case then you need to add the replySelection attribute to the mqzosconnect_mqzOSConnectService element, and set the value appropriately.

      See replySelection for further information.

Results

You have set up a two-way service in z/OS Connect EE, that can be used with an existing backend application that makes use of a pair of IBM MQ queues.

What to do next

We can invoke the two-way service issuing an HTTP POST command to the URL https://host_name:port_no/twoWay.

The steps to do this are similar to those described in Testing the one-way service on z/OS Connect EE, except that only the HTTP POST verb is supported, and you should send JSON payload data that is appropriate to the existing backend application.