Stubbing settings for MQ transport

Stubbing Mode

Select one of the available modes for routing messages.

• Direct: Select this option to enable HCL DevOps Test Integrations and APIs (Test Integrations and APIs) to subscribe to a queue like any other client and consume messages directly. If the real application is running, it is a race condition whether Test Integrations and APIs or the real application receives a message.
  Note: There are no other configuration parameters to specify for the Direct stub mode in this page.

• Use Sift & Pass-through with Dynamic Queues: Use this option to use the API exit to route messages to Test Integrations and APIs instead of placing them on the real queue. The messages are sent to dynamic queues that are created when the stub is run and this can be accessed by only one stub at a time. For each message received, Test Integrations and APIs either responds to it or writes it to the intended queue. For information about configuring a message-based stub properties, see Creating and modifying message-based stubs.
  Notes:

  • If you use this option when stubbing shared queues in a z/OS queue sharing group, only messages from a single queue manager are diverted. To virtualize messages in a z/OS queue sharing group with Test Integrations and APIs, use Use Sift & Pass-through with Fixed Queues instead of this one.
  • Stubbing takes priority over recording. If a stub is intercepting messages for a queue, and if a recording session is also active for the queue, the stub processes the message, and the message is not captured by the recording session.
  • This mode requires access to the SYSTEM.COMMAND.INPUT queue so that the PCF commands can be sent to achieve stubbing of the WebSphere® MQ transport.
• Use Sift & Pass-through with Fixed Queues: This option is similar to the Sift and Pass-through option, but the messages are sent to the fixed queues that are already created and configured with the specific suffix. With this option, you can run multiple stub copies to improve performance. When stubbing shared queues in a z/OS queue sharing group environment, create the .DIVERT and .STUB queues as shared queues.

To enable sift-and-pass-through stubbing, create a diverted queue rules namelist for any Test Integrations and APIs API exits deployed on the queue manager. For more information, see Configuring a queue manager to support sift-and-pass-through stubbing.

Stub Queue, Diverted Queue areas

Pass-through queue

Model Queue for Dynamic mode (Stub, Diverted queues)

In Dynamic mode, the stub queue should be created from a model queue that creates a temporary dynamic queue. This is because only the stub needs to be able to read from this temporary queue, which must be deleted when the connection is closed.

The diverted queue should be created as a permanent dynamic queue because multiple connections need to be able to read from, and write to, it.

Test Integrations and APIs uses temporary queues for recording.

Select the Use Default Model Queue check box (by default, it is selected) if you want to specify SYSTEM.DEFAULT.MODEL.QUEUE or SYSTEM.DURABLE.MODEL.QUEUE (as applicable) as the object from which to copy attributes.

If you want to specify a different model queue, clear the Use Default Model Queue check box and enter a queue name in the Model Queue field.

If you are using Test Integrations and APIs 8.5.0.1 or later, the prefixes used by Test Integrations and APIs when creating WebSphere® MQ model queues for the sift-and-pass-through capability have been changed to be more consistent.

For example: To run a stub using queue Q1, you must manually create Q1.STUB and Q1.DIVERT before you run the stub.

Open Options (Stub, Diverted, Pass-through queues)

Pass-through unhandled messages on stub completion

To pass the queue messages that were not handled by the stub to the "real" queue, select this check box.

Clear this check box to discard the queue messages that were not handled by the stub.