Page History

This section explains how to configure and apply the Call Back tool Tool that supports asynchronous HTTP testing by listening for the asynchronous server response.

...

SOAtest supports asynchronous HTTP testing, including SCP (SOAP Conversation Protocol), WS-Addressing, custom protocols, JMS, TIBCO, IBM MQ, and SonicMQ. After you configure the Call Back toolTool, SOAtest sets up a server to manage the Call Back Messages. It uses the keys you specify in the tool configuration to recognize incoming messages.

Configuring the Call Back Tool

...

1. Ensure that there is a SOAP invocation from a SOAP Client tool.
2. Right-click the main test suite node and go to Add New > Test. The Add Test wizard opens.
3. Choose Standard Test > Call Back Tool from the Add Test wizard and click Finish. A Call Back Tool test node appears in the test suite.
4. Double-click the Call Back Tool test node. The Call Back Tool opens in the workspace. 
   
5. Enter the name of the test in the Name field.
6. If there is a Data Source in the project that contains parameters you want to use as call back values, choose it from the Data Source menu. If there are no data sources in the project, this option will not appear.
7. Specify the length of delay (in seconds) after which SOAtest should consider your requests to be timed out in the Timeout (sec) field.
8. Choose the asynchronous protocol to be used from the Protocol menu. Note that some of the options available are specific use cases for the HTTP protocol (for example, SCP or WS-Addressing). The rest of the settings for the tool will be specific to the protocol selected.
   • Custom: Choose for custom message correlation over HTTP. The Call Back tool Tool will pick up any messages at the call back URL that match the text value of elements at specified XPaths. For example, assume you have the following message:
     <root>
<id>2</id>
<name>Java</name>
</root>
     You can define an XPath of /root/id with value 2. The XPath will select the id element. The Call Back tool Tool will then check if the text content matches the configured value of 2. The Call Back tool Tool will not pick up any received messages that have a different text value for the id element.
     If selected, the Call Back URL field will show the server location of the Call Back toolTool. Enter your XPath/value key sets by clicking Add (if the view is set to Table) or directly (if the view is set to Literal).
   • IBM MQ: Choose for the IBM MQ protocol. If selected, see IBM MQ Tools Reference for more information about the relevant settings.
   • JMS: Choose for the JMS protocol. If selected, see Configuring JMS options for the Call Back Tool for more information about the relevant settings.
   • No correlation: Choose to use the first message in http://localhost:9080/servlet/NoCorrelationCallBackHandler. If this "protocol" is selected and there is no message at that location, the test will fail once it times out.
   • OAuth 2.0: Choose for the OAuth 2.0 protocol. If selected, seeThe Call Back URL field will show the server location of the Call Back Tool. Enter a correlation to parameter in the original URL to login page of the authorization server.
     • The primary use for this option is to incorporate the Call Back Tool as part of a login test suite where the user navigates in their web browser to the login page of their authorization server, provides their login credentials, and then is redirected back to an application (SOAtest in this case) with the resulting authorization code. The Call Back URL shows the URL that should be used for the redirect_uri query parameter when navigating to the login page. After login, the authorization server will redirect the user's browser back to this URL but with additional query parameters state and code. You want to configure the Call Back Tool to correlate on the value of the state parameter, which should match the value of the state parameter that was in the original URL to login page of the authorization server. The code can be extracted by chaining a REST URL Data Bank to the tool's Incoming Request > Transport Header output. For more detail about setting up this kind of login test suite, see OAuth Authentication#CreateRefSuite.
   • SonicMQ: Choose for the SonicMQ protocol. If selected, see SonicMQ Transport for more information about the relevant settings.
   • SCP: Choose to use SCP over HTTP. If selected, the Call Back URL field will show the server location of the Call Back toolTool. Double-click the key set to enter a value for the call back message (the key is automatically set to conversationID).
   • TIBCO: Choose for the TIBCO protocol. If selected, see Configuring TIBCO options for the Call Back Tool for more information about the relevant settings.
   • WS-Addressing: Choose to use WS-Addressing over HTTP. If selected, the Call Back URL field will show the server location of the Call Back toolTool. Double-click the key set to enter a value for the call back message (the key is automatically set to MessageID).
9. Save your changes.
10. Right-click the Call Back Tool test node and select Add Output. The Add Output wizard opens.
11. Select the desired tool from the Add Output wizard to create an output for the Call Back message from the server. For example, you can select the Diff tool to create a regression control on the Call Back message from the server. 

...

If TIBCO is selected as the Protocol for the Call Back toolTool, a TIBCO Properties panel appears at the bottom of the tool configuration panel. SOAtest can listen on a local TIBCO DAEMON or a remote one. That is, the bus daemon could be running on the local machine or somewhere else. The following options are available:

...

The Message Delivery field indicates what type of messages the Call Back tool Tool should look for on the bus. This should correspond to the delivery type established by the message sender.

...

If JMS is selected as the Protocol for the Call Back toolTool, a JMS Properties panel is shown at the bottom of the Call Back tool Tool workspace. The following options are available:

...