The JMS Messaging (JNDI) step lets you send messages to, and receive messages from, topics and queues. You can also receive, change, and forward an existing message. The list of possible queues and topics can be browsed using JNDI. Provide client libraries where DevTest can read them.
All the common message types including Empty, Text, Object, Bytes, Message, and Mapped (Extended) are supported.
The JMS Messaging (JNDI) step is configured using a single editor regardless of the messaging requirements. The input options vary on the messaging requirements. The editor only allows valid configurations, so when you enable some features, others could become inactive.
The JMS Messaging (JNDI) step has a default name using this convention: JMS publish-queuename publish. If there is not a publish queue name, the default step name is JMS subscribe-queuename subscribe. If another step uses the default step name, DevTest appends a number to this step name to keep it unique. You can change step names at any time.
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.
Parameter Requirements: This step requires the connection parameters and the queue or topic names that are used in the application under test. Other parameters could be required, depending on your environment. Get these parameters from the application developers. In most cases, you can browse for server resources to get some of these required parameters.
The jms.tst test case in the examples project shows the step that this section describes.
The jms.tst test case uses a publish/subscribe JMS step to send a message and listen on a temporary queue. A Message Driven Bean (MDB) on the server handles the message and drops the message onto the temporary queue. The message type is text. The message is an XML payload that is created by inserting properties dynamically into the XML elements. The properties are read from the order_data data set. After the response message is received, the XML from the JMS message is put into a property. The next step does an assertion validating the order ID. After this check asserts true, the existing message object is changed, and the message is sent to another JMS destination.
The jms.tst test case shows how to listen for and intercept messages as they move through a multipoint messaging service backbone. You can run this test case against the demo server on your computer. The application backend is available there.
The editor for the JMS Messaging (JNDI) step contains the following tabs:
The Base tab is where you define the connection and messaging parameters.
The following graphic shows the Base tab. The tab is divided into the following sections:
To enable and disable the Subscriber Info, Publisher Info, and ReplyTo Info, use the enable check box in the top left corner of each section. This option allows you to configure the step to be a publish step, a subscribe step, or both. You can also select to include a JMS reply to component in the step.
When you finish configuring the test step, click Test in the Error Handling and Test section to test the configuration settings.
Server Connection Info
Enter the JNDI information in the Server Connection Info section of the Base tab.
To simplify changing the application under test, parameterize these values with properties that are in your configuration. The previous graphic shows an example of this approach.
The following parameters are available to you for the system under test:
The fully qualified class name of the context factory for the JNDI provider.
The URL for connecting to the JNDI server. The format of the URL depends on the specific JNDI provider being used.
Use Search 
to browse available resources on the server. Select or enter a connection factory to use for this step execution according to the JMS specification.
The pull-down menus contain common examples or templates for these values.
The user and password could be optional.
The user name for connecting to the JNDI provider and getting a handle to the connection factory.
The password for connecting to the JNDI provider and getting a handle to the connection factory.
To share JMS sessions and publishers throughout the test case, use these check boxes. This approach can lower overhead, but does not always provide a realistic simulation because typically JMS clients want to release resources. If you select the Share Publishers check box, the Share Sessions check box is also selected. You cannot share publishers without sharing sessions. For more detailed information about these parameters, see the Deliberate Delays in VSE knowledge base article.
Lets you stop any listeners at design time now. Some listeners can get orphaned, but still consume messages. When they do, it is difficult to create test cases.
Displays a panel where you can add custom properties that are sent with the connection information and you can configure the second-level authentication.
Note: The Server Connection Info user and password fields are for connecting to the JNDI provider and getting a handle to the connection factory. The user and password fields in the Second Level Authentication tab are for getting a handle to the actual JMS connection.
Publisher Info
To set up the ability to send messages, select the enable check box.
To execute a commit when the message is sent, select the use transaction check box.
Enter the following parameters:
The name of the topic or queue. Use Search to browse the JNDI server for the topic or queue name.
Select whether you are using a topic or queue. To see what messages are waiting to be consumed from a queue (only), use Browse 
to the right of this field.
Select the type of message you are sending. The supported types are Empty, Text, Object, Bytes, Message, and Mapped (Extended).
Displays a panel where you can edit the message headers and can add message properties.
Subscriber Info
To set up the ability to receive messages, select the enable check box.
Enter the following parameters:
The name of the topic or queue. Use Search to browse the JNDI server for the topic or queue name.
Select whether you are using a topic or queue, and whether to listen in synchronous or asynchronous mode. For asynchronous mode, you also must have an entry in the Async Key field. To see what messages are waiting to be consumed from a queue, use the Browse icon to the right of this field.
The period to wait before there is an interrupt waiting for a message. Use 0 for no timeout.
The value that is necessary for identifying asynchronous messages. This field is necessary only in asynchronous mode. The field is used in a subsequent Message Consumer step to retrieve asynchronous messages.
By entering a name here, you are requesting a durable session. You are also providing a key for that session. A durable session lets you receive all of your messages from a topic even if you log out and then you log in again.
The options available are:
Auto Acknowledge and Client Acknowledge and Auto (Duplicates Only) have no practical differences. With Client Acknowledge, each received message is acknowledged immediately upon receipt. The only difference is that the acknowledge call is made explicitly instead of letting the JMS client library do it. With Auto (Duplicates Only), the behavior is the same as Auto Acknowledge except under high loads.
The Use Transaction option is not strictly an acknowledgment mode setting. The option is included in the list for two reasons:
If you want the JMS provider to set up a temporary queue/topic on your behalf, select this check box. When a temporary queue/topic is used, DevTest automatically sets the JMS ReplyTo parameter of the message you send to the temporary queue/topic. The temporary queue/topic feature must always be used with a publisher so that a reply can be sent. If you use a temporary queue/topic, the ReplyTo section is disabled.
To make the payload response the last response, select this check box.
ReplyTo Info
To set up a destination queue/topic, select the enable check box.
If your application requires a destination, it is set up in this section.
Enter the following parameters:
The name of the topic or queue. Use Search to browse the JNDI server for the topic or queue name.
Select whether you are using a topic or queue. To see what messages are waiting to be consumed from a queue (only), use Browse to the right of this field.
Error Handling and Test
If an error occurs, the Error Handling and Test section lets you redirect to a step.
Specifies the action to take or the step to go to if the test fails because of an environment error.
Default: Abort the test.
Click Test to test your step configuration settings.
You can enter a JMS selector query in the Selector Query tab. The syntax closely follows SQL. The query is a subset of SQL92.
A JMS selector query can be specified when listening for a message on a queue that is a response to a published message.
The following graphic shows a query looking for a JMSCorrelationID that matches the lisa.jms.correlation.id property as sent with the original message.
If your step is configured to publish, you compose the message in the Send Message Data tab.
You can type the text, or you can click Read Message from File to read from a file. You can also store text in a property, in which case you would place the property in the editor, for example, {{property_name}}.
The following graphic shows an XML fragment with properties. Using the properties allows the message to be created dynamically during the test run.
If your step is configured to subscribe, the response appears in the Response Message tab after you click Test in the Base tab.
The tab shows the Complex Object Editor for the returned object. The returned object varies with the type of application server. You have access to all the JMS parameters returned in addition to the message itself. The object is loaded into the Complex Object Editor, where it can be manipulated like any other Java object.
The following graphic shows a text response from a JBoss object.
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|