SOAP Response Properties

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

To view or change properties and contents of virtual responses, select a response in the Outgoing column of the Setup page of the virtual service editor. You will see the properties on the right of the ReadyAPI window:

SOAP service virtualization and API testing: Properties of outgoing messages (responses)

Click the image to enlarge it.

Properties of SOAP responses are organized into the following categories.

Edit

Property Description
Http Status Code

The response status line and code. This is the same value that you set in the Response HTTP-Status property in the Properties section.

Note: When validating virtual responses, ReadyAPI does not treat “error” codes like 404 or 406 as errors. These codes can be expected by your test procedure. To verify whether a virtual service functions properly, use assertions on the client side.
XML

The XML tab contains the response body data. You can include service, response and data source properties into the response. To do this, use syntax like this:

${#MockService#Virt-Property-Name}

${#MockResponse#Response-Property-Name}

${DataSource-Property-Name}

See Property Expansion in Responses and Data Sources in Virtual Services for complete information.

The Outline view is available if the Editor contains XML data.

Raw

Displays the contents of the last response of your virtual service (status line, headers and body). Read-only. Use this view to explore the data the virtual service sends.

To view data on the Raw tab, send a sample request to the service.

Outline

A tree-like view of the response contents you set on the XML tab. Available if the response body contains valid XML data. To modify a value of some element, simply click within the Value cell and enter the new data. Press Enter to confirm the changes or Esc to cancel them.

If needed, you can specify the service properties and data source properties. Use the same syntax that you use in the XML tab (see above).

Form

A form-like editor of response data. If needed, you can specify the service properties or data source properties in edit fields. To do this, use the same syntax that you use in the XML tab (see above). Alternatively, you can click the ellipsis button and select the desired property in the context menu (currently, this works for service properties).

Script

Groovy script code that the virtual service runs before sending the response to the client. You can use this code, for example, to change the response contents or for debug purposes. For information on scripting and available objects, see Virtual Service Scripting.

Note that methods and properties of the mockResponse object modify the response body that you have on the XML tab.

Headers

A list of custom response headers. The toolbar above the list contains commands for creating and deleting headers, changing their order, sorting, clearing header values, and loading header values from and saving them to a file.

In custom headers, you can mention custom properties of your service or data source properties, for example:

SOAP service virtualization and API testing: Custom response headers

See Property Expansion in Responses.

Attachments

A list of files to be attached to the response. The toolbar above the list contains commands for adding attachments to the response, deleting them, storing to a file and replacing the selected file with some other file.

When you add a file to the list, ReadyAPI asks if you want to cache it in the response. If you approve, the virtual service will create a file copy and will attach this copy to the response. If the file changes on the hard drive, then you will need to add it again to the Attachments list (you can use the “Reload... ” command for this purpose).

If you decline to cache the file, then the service will load the file from the hard drive every time the response is sent. This means that the file must exist in the same folder where it was at the time of the response creation. This may cause issues if you try running your virtual service on another computer. In other words, if you are going to deploy and run a virtual service on some server, we recommend that you cache files in the response.

For more information on how ReadyAPI works with attachments, see Attachments.

WS-A

WS-Addressing settings applied to the response. For details, see WS-Addressing.

Coverage

This section gives estimations of what elements of the response definition the given response will cover. To view coverage data, simply select the Enable Message Coverage check box in the section:

Service virtualization and API testing: Coverage results of a response of a SOAP virtual service

ReadyAPI reports coverage information by analyzing the response contents you set in the Edit section. There is no need to run your virtual service and simulate requests for this.

The green color indicates the elements that the response covers (that is, the elements that are in the response). The red color indicates missed elements or the elements that have no value. The numbers that appear in the section title specify the number of covered elements against the total number of elements in the response body. The total number is a sum of elements on all the levels.

Click to open the Coverage Options dialog and to configure settings that affect the coverage check, for example, how ReadyAPI should treat empty elements or what elements to exclude from the check.

Data Source

Specifies the data source, whose properties you can use in the response body and headers. See Data Sources in Virtual Services.

Properties

Property Description
Message Size The size of the most recent response in bytes.
Encoding The response body data encoding to be used. Possible values include UTF-8 and iso-8859-1.
Outgoing WSS The WS-Security configuration that the virtual service will apply to the response before sending it to the client. See WS-Security.
Enable MTOM Enables the MTOM packaging method for attachments.
Force MTOM Specifies whether the service will use the MTOM packaging for all attachments. Used even if there are no MTOM attachments.
Enable multiparts Specifies whether the virtual service will send attachments of the same type as multipart.
Encode attachments Encodes attachments using the encoding type set by the service definition (WSDL). For example hex binary, or base64.
Strip Whitespaces Specifies whether the virtual service will remove comments and extra whitespaces from elements and attributes of the response.
Remove Empty Content Specifies whether the service will remove empty elements from the response.
Entitize Properties Specifies whether the service will encode special characters in the response. For example, HTML symbols (like & or >) are entitized into (& or >). Set to false if data is already encoded.
Enable Inline Files Specifies whether the virtual service will insert file data into the response body using the file: element.
Response HTTP-Status Specifies the response status code. This is the same value that you set in the HTTP Status Code field in the Edit section.
Response Delay The number of milliseconds that the service will wait before sending the response to the client.
Response Compression Added for backward compatibility. Always <auto>.
WS-Addressing Specifies whether the service will apply WS-Addressing to the response. You can edit the WS-Addressing settings in the WS-A section.

XSD

Displays the schema definition of the element that is currently selected on the XML tab. For instance, if the insertion point is on the <soapenv:Envelope ...> element in the XML tab, the XSD box displays the XSD schema declaration for this element. As you move the insertion point to child elements, the XSD box updates and displays the definition for the element, in which the insertion point resides. The text in parentheses after the XSD title specifies the current element data type. If the definition is not found, the XSD box is empty and the parentheses display a question mark.

Doc

The description of the element that is currently selected on the XML tab. ReadyAPI takes the description from the WSDL of your virtual API.

See Also

Reference

Highlight search results