The JMS Request uses a SOAP or REST Request test step to send a message to a JMS destination.
Important
To create a JMS request, you need to have a service added to your project.
Specify a request based on which you want to create a new JMS test step. The creation process is different for SOAP and REST services:
The next dialog offers you to select a JMS endpoint specified for the service or create a new one.
Note
If you do not have any endpoints configured in the selected interface, this dialog is skipped.
When you add a new JMS endpoint, you can create an endpoint to one of the specified JMS servers.
Depending on the service, you use different editors to modify the created test step:
For the SOAP services, the editor is similar to the SOAP Request test step editor.
For the REST services, the editor is similar to the REST Request test step editor.
Depending on the service API type (SOAP or REST), the property list of the JMS Request test step is the same as for to the SOAP or REST request test step.
The JMS Request toolbar contains commands that allow you to modify the test step, underlying service or appearance of test step editor. Depending on the used service, the toolbar is different:
![]() |
![]() |
Note
Now users can use a file named readyapi-install.vmoptions
to specify JVM options that ReadyAPI will incorporate post-installation. The file must be in the same directory as the ReadyAPI installer. This is introduced so that system administrators can set up necessary options for end users.
To add, change or modify the assertions, use the Assertion panel. You can use the following assertions:
Name | Description |
---|---|
Property Content: | |
Verifies that the response contains the specified string. | |
Verifies that the value of a property is equal to the specified value. | |
Checks whether the binary response is equal to a file. | |
Verifies that the message contains expected contents. | |
Verifies that the response does not contain the specified value. | |
Verifies the message content and metadata such as headers and the status code. | |
Checks whether the result of the specified XPath expression is equal to the specified value. | |
Verifies that the result of the specified XQuery expression is equal to the specified value. | |
Compliance, Status and Standards | |
Checks whether the response contains the expected value of an HTTP header. | |
Verifies that the response contains the specified HTTP header. | |
Checks whether the HTTP status code is not on the specified list. | |
Verifies that a request and response are compliant with the specified JSON schema. | |
(Only for SOAP services) Checks whether the received SOAP response is not a SOAP fault. | |
Checks whether the response is compliant with the specified schema definition. | |
(Only for SOAP services) Checks whether the received SOAP response is a SOAP fault. | |
(Only for SOAP services) Checks whether the received response is a valid SOAP response. | |
Verifies that a request and response are compliant with an OpenAPI or Swagger specification. | |
Checks whether the HTTP status code is in the specified list. | |
(Only for SOAP services) Validates that the last received response contains valid WS-A headers. | |
(Only for SOAP services) Validates that the last received response contains valid WS-S headers. | |
Script | |
Executes a script to perform a custom assertion. | |
SLA | |
Checks whether the response was returned within the specified timeout. | |
JMS Response | |
Verifies that the JMS request is successful. | |
Checks whether a JMS response returns within a specific time period. | |
Security | |
Checks whether the response does not contain any valuable information. |
While the test step editor is open, brief information on sent requests is listed in the Log tab. If the test step is run as part of a test case, you can see a more detailed log in the Transaction Log panel.
Most actions that you can perform with the JMS Request test step are similar to the SOAP or REST request test step depending on the service you use. Below, you can find information specific to the JMS Request test step.
If your JMS server uses authorization, configure requests to send credentials to the server, as well.
Open the Auth tab in the request editor.
In the Authorization drop-down list, select Basic.
Enter user credentials in the Username, Password and Domain fields.
To change the endpoint, type the new endpoint on the toolbar or press the down button and use the items of the drop-down list:

For information on the endpoint format and on the specifics of topic and queue names, see below.
To specify a JMS header:
Open the JMS Headers panel of the request editor.
Specify the value of the desired JMS Header.
See the JMS Message Header for more information.
To specify a JMS property:
Open the JMS Properties panel of the request editor.
Specify the name and value of a property.
To remove the Content-Length: 0
header from your request, add the -Dsoapui.send.zero.content.length=false
parameter to the vmoptions file located in the <ReadyAPI>/bin
directory and restart ReadyAPI.
The endpoints you specify in the JMS Request step have the following format:
readyjms://<server/session>::<send/publish destination>::<receive/subscribe destination>
Where:
server/session – the name of the configured JMS server the request will use.
send/publish destination – The queue or topic to which the request will be sent.
receive/subscribe destination – The queue or topic from which the request will receive the response.
For ActiveMQ, the endpoint should include additional JNDI property names mapped in ReadyAPI.
For WebSphere MQ, the endpoint should include destination names mapped in WebSphere MQ.
If needed, you can specify “send-only” or “receive-only” endpoints:
Send-only:
readyjms://jms-server::send/publish-destination
Receive-only:
readyjms://jms-server::-::receive/subscribe-destination