Using WebSphere MQ transports on distributed platforms to test traffic to and from WebSphere MQ on z/OS

You can record requests from a non-z/OS queue manager to a queue on a z/OS queue manager and virtualize replies from z/OS to a queue on a non-z/OS queue manager without installing the HRVMMQF exit.

Since the IBM® WebSphere® MQ Series is used to exchange messages between diverse platforms, you can use the HCL OneTest™ API WebSphere MQ exit on Windows, Linux, or other platforms to record and stub messages before they get to WebSphere MQ on z/OS. For example, an application on a Linux platform can connect to a queue manager on Linux that is connected to a queue manager on z/OS. In this configuration, it is possible for the application on Linux to use its connection to the queue manager on Linux to place a request on a queue residing on z/OS. The reverse is also possible. An application residing on z/OS can get the request message from the queue on z/OS, and then use its connection to the z/OS queue manager to write a reply message on a reply queue residing on Linux.

In this scenario, both the request message and the reply message pass through the Linux queue manager. Using the exit installed on the Linux queue manager, HCL OneTest™ API provides the ability to record the request and reply messages, and create and run tests and stubs for the request/reply operation. The following restrictions apply to this scenario:
  • The recording mode on the physical transport must be set to either Mirror Queues mode or Dynamic Mirror Queues mode.
  • The stubbing mode on the physical transport must be set to either Use Sift & Pass Through with Dynamic Queues or Use Sift & Pass Through with Fixed Queues.
  • HCL OneTest™ API uses operations defined in the Architecture School Logical View to describe Message Exchange Patterns used for recording, testing, and stubbing. Operations can be created manually (see Creating and editing an operation), or in some instances, HCL OneTest™ API creates operations for you automatically. Whether you create it manually or HCL OneTest™ API creates it for you, before running tests or stubs, ensure that the operation is defined according to the guidelines in Defining request/reply operations when the request queue is on z/OS and the reply queue is on distributed.
  • You must not have a local queue on the distributed queue manager with the same name as the request queue on the z/OS queue manager.
  • The clocks where the local queue manager and the remote queue manager reside must be synchronized to prevent reply messages from being time stamped earlier than request messages.

Defining request/reply operations when the request queue is on z/OS and the reply queue is on distributed

WebSphere MQ provides multiple ways for an application connected to one queue manager to access a queue defined to another queue manager. The application can provide both the queue name and the queue manager name in the WebSphere MQ Object Descriptor. Alternatively, the WebSphere MQ system administrator can create a remote queue definition on the local queue manager, which defines the name of the queue and the name of the queue manager on which the queue resides. In this case, the application only needs to supply the name of the remote queue definition, and the queue manager routes put requests to the queue and queue manager specified in the remote queue definition. Finally, if the queue managers are clustered, the queue can be defined as being shared in the cluster. An application connected to any queue manager in the cluster can access the queue simply by specifying the queue name. The queue managers route requests to the appropriate queue on the appropriate queue manager.

The examples that follow describe how to set up an HCL OneTest™ API operation for each of these scenarios, and any special considerations for each. In each case, the Stub tab within the operation must not specify the binding transport.

No binding details

Scenario #1 - – Distributed and z/OS queue managers are not clustered, requesting application is on distributed, request queue is on z/OS, responding application is on z/OS, reply queue is on distributed

Remote queue diagram 1

In this scenario, be sure to specify both the name of the queue manager where the request queue resides, QM01, and the name of the queue manager where the reply queue resides, VBUQ1, within the HCL OneTest™ API operation Message Exchange Pattern.

Binding details

Scenario #2 - Distributed and z/OS queue managers are not clustered, requesting application is on distributed, request queue is on z/OS with a remote queue definition on the distributed queue manager, responding application is on z/OS, reply queue is on distributed with a remote queue definition on the z/OS queue manager

Remote queue diagram 2

In this scenario, even though the request queue is not on the distributed queue manager, it appears as if it is, due to the remote queue definition. Within the HCL OneTest™ API operation Message Exchange Pattern, specify the name of the remote queue definition as the queue name. Specify the name of the distributed queue manager, VBUQ1, as the Queue Manager name. Leaving the Queue Manager name blank is also valid in this scenario.

For the Reply Queue, be sure to specify the name of the reply queue on the distributed queue manager. Do not use the name of the z/OS remote queue definition for the reply queue. Since the HCL OneTest™ API exit is running on the distributed queue manager, it needs to know the name of the queue as it is known on the distributed queue manager. Specify the name of the distributed queue manager, VBUQ1, as the Reply Manager name. Leaving the Reply Manager name blank is also valid in this scenario.

Binding details scenario 2

When creating tests based from messages recorded by HCL OneTest™ API, the reply queue name and the reply queue manager name are extracted from the recorded request message. If there is a remote queue definition on z/OS for the distributed reply queue, the z/OS application might have specified the remote queue definition name within the MQOD, and that is what will be stored within the test. This might result in an error when running the test: Failed to find base object for alias queue. To prevent this error, select the Send Request action within the test, and update the Reply Queue to contain the actual reply queue name as it is known by the distributed queue manager. Also update the Reply Manager either by specifying the name of the distributed queue manager, or clearing the field so that it defaults to the distributed queue manager.

Send request details scenario 2

Scenario #3 – Distributed and z/OS queue managers are clustered, requesting application is on distributed, request queue is on z/OS and is shared across the cluster, responding application is on z/OS, reply queue is on distributed and is shared across the cluster

Remote queue diagram 3

In this scenario, if the request queue and reply queue are shared across the cluster, it is not necessary to specify the Queue Manager name or the Reply Manager Name within the HCL OneTest™ API operation.

Transport details scenario 3

Feedback