Recording settings

HCL DevOps Test Integrations and APIs (Test Integrations and APIs) provides a number of ways to record WebSphere® MQ messages.

Choosing the most appropriate method depends on several factors. Some methods require the installation of more software on the WebSphere® MQ queue manager server. For information about this additional software, see Installing and configuring DevOps Test Integrations and APIs API exits.

Note: In Test Integrations and APIs, recording methods are configured on a per-transport basis. To record different queues by using different methods, you have two options:

Create multiple transports.
Create a single transport but change the setting on that transport each time you want to change the recording method.

The following table provides guidelines for selecting recording methods in Test Integrations and APIs when you are using WebSphere® MQ.

Table 1. Choosing a recording method
Recording Method	Description (Summary)	Advantages	Disadvantages
Queue browsing (applicable for all versions of WebSphere® MQ)	Suitable for "recording" a snapshot of the messages in a queue because it does not affect the messages in the queue. A quick and easy way to get a copy of messages that were posted into a queue thus facilitating the quick creation of tests.	No additional software is required on the queue manager. No requirement to reconfigure queues or queue managers when recording starts or stops.	The subscribing system must be stopped to ensure that Test Integrations and APIs can view the messages. Messages are not removed, so if you record again, you get all the events again.
Proxy queues (applicable for all versions of WebSphere® MQ)	The client is changed to publish into a queue that Test Integrations and APIs monitors. When Test Integrations and APIs sees an event it "records" it and then publishes a duplicate message to the original queue. A proxy queue is named the same as the request or reply queue, except for the addition of the Queue Suffix (specified in the WebSphere® MQ transport). Message initiators must be configured to send their requests to the proxy queue.	No additional software is required on the queue manager. The subscriber does not have to be reconfigured.	Requires the client application to be changed to put into the Proxy Queue before recording starts. When recording stops, the client application must be reconfigured to put into the original queue. If recording studio is not running, the end-system does not see the messages.
Mirror queues (applicable only to WebSphere® MQ 7.1 and later)	Record messages from a single queue (or request/reply queue pair) with no reconfiguration of the system under test. With this technique, Test Integrations and APIs configures the queue manager to create a "mirrored queue". Every message that is put into the queue that is being recorded is copied into the mirrored queue. Test Integrations and APIs subscribes to the mirrored queue. Note: This method requires access to the SYSTEM.COMMAND.INPUT queue so that the PCF commands can be sent to achieve recording of the WebSphere® MQ transport.	Transparent to the system under test. No requirement to reconfigure the system under test. Can be used to record messages from multiple queue managers to a shared queue in a z/OS queue sharing group.	The performance of the queue manager is affected adversely. Software must be installed on the queue manager. 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. Note: Changes to the queue manager can require authority to administer WebSphere® MQ.
Dynamic mirror queues (applicable only to WebSphere® MQ 7.1 and later)	Records messages to a temporary queue instead of a fixed queue. Note: This method requires access to the SYSTEM.COMMAND.INPUT queue so that the PCF commands can be sent to achieve recording of the WebSphere® MQ transport.	Transparent to the system under test. No requirement to reconfigure the system under test. WebSphere® MQ clears queues automatically.	The performance of the queue manager is affected adversely. Software must be installed on the queue manager. When used with a z/OS queue sharing group, only messages from a single queue manager will be captured while recording shared queues. 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. Note: Changes to the queue manager can require authority to administer WebSphere® MQ.
Queue aliasing (applicable only to WebSphere® MQ 7.1 and later)	If the system under test publishes by using a Queue Alias rather than directly to a queue, Test Integrations and APIs can reconfigure the queues automatically so that both Test Integrations and APIs and the original subscriber receive a copy of the message. Note: This method requires access to the SYSTEM.COMMAND.INPUT queue so that the PCF commands can be sent to achieve recording of the WebSphere® MQ transport.	No additional software is required on the queue manager. If the system under test already uses alias queues, there is no requirement to reconfigure it.	There must be no connections to the queue alias when recording starts; otherwise, Test Integrations and APIs is not able to perform the necessary automatic reconfiguration. This recording mode works only if the client application is using a queue alias when publishing. Because the queue alias is configured to point to a topic during recording, the client must not be using any queue-specific API calls on the alias, such as queue depth. There can be an overhead during performance testing. Test Integrations and APIs attempts to reconfigure the system under test back to the original settings when recording ends; however, it fails if applications are still connected to the queue alias.
Record-The-Transport (applicable only to WebSphere® MQ 7.1 and later)	Record messages from multiple queues simultaneously. Record when you do not know the queue that is being used. Record many queues without having to set up individual operations first. Note: It is especially useful when dynamic reply queues are being used and the queue name is not known in advance. Note: This method requires access to the SYSTEM.COMMAND.INPUT queue so that the PCF commands can be sent to achieve recording of the WebSphere® MQ transport.	Transparent to the system under test. No requirement to reconfigure of the system under test. There is no requirement to know the exact queue names in use.	A large number of recorded messages can be produced. The performance of the queue manager is affected adversely. Software must be installed on the queue manager. When used with a z/OS queue sharing group, only messages from a single queue manager will be captured while recording shared queues. Note: Changes to the queue manager can require authority to administer WebSphere® MQ.

