Asynchronous Service Calls

Relevant for: API testing only

You can use OpenText Functional Testing to emulate asynchronous services, such as Web Services, REST services, HTTP requests, or JMS/MQ-based services.

In synchronous messaging, the replay engine blocks step execution until the server responds. The client sends a request and receives a response immediately, using the same connection. During the waiting time, the replay engine is blocked and does not perform any other activity. If the timeout was reached without a response from the server, the client returns an error.

In asynchronous mode, the replay engine executes the step without waiting for server's response from previous requests.

OpenText Functional Testing provides a solution for various asynchronous patterns.

WS-Addressing

WS-Addressing is a specification that enables Web services to communicate addressing information. You can instruct the server to respond to any location, and not necessarily to the machine that issued the request. To do this, you use the WS-Addressing replyTo attribute.

In this implementation, OpenText Functional Testing pauses the test and uses a listener mechanism to verify that the response arrived at the specified address. After the listener acknowledges that the server responded to the address or if it reaches the timeout, the test resumes. After completion of the test, you can validate the response with the standard API testing checkpoints.

HTTP Receiver

In the HTTP Receiver pattern, the server sends an HTTP request to the client, reversing the typical roles of the client and server.

This is useful, for example, if you want to test a service which publishes information over HTTP to a client. You define a receiver, which waits for a request from the server, sent over HTTP.

After a trigger, the receiver captures the request. The trigger can be an HTTP client request, a call to a Web service, an email, or any other event that will trigger the server. If there are inner steps, the receiver waits for them to finish and only then is the receiver activity considered complete.

Using the API testing interface, you can insert the necessary logic and validate the checkpoints in the captured request.

The response from the receiver should wait for the inner steps to complete and link to them.

The completion event name fired for the receiver should only be fired AFTER the inner steps are done.

Web Service Publish Subscribe

In the Web Service Publish Subscribe pattern, the server sends an HTTP request to the client, reversing the typical roles of the client and server. it is similar to the HTTP Receiver, except that the request is sent to the client through a Web Service call instead of exclusively using HTTP.

Using OpenText Functional Testing, you test the publishing of messages to the client. You set up a receiver, which waits for a server request, sent from the server as a Web service call.

After a trigger, the receiver captures the request. The trigger can be an HTTP client request, a call to a Web service, an email, or any other event that will trigger the server.

Using the API testing interface, you can validate the response with standard API testing checkpoints.

Web Service Solicit Response

The Web Service Solicit Response pattern is a variation of the Web Service Publish Subscribe pattern. It enables you test a a service which publishes information through a Web Service to a client.

In this pattern, however, the client is expected to send a response to the server request. The response can be a simple acknowledgment or a full SOAP message.

You set up a receiver activity, which waits for a server request. This server request is sent from the server as a Web service call. The receiver then sends a client response back to the server.

After the trigger, the receiver captures the request. The trigger can be an HTTP client request, a call to a Web service, an email, or any other event that will trigger the server.

Using the API testing interface, you can validate the response with standard API testing checkpoints.

Dual WSDL Files

The Dual WSDL technique is a standard request-response pattern. In this pattern, however, the client request is defined by one WSDL, and the server response is defined by another WSDL.

You implement this scenario in two stages:

Import the Request WSDL file, using the Import WSDL from import command.
Import the Response WSDL file, using the Import WSDL from import command, enabling the Import as Server Response option. For details, see the Import/Update WSDL/WADL/Swagger Service from URL or UDDI Dialog Box or Select WSDL Dialog Box.