Reference › Test Case Reference › Test Step Descriptions › Web-Web Services Steps › Web Service Execution (XML) Step

Web Service Execution (XML) Step

The Web Service Execution (XML) step is designed to execute an operation on a SOAP-based Web Service using an HTTP POST or JMS message.

Access to a WSDL is not required; rather, it is a recommended but optional piece of configuration information. If a WSDL is configured, it helps in the process of building a SOAP message to be sent to the service. This step lets you manipulate the raw SOAP message (XML) directly. This feature provides flexibility and power, but does expose you to the details of how web services work.

In general, the top portion of the editor is dedicated to how and where to send the SOAP message. The bottom portion is dedicated to the contents of the message.

The Web Service Execution (XML) step has a default name using this convention: Web Service webServiceOperation name. If another step uses the default step name, DevTest appends a number to this step name to keep it unique. You can change step names at any time.

After the test step opens, it has two tabs, with each tab having multiple sub tabs.

The PRO icon switches between basic and advanced options. Some tabs and options are only available when PRO is selected.

Connection Tab

The Connection tab has fields for the connection. The tab has sub tabs on the top bar and bottom bar.

• The top bar - for viewing the Visual XML, Raw XML, Headers, Attachments.
• The bottom bar - for Request and Response.
  • Basic Configuration
  • Design Time Execution

Basic Configuration

Connection

WSDL URL

The WSDL URL is an optional but recommended field (denoted by its slightly gray color).

The WSDL URL must be a URL (either file:/, http:/, or https:/). From the More Options menu you can:

• Browse the file system for a local WSDL or WSDL Bundle file.
• Search a UDDI Registry (which populates the advanced UDDI access point lookup).
• To migrate from the legacy WS step, select WSDL from hotDeploy.
• Create and use a WSDL bundle. You can also create a WSDL Bundle from the Actions menu, but from the Options menu, DevTest automatically populates the WSDL URL with the resulting WSDL bundle file URL. Or if you already have a WSDL URL populated, it prepopulates the WSDL URL in the WSDL bundle dialog.

When you enter a WSDL URL that is not already a WSDL bundle, DevTest creates a WSDL bundle and stores it locally in the Data/wsdls directory for the project. This action caches the WSDL locally for quicker access. DevTest parses the WSDL and uses its schema is used to build sample SOAP messages. The Visual XML editor also uses the WSDL to help you manually edit the SOAP message. DevTest first tries to load a cached WSDL bundle whenever processing the WSDL. If the external WSDL has changed and you want to force the local WSDL cache to update, use the Refresh WSDL Cache button. You can manually drop a WSDL bundle into the Data/wsdls any time. When the step tries to process the "live" WSDL URL, it uses the cached bundle instead.

Service, Port, Operation

If the WSDL URL is populated, the WSDL is processed and the Service, Port, and Operation selections are populated. These optional but recommended fields can be used to build a sample SOAP request message. Selecting a port also updates the Endpoint URL to match the definition in the WSDL. Changing the WSDL URL causes these items to be refreshed. If the Endpoint URL and SOAP Message are unchanged, they update also to correspond to the new WSDL, service, port, and operation that are selected.

If the endpoint was changed and no longer matches the endpoint in the WSDL, a Warning button appears next to the field. A tooltip on the button indicates the differences between the entered value and the WSDL definition. Clicking the button updates the field to match the WSDL definition.

If the SOAP Request Message no longer matches the default, it is not updated automatically. You can force the SOAP Request Message to be updated by using the Build Message button next to the Operation field.

Operation

Any of the following options can be used here:

• Build empty SOAP request message.
• Build full SOAP request message.

Port

This field indicates the server port on which the service is available.

On Error

This field indicates what action to be taken when some error occurs during execution.

Endpoint

The URL to the SAML Query API of the Identity Provider.

Build Options

When building sample SOAP messages, various build options are used to determine what to do in various situations.

• Use String Pattern for Value: When selected, it populates element values using DevTest string patterns as opposed to using a hard-coded literal value.
• Default Literal Value: When not using string patterns, use this literal value for all string values.
• Build All Choices: By default, only the first element in an XML schema choice is generated. To build all possible choice elements, select this option.

  Note: The SOAP request is not valid if you include multiple choice elements. However, it provides a sample for each possible choice, which makes it easier to build a message when you do not use the first choice.

• Maximum Elements: Defines the maximum number of elements to include when building the sample message.
• Maximum Type: Defines the maximum number of complex schema types to include when building the sample message.
• Insert Comments: By default, comments that are related to the schema are generated. For example, when an element is optional, alternative choices, nillable elements, are generated. You do not see these comments in the Visual XML Editor, but they are visible in the Raw Editor.