Testing Tools

Sending a Message to a Queue or Topic

A test message may easily be sent to any queue or topic. The following JMS message types are supported:

To send a message first select the queue or topic then select the send action, for the type of message you wish to send, from the Queues or Topics menu. Alternatively, right click on the queue or topic and select from the right mouse button pop-up menu.

Note; these options will not be available if ViewOnlyMode is enabled in the gems.props file.

Use the send message window to set the message header properties and text body for a TextMessage or fields for a MapMessage.

The following standard JMS header properties are automatically populated:

The JMSDestination header property will automatically be set to the queue or topic that was selected, if there was no selection this will be blank, the destination name must be entered before the message can be sent.

Use the Properties menu or the pop-up right mouse button menu to add any additional message header properties.

Once the header properties and message body have been set press the Send button to send the message. Note; the display remains open so further messages may be sent.

Service Request/Reply Tester

The Request/Reply Tester display may be used to send requests and receive replies to test any request/reply based service operation. To test service operations using queues open the display using the Queues menu, or for topics using the Topics menu.

Configure the following information in the Tester display

Note; temporary destinations are used automatically for receiving replies, for synchronous mode a new temporary is generated for every requests, for asynchronous mode a single temporary is used in conjunction with the JMSCorrelationID. For asynchronous mode to work the receiving service MUST copy the JMSCorrelationID header property from the request to the response message. For synchronous mode the timeout used to wait for a reply may be configured using the Options entry in the Edit menu.

Click Start to run the test, as request messages are sent an entry representing that operation will be shown in the tester window. Once a reply is received the ResponseTime column is updated to indicate the time the service took to execute, to view a reply message double click on the row for the message. All messages may be logged to file using the File menu "Save Messages To File" option.

If replies can be returned on $TMP$ destinations, set tmpQueueReplies and/or tmpTopicReplies to true in the ServiceMonitor element. Note: The monitor does not know in advance which $TMP$ destination a reply will be returned to, hence Gems will subscribe to the system monitor messages for ALL $TMP$ destinations so there may be performance implications to be considered.

Service Request/Reply Monitoring

It is possible to monitor messages used in service request/reply interactions and Gems will automatically correlate the reply with its request message. To open the monitor for queue messages select "Monitor Request/Reply Queue..." from the Queues menu, to monitor topic messages select "Monitor Request/Reply Topic..." from the Topics menu.

If a destination was selected the monitor will automatically use this as the request destination, if not use the "..." button to display the destination picker. Set the reply destination name, if replies are returned on temporary destinations use $TMP$.>. Also set the number of request/reply operations to monitor or specify no limit.

To begin monitoring click the Start button, the display will show one line for each request/reply interaction. The display shows the following information for each:

The following options may be set using the options editor on the Edit menu:

To display further information about a request or reply message open the message display by using the Message menu or right mouse button pop-up menu.

All received messages can be saved to a file using the "Save Messages to File..." option in the File menu.

Note; monitoring destinations under high load can cause message backlogs in the EMS server, the monitor will automatically stop if the message backlog exceeds the configuration property MaxMonitorBacklog (default 1000). MaxMonitorBacklog may be set in the gems.props file.