JMS Request Test Step

Applies to ReadyAPI 3.57, last modified on December 20, 2024

About JMS Request test step

The JMS Request uses a SOAP or REST Request test step to send a message to a JMS destination.

Creating JMS Request test step

To create a JMS request, you need to have a service added to your project.

  1. 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:

    1. Specify the name of a new request and click OK.

    2. In the next dialog, select SOAP and click OK.

      If you have only one interface in your project, ReadyAPI skips this dialog.

    3. Select the operation for which you want to create the JMS request and click OK.

    4. In the next dialog, specify test step creation options:

      Creating JMS Request for SOAP operation
      Option Description
      Name The name of the new JMS Request test step.
      Add SOAP Response Assertion Adds a SOAP Response assertion to the test step.
      Add Schema Assertion Adds a Schema Compliance assertion to the test step.
      Add Not SOAP Fault Assertion Adds a SOAP Not Fault assertion to the test step.
      Create optional elements Elements marked as <!--Optional:--> in the service definition are included in the request.

    1. Specify the name of a new request and click OK.

    2. In the next dialog, select REST and click OK.

      If you have only one interface in your project, ReadyAPI skips this dialog.

    3. Select the method for which you want to create a JMS request and click OK.

  2. 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.

  3. When you add a new JMS endpoint, you can create an endpoint to one of the specified JMS servers.

    Endpoint to JMS server
    JMS testing: Manual connection to JMS server

    Click the image to enlarge it.

    Option Description
    JMS Server Select one of the JMS servers specified in the JMS dialog or select Create New to create a new JMS server.
    Send Destination JNDI Name The queue or topic to which the test step will send a message. See below for information on specifics of setting topic or queue names.
    Receive Destination JNDI Name The queue or topic from which the test step will receive a response. See below for information on specifics of setting topic or queue names.

    The options are converted to a string and are added to the list of service endpoints in the following format:

    readyjms://jms-server::send/publish-destination::receive/subscribe-destination

    For detailed information on specifying the queue or topic names, see below.

Editing JMS Request test step

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.

Property list

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.

Test step toolbar

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:

JMS Request test step toolbar for a SOAP service

Click the image to enlarge it.

JMS Request test step toolbar for a REST service

Click the image to enlarge it.

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.

Verifying response

To add, change or modify the assertions, use the Assertion panel. You can use the following assertions:

Name Description
Property Content:
Contains Verifies that the response contains the specified string.
Equals Verifies that the value of a property is equal to the specified value.
Equals (Binary) Checks whether the binary response is equal to a file.
Message Content Assertion Verifies that the message contains expected contents.
Not Contains Verifies that the response does not contain the specified value.
Smart Assertion Verifies the message content and metadata such as headers and the status code.
XPath Match Checks whether the result of the specified XPath expression is equal to the specified value.
XQuery Match Verifies that the result of the specified XQuery expression is equal to the specified value.
Compliance, Status and Standards
HTTP Header Equals Checks whether the response contains the expected value of an HTTP header.
HTTP Header Exists Verifies that the response contains the specified HTTP header.
Invalid HTTP Status Codes Checks whether the HTTP status code is not on the specified list.
JSON Schema Compliance Verifies that a request and response are compliant with the specified JSON schema.
Not SOAP Fault  (Only for SOAP services) Checks whether the received SOAP response is not a SOAP fault.
Schema Compliance Checks whether the response is compliant with the specified schema definition.
SOAP Fault (Only for SOAP services) Checks whether the received SOAP response is a SOAP fault.
SOAP Response (Only for SOAP services) Checks whether the received response is a valid SOAP response.
Swagger Compliance Assertion Verifies that a request and response are compliant with an OpenAPI or Swagger specification.
Valid HTTP Status Codes Checks whether the HTTP status code is in the specified list.
WS-Addressing Response (Only for SOAP services) Validates that the last received response contains valid WS-A headers.
WS-Security Status (Only for SOAP services) Validates that the last received response contains valid WS-S headers.
Script
Script Assertion Executes a script to perform a custom assertion.
SLA
Response SLA Checks whether the response was returned within the specified timeout.
JMS Response
JMS Status Verifies that the JMS request is successful.
JMS Timeout Checks whether a JMS response returns within a specific time period.
Security
Sensitive Information Exposure Checks whether the response does not contain any valuable information.

Logging

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.

Working with

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.

    JMS Requests in ReadyAPI: Auth tab

    Click the image to enlarge it.

  • In the Authorization drop-down list, select Basic.

    MS Requests in ReadyAPI: Authorization dropdown

    Click the image to enlarge it.

  • 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:

JMS testing: Changing endpoints

For information on the endpoint format and on the specifics of topic and queue names, see below.

To specify a JMS header:

  1. Open the JMS Headers panel of the request editor.

  2. Specify the value of the desired JMS Header.

See 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.

Setting endpoints

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.

    Example

  • 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

See Also

SOAP Request Test Step
REST Request Test Step
JMS Support
Test Steps

Highlight search results