This topic covers the SonicMQ Transport, which is implemented as an extension to the JMS Transport.
In addition to JMS Message types, SOAtest and certain Virtualize supporting tools and provisioning action tools support
MultiPartMessage for the SonicMQ Transport. For JMS Message types, you need to use JMS Transport. For more information on the JMS Transport, see JMS 1.
For outbound messaging, a
MultiPartMessage is constructed with a single part that wraps the request message as "text/xml" type. Users can specify the 'Content-ID' header field of the part via the Part Content ID field. For inbound messaging, both JMS and SonicMQ Transports can parse MultiPartMessage with multiple parts.
Creating New Tests for SonicMQ
To configure SOAtest to create tests for access SonicMQ, complete the following:
After selecting SonicMQ from the Transport drop-down menu within the Transport tab of an appropriate tool, the following options display in the left pane of the Transport tab:
Connection Settings contains the Settings and Properties tabs. The Properties tab is optional and allows users to specify additional properties to be passed to the JNDI javax.naming.InitalContext constructor; in addition to the Provider URL and Initial Context factory properties that are specified in the Settings tab. The Settings tab contains:
If you select Use Shared Property, a second drop-down menu displays from which you select the desired global SonicMQ settings that the tool will use. For more information, see
In addition to the Settings tab, the Connection Settings also include:
The Queue/Topic settings contain the following options:
Messaging Model options specify how messages are sent between applications. Select either Point to Point or Publish and Subscribe.
Message Exchange Pattern options specify whether or not SOAtest or Virtualize receive a response. If Get Response is selected, SOAtest or Virtualize sends a message and receives a response. If Get Response is not selected, SOAtest or Virtualize sends a one-way message and does not receive a response.
If Get Response is selected, you can also enable Create consumer on the JMSReplyTo destination before sending the message.If the response is expected to become available very quickly on the JMSReplyTo topic, this option should be enabled to ensure that SOAtest or Virtualize has subscribed to the reply topic before the response message is published.
This option is cannot be mixed with Match response JMSCorrelationID with the request JMSMEssageID because the JMS specification requires vendors to generate the JMSMessageID after the message is sent. As a result, there is no way to create the consumer on the response destination with that correlation (selector) set until after the message has been set and the JMSMessageID becomes available.
Message Type options allow you to select the message type from the drop-down menu. A SonicMQ Message is a Java object that contains the data being transferred between SonicMQ clients. The following Message Types are available:
A Sonic MultipartMessage can have multiple parts. Each part has its own name (ID) and content. SOAtest and Virtualize support sending MultipartMessages with a single part. This field specifies the part name and the content is defined by the Request area, such as Form Input, Literal, Literal XML (SOAtest), etc. SOAtest and Virtualize support receiving MultipartMessages with multiple parts and outputs all the part contents as XML to the Response Output of the tool.
The Request Message Properties are optional and allows for any miscellaneous property values to be set into the javax.jms.Message object before it gets sent to a queue or published to a topic. These include predefined properties that get set to the outgoing requests message using one of the corresponding "set" methods in javax.jms.Message, or any custom property provided with the setStringProperty() method.
The Response Message Correlation settings contain the following options:
Additional Selector Expression Terms: (Optional) Enter a value to act as a message filter. For tips on specifying a selector,
You can add message object outputs to tools that utilize the SonicMQ transport. For example, an Extension tool chained to a tool that uses SonicMQ will have access to the response SonicMQ Message. In the ObjectMessage case, you can use
equals() methods to validate the response thereby creating a regression control. In addition, you can chain a Diff tool to the Response Traffic and if the response is an ObjectMessage, SOAtest or Virtualize will convert the inserted serializable object to XML format and perform an XML diff. By doing this you can use data bank values, ignore XPath differences, etc.
To do this complete the following:
Right-click SOAP Client or Messaging Client node, or the Virtualize tool node the node for which you would like to add the output and select Add Output from the shortcut menu. The Add Output wizard displays.