JMS Request Test Step

About JMS Request test step

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

Create JMS Request test step

Important

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:

  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.

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

SOAP service

JMS Request test step toolbar for a SOAP service

REST service

JMS Request test step toolbar for a REST service

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.

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

Configure authorization

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
  • In the Authorization drop-down list, select Basic.

    MS Requests in ReadyAPI: Authorization dropdown
  • Enter user credentials in the Username, Password and Domain fields.

Change endpoint

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.

Specify JMS headers

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 the JMS Message Header for more information.

Specify JMS property

To specify a JMS property:

  • Open the JMS Properties panel of the request editor.

  • Specify the name and value of a property.

Remove the “Content-Length: 0” header

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

Format

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.

Queue and topic names

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

“Send-Only” and “Receive-Only” endpoints

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

Publication date: