Using CA Service Virtualization › Using the Workstation and Console with CA Service Virtualization › Creating Service Images › Create Service Image by Recording › Transport Protocols › Standard JMS

Standard JMS

This topic contains the detailed instructions for recording a virtual service image using the Standard JMS transport protocol.

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. To record 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.

5. To record in import mode, complete the following fields:

   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 destination names, and select the destination type.
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 lets you define custom connection properties for the service image.

10. Click Next.

    The Destination List tab opens.

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 the Current Connection Info tab and verify that the connection information is correct.

    The information that appears on this tab is copied from the connection information that was given earlier. You could change it in a rare case when the response connection information is different.

14. Click Next to start recording.

    The names of the destinations to which VSE is listening display.

    The Pending Transactions field displays the number of transactions that are stored in the pending transaction buffer waiting for more responses. The transactions are closed either by reaching the maximum pending transaction count or by using the Disable Multiple Responses option. As the transactions close, they are moved from the pending transaction buffer to the total transaction buffer.

15. 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. Again, VSE acquires those messages and copies them to the response proxy queue, where the client is listens.

    As the transactions are recorded, the message count increases and 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 less than you expect. Because a single request can have multiple responses, VSE will not yet have recognized the last transactions to complete. Therefore, the messages corresponding to the last transaction are not counted.

    Recommended data protocols are defaulted on this panel. You can add or edit both request and response side data protocols here. If there are configuration panels for the data protocols you have chosen, they open next. For more information, see Using Data Protocols.

16. Click Next.

    The last transaction closes and the necessary cleanup completes.

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

17. Click Finish to close the window and store the image.
18. Review and save the VSM that is generated in the main window.