Using CA Service Virtualization › Using the Workstation and Console with CA Service Virtualization › Creating Service Images › Create Service Image by Recording › Transport Protocols › IBM WebSphere MQ

IBM WebSphere MQ

Prerequisites: Using DevTest with this application requires that you make one or more files available to DevTest. For more information, see Third-Party File Requirements in Administering.

Follow these steps:

1. To start recording a new virtual service image, complete one of the following steps:
   • Click VSE Recorder on the main toolbar.
   • Right-click the VirtualServices node on the Project panel and select Create a VS Image, by Recording.

   The Virtual Service Image Recorder opens.

2. Complete the Basics tab as in the following graphic:

   

3. Click Next.

   The recording mode selection step opens, with one of the following options selected:

   Proxy Mode

   Proxy mode is the only true recording mode that VSE supports. Proxy mode provides the following options:

   • Generate the service from the Live queues
   • Generate the service using the Proxy queues

   Proxy mode allows the use of proxy destinations to be set up on the message bus. The client application is configured to put messages on those proxy destinations and DevTest records them and forwards to the real destination. The same thing happens on the response side. DevTest is configured to listen on the real response destination, get the message, and forward it to the response proxy destination. This mode can behave differently if you enable temporary destinations, making the response side automated.

   Import Mode

   This mode for recording virtual services is available if you specify a raw traffic file in the Import traffic field on the initial recording window. In import mode, you can specify extra information about which request and response queues were detected in the raw traffic file. You can also select to skip the request response steps.

4. If you are recording in proxy mode, complete the following fields:

   Generate service using the Live queues / Proxy queues

   Specifies whether to use the live queues or the proxy queues when generating the final virtual service model and image.

   Max Pending Transactions

   Defines the maximum number of running response listeners on each response queue. These response listeners run as long as a transaction is pending. When the number of pending transactions exceeds the maximum, the oldest transaction closes automatically. If you enter 0 in this field, there is no maximum.

   Disable Multiple Responses

   Specifies whether to support multiple responses in each transaction. By default, a transaction stays pending after the first response, waiting for more responses to arrive for the same transaction. When you select this option, the transaction automatically closes after the first response. If there are many transactions coming in quickly, this option can boost performance, especially for MQ.

   Correlation

   Contains the possible schemes for correlating the request and response sides of individual transactions. JMS is asynchronous, which means the requests and responses are received separately. This drop-down list lets you define to the VSE Recorder which request to associate with which response. The Correlation field has the following options:

   • Sequential: Associates every response with the last request received, chronologically. There is no correlation scheme, so the VSE MQ recorder acquires an exclusive read lock on the live response queue to ensure that another MQ listener cannot take response messages from it.

     When you specify a correlation scheme, such as Correlation ID or Message ID to Correlation ID, the VSE MQ recorder can assume that any other listener on the live response queue will also use a correlation scheme. If all listeners on the live response queue use correlation schemes, the VSE MQ recorder can keep its responses separate without resorting to an exclusive read lock, so it opens the queue with the shared input flag.

   • Correlation ID: The request and the response must have the same Correlation ID.
   • Message ID to Correlation ID: The request Message ID must be the same as the response Correlation ID.
   • Message ID: The request and the response have the same Message ID.

5. If you are recording in import mode, complete the following fields:

   Client Mode

   Specifies how to interact with the WebSphere MQ server.

   Values:

   • Native Client: A pure Java implementation using IBM-specific APIs
   • JMS: A pure Java implementation that is based on the JMS specification. If you want this implementation, the best practice is to use the JMS transport protocol instead of MQ.
   • Bindings: This option requires access to the native libraries from a WebSphere MQ client installation. Ensure that the DevTest application run time can access these libraries. In most cases, having these libraries available in the PATH environment is adequate.

   Review the queues and transaction tracking mode

   Specifies whether to skip the request and response steps. If the raw traffic file comes from CAI, this option is cleared. CAI autodetects queues and transactions. If the raw traffic file does not come from CAI, this option is selected by default to let you review destination and tracking settings.

   Correlation

   Contains the possible schemes for correlating the request and response sides of individual transactions. JMS is asynchronous, which means the requests and responses are received separately. This drop-down list lets you define to the VSE Recorder which request to associate with which response. The Correlation field has the following options:

   • Sequential: Associates every response with the last request received, chronologically. There is no correlation scheme, so the VSE MQ recorder acquires an exclusive read lock on the live response queue to ensure that another MQ listener cannot take response messages from it.

     When you specify a correlation scheme, such as Correlation ID or Message ID to Correlation ID, the VSE MQ recorder can assume that any other listener on the live response queue will also use a correlation scheme. If all listeners on the live response queue use correlation schemes, the VSE MQ recorder can keep its responses separate without resorting to an exclusive read lock, so it opens the queue with the shared input flag.

   • Correlation ID: The request and the response must have the same Correlation ID.
   • Message ID to Correlation ID: The request Message ID must be the same as the response Correlation ID.
   • Message ID: The request and the response have the same Message ID.