The recording method and options used when you are capturing messages in the Recording Studio perspective can be set under the Recording tab on the physical transport.

The following options are available on this page:

Table 2. Transport recording options
Field	Description
Use Default Model Queue	Specifies SYSTEM.DEFAULT.MODEL.QUEUE as the object from which to copy attributes. This option is selected by default.
Model Queue	To specify a model queue other than the default, clear the Use Default Model Queue check box and enter a queue name in this field.
Open Options	You can override default options when opening model queues. By default, the field is blank, which causes the value of 1 (MQOO_INPUT_AS_Q_DEF) to be used. To specify a different open option: Click to select one, or more, open options that are supported for the operation. Click OK. The selected open options are converted into a decimal value, which is displayed in the field. Warning: The value entered in the Open Options field is not validated when you click Test Transport or OK. However, an invalid value causes a warning message to be displayed when you start recording.
Queue Prefix	Provides a custom prefix for temporary dynamic queue names. By default, the Queue Prefix field is blank and the prefix "AMQ." is used. If you enter a value in the field, it is prefixed by "AMQ." and suffixed by "." For example, if you enter "RIT" in the Queue Prefix field, the names of any temporary queues created will have the format "AMQ.RIT." where "" represents a 16-character string.

Table 3. Queue recording options
Field	Description
Recording Mode	Select one of the following modes. Refer to Choosing a recording method earlier in this topic for more information. Queue Browsing No further information is required. Proxy Queues Provide a value for the Queue Suffix field. Mirror Queues Provide a value for the Queue Suffix field. This option is available only if WebSphere® MQ 7.1 and later is installed and configured in Library Manager. Dynamic Mirror Queues The same values are required as shown in the previous table, Transport recording options. This option is available only if WebSphere® MQ 7.1 and later is installed and configured in Library Manager. Queue Aliasing Provide a value for the Queue Suffix field. This option is available only if WebSphere® MQ 7.1 and later is installed and configured in Library Manager.
Queue Suffix	The suffix that Test Integrations and APIs uses to create unique queues and topics for the purposes of recording. The details vary according to the recording mode. The following examples assume a suffix of ".GH": Mirror Queues The name of the queue that receives copies of all messages posted to the original queue you are recording is: `OriginalQueueName.GH` Proxy Queues The name of the queue to which the client application must be configured to publish messages is: `QueueName.GH` Queue Aliasing The topic is named: `TTTTT.GH` The queue is named: `QQQQQ.GH`

When you add an event monitor for an operation in Recording Studio, the controls happen as follows:

The recording approach is specified by the transport for the operation.
The queues that are recorded are specified by the operation itself.

If reply queues are specified, suffixed versions of those queues are created.