SOAP Virtual Services

In ReadyAPI, you can manually create a SOAP virtual service by first creating an empty service and then adding virtual operations to it.

A faster approach is to create a SOAP virtual service from a WSDL specification. In this case, ReadyAPI will automatically create virtual operations for the operations it finds in the specification (it can do this for all the operations or some of the operations). If the specification is not part of your ReadyAPI project yet, it will be included into the project. See Generating Virtual Services.

One more way to create a SOAP virtual service and add operations to it is to “discover” an existing SOAP service and create virtual operations from it: you activate a special recording mode in ReadyAPI and send requests to an existing web service with your client application. ReadyAPI traces the traffic and creates a virtual operation from the requests and responses it detected. See Recording Virtual Services (Discovering).

To add new operations to a SOAP virtual service, simply click Operation on the service editor toolbar:

Click the image to enlarge it.

One more way is to use the Generate Virtual Service command. When you select it, ReadyAPI displays the dialog, in which you can select the operations which ReadyAPI will virtualize.

Click the image to enlarge it.

One more possible way to add operations to a virtual service is to record traffic to some existing web service. See Add Recorded Operations to Virtual Service.

Like real SOAP web services, SOAP virtual services accept POST and GET requests. The POST request body should contain XML data that conforms to the SOAP 1.1 or SOAP 1.2 specification.

You can send such requests from ReadyAPI, or use third-party applications like cURL, or use your client code.

If the request type differs from POST or GET, or if the POST request body data does not match the SOAP specification, the service returns the 500 Internal Server Error.

• When a SOAP virtual service receives a request, it checks the request path and the body data format. If the request type differs from POST or GET, or if the POST request body data does not match the SOAP specification, the virtual service returns the 500 Internal Server Error.

  If the request type is POST and the body data format is correct, the service extracts the operation name from the body data and starts searching for the matching virtual operation. If the operation is found, the service uses dispatch settings to select a response for the reply. If the service fails to find an operation, it returns the 500 Internal Server Error.

  If the service has two virtual operations that match the same request, it uses the first found operation.

• The SOAP virtual services use the parameters that are specified in the request body. They ignore query parameters, that is, the parameters that follow a question mark (?) in the URL string.

  To provide different responses for different parameter values, use the Script dispatch type to analyze parameter values and to select the response you need.

You can run SOAP virtual services both on local and remote machines:

• On local computers, you can run them from within ReadyAPI and from the command-line runner.

• To run virtual services on remote machines, you need to install VirtServer there. Alternatively, you can save the virtual service as a WAR file (Web Application aRchive) and run it on a container like Tomcat.

For complete information, see Running Virtual Services.

Running SOAP virtual services exposes their WSDL specification in the following URLs:

For example, to get WSDL of a virtual service that is working on your computer via the HTTP protocol on port 8083 and using the path mockServiceSoapBinding, enter the following:

http://localhost:8083/mockServiceSoapBinding?WSDL

In case a virtual service contains virtual operations based on operations from different WSDLs, the exposed WSDL will be a wrapper that imports both WSDLs.

The exposed WSDL contains the service address and path, not the address of the API, whose WSDL you imported:

SOAP virtual services can apply WS-Addressing and WS-Security settings to responses they send:

To use WS-Addressing:

1. Set the Properties > Enable WS-Addressing property to true, and

2. Configure the settings in the WS-Addressing section.

   For information on the settings, see WS-Addressing.

To use WS-Security:

1. Create a WS-Security configuration. To do this, select the APIs node in the Navigator panel and select WSS config on the toolbar. Create a configuration in the subsequent WS-Security Configuration dialog box.

2. Open your virtual service settings and specify the outgoing WSS configuration you created in the Properties > Outgoing WSS property.

   You can also specify a WSS configuration common for all the responses. You do this in the Properties panel (the bottom left corner of the ReadyAPI window), in the Default Outgoing WSS property.

   If your service uses WS-Security for incoming requests, you specify the WSS configuration in the Incoming WSS property in the Properties panel.

For more information on WSS settings, see WS-Security.

Properties

SOAP Virtual Service Properties

SOAP Request Properties

SOAP Response Properties

Transaction Log Pages

SOAP Request Log

SOAP Response Log