SOAP Clients are tools that check the functionality of SOAP-based services. You can add SOAP Client tools to your test scenarios and configure them to suit your testing needs. You can then create and run a job for executing the related test scenarios and with the appropriate environment provisioned. Use these tests for checking the health of specific components and for automated testing during provisioning. 

The SOAP Client interface in CTP is designed to quickly enable you to create new SOAP Client tools. Use the SOAtest desktop to create more advanced SOAP Clients with more complex configurations, such as message payloads defined by custom scripts.See SOAP Client.

If you have a traffic file that captures traffic for a SOAP service, you can generate a test scenario with SOAP Clients configured to test the recorded traffic. For details, see Creating New Test Scenarios and Test Suites.

Adding a SOAP Client

  1. In the left pane, select the .tst or test suite where you want the new SOAP client added.
  2. Choose Add SOAP Client from the page-level action menu.
     
  3. (Optional) Modify the name of the newly-created tool.
  4. Configure the tool as described below and click Save.

The new tool will be added at the end of the selected test suite.

Configuring a SOAP Client

  1. (Optional) You can associate the client with requirements, tasks, or other work items in the Work item field. See Associating Tests with Work Items for details. 
  2. If the containing test suite includes multiple data sources, you can review and change which data source is used to parameterize this SOAP Client. See Parameterizing with Data Source and Data Bank Values for details.
  3. Specify the endpoint of the service to invoke in the Endpoint field. 
  4. Specify the action you want performed in the SOAP action field. 
  5. (Optional) You can configure the client so that it succeeds with HTTP response codes outside the 2xx range. Specify single codes and/or code ranges as a comma-separated list in the Valid response field. For example, if you use "302, 500-599", a 302 code or any code in the 5xx range will be accepted.  If you're using a parameterized value, be sure that the value in the data source uses this same format (e.g., "302, 500-599").
  6. (Optional) Specify a length of time in ms before the client timeouts if it does not receive a response.
     

  7. (Optional) If the service requires authentication, enable the Enable HTTP authentication option and specify login credentials.


  8. (Optional) Add HTTP headers if you want to override the default headers.See HTTP Headers for additional information. Choose Literal or Table mode from the HTTP headers drop-down menu to enter values in a text area or build the header using a table format. 

  9. (Optional) If you want to reset cookies before sending a request, enable the Rest existing cookies before sending request option.

  10. In the Request area, specify the message request that will be sent. Specify the message in the literal text editor, the JSON editor, or the XML editor (see  Editing JSON Messages and Editing XML Messages for details and tips).

    If you’re familiar with SOAtest, you can use the standard ${var_name} notation to reference environment variables, test suite variables, and data source values that are defined for the test scenario. This applies to both URL and Payload.

    When you are working with JSON, a special notation is used for parameterizing a number or boolean field within a JSON message: ${number:<value>} or ${boolean:<value>}. For example, to parameterize a number field with the column Count, you would use ${number:Count}.