6. Click Next.

   The Destination Info tab opens.

7. Enter your proxy and live queue names, and select the queue type.

   The Create Proxy Queue check box lets you create a temporary queue on the fly to be used as a proxy queue. Select this option if you did not manually create the proxy queue on WebSphere MQ.

8. Click the Connection setUp tab.
9. Enter the connection parameters used to connect to the MOM.

   These connection parameters are internally saved.

   The Advanced tab at the bottom of the Connection setUp tab includes the following subtabs:

   Environment

   Lets you add, delete, and specify values for more MQ environment settings.

   MQ Exits

   Lets you point to MQ exits for Security, Send, and Receive.

10. To define an optional separate set of connection information for when your proxy queues are on a different queue manager from your live queues, click the Proxy Connection setUp tab.
11. Define the connection details for the response destinations on which to listen for messages.
12. Define the proxy queue on which the client application will receive these responses.
    • Remember that multiple responses are possible for a request. To register a set of response proxy queues, click Add .
    • Select the Use for Unknown Responses check box before registering the response queue to use for unknown requests.
    • To define a temporary destination, select the Use temporary queue/topic check box. Selecting this option disables the destination name and proxy destination name fields and marks the response listener you are adding as a temporary response. The destination name is blank.

      A "temporary" destination in messaging is a destination that is created on demand for a messaging client. A temporary destination is typically used in request/response scenarios. DevTest supports using a temporary queue for the responses, but only supports one concurrent transaction with a temporary queue at a time.

13. Click Next.

    The Destination List tab opens.

14. Click the Current Connection Info tab and verify that the connection information is correct.
15. The information that is shown on the Current Connection Info tab is copied from the connection information that you gave earlier. You might want to change it in a rare case when the response connection information is different.
16. Click Next to start recording.

    The names of the queues to which VSE is listening display, and the status is Waiting.

    If you connect to WebSphere MQ and you chose to create the proxy queues on the fly, those proxy queues are created.

17. Run the client that adds messages to the request proxy queue.

    VSE copies the messages to the real request queue. The server acquires those messages from there and sends responses to the response queue or queues. Again, VSE acquires those messages and copies them to the response proxy queue, where the client is listening.

    As the transactions are recorded, the message count increases and the Total sessions and Total transactions counts increase on the Virtual Service Image Recorder window. At the end of recording, all the requests have gone through the same request queue. About half of the responses have returned through temporary queues, and the other half have returned through the nontemporary response queue.

    When the run is complete, you may see the count of messages on the response queues one fewer than you would expect. Because a single request can have multiple responses, VSE will not yet have recognized the last transactions complete. The messages corresponding to the last transaction are therefore not counted.

18. Click Next to trigger closure of the last transaction and complete the necessary cleaning. (You would see an intermediate window if you were using a dynamic data protocol.) As part of preparing the recorder for writing out the .vsi file, the recorder verifies request and response bodies to ensure that, if they are text, if so marked. If they are not, the type is switched to binary.

    A Request Data Manager data protocol has been added on the request side. For more information about configuring this protocol, see "Request Data Manager". You can change or add more data protocols.

19. Click Next.

    Note: To save the settings on this recording to load into another service image recording, click Save above the Finish button.

20. Click Finish to close the window and store the image.
21. Review and save the VSM that was generated in the main window.