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 agent.
Since the IBM® WebSphere® MQ Series is used to exchange messages between diverse platforms, you can use the HCL DevOps Test Integrations and APIs (Test Integrations and APIs) WebSphere® MQ agent 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.
- 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.
- Test Integrations and APIs 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 an operation), or in some instances, Test Integrations and APIs creates operations for you automatically. Whether you create it manually or Test Integrations and APIs 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 that is 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 Test Integrations and APIs 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.
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
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 Test Integrations and APIs operation Message Exchange Pattern.
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
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 Test Integrations and APIs 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 Test Integrations and APIs 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.
When creating tests based from messages recorded by Test Integrations and APIs,
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.
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
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 Test Integrations and APIs operation.
