To open the Advanced settings tabs, click PRO 
. Five new tabs open in the top of the panel, and two new tabs open at the bottom level.
Transport Tab
This parameter controls which HTTP protocol is used when sending the operation request. The default is 1.1.
The SOAP version is auto-populated based on the WSDL definition. SOAP Version controls the generation of a number of transport headers (for example, SOAPAction and contentType).
This parameter defines how to wait while trying to execute the operation. After the timeout is hit, an exception will be thrown and the On Error handling will occur.
SSL Tab
The name of the keystore file where the client identity certificate is stored. The file can be in JKS or PKCS format.
Password for the keystore file.
The keystore attribute that defines the alias that is used to store and retrieve the private key for the server.
An optional password for the key entry if using a JKS keystore, and key has a different password from keystore.
For an example of using multiple SSL certificates, see HTTP_HTML Request Step.
Specify global certificates properties for SSL in your local.properties file.
For global certificates (web server, raw SOAP, and web service steps):
A full path to the keystore.
Password for the keystore (this password is automatically encrypted when DevTest runs).
An optional password for the key entry if you are using the JKS keystore and the key has different password from the keystore. This password is automatically encrypted using AES (Advanced Encryption Standard) when DevTest runs.
Note: This option is not available for the WS Test step. To set this option, use the local.properties file.
For web service steps only certificates (not raw SOAP steps):
A full path to the keystore.
Password for the keystore. This password is automatically encrypted when DevTest runs.
An optional password for the key entry if you are using the JKS keystore and the key has different password from the keystore. This password is automatically encrypted using AES (Advanced Encryption Standard) when DevTest runs.
Note: This option is not available for the WS Test step. To set this option, use the local.properties file.
Note: If you have duplicate values in local.properties and in the general tab, the values in the general tab are used.
UDDI Tab
Select the Inquiry URL and Binding Template. To perform the lookup, use the Search UDDI Server Find 
button to navigate to the correct binding.
Note: When creating the step, if you used the UDDI Search function when specifying the web service WSDL URL, these values are automatically populated. If the Inquiry URL is specified but the Binding Template is not, you could have performed a Model search. To locate the Binding Template, perform a search at a higher level of the hierarchy. Then drill down to the TModel through a specific Binding Template.
WS-I Tab
You can select four different validation levels in the pull-down menu.
Select to validate the WSDL, the SOAP message, or both.
Select the step to redirect to on error.
Note: Validation failures are common, but usually do not affect the outcome of the test. A good practice is to set the next step to continue so that you can complete the test.
Advanced Tab
This field is auto-populated based on the WSDL operation definition. The field is used as the value of the SOAPAction transport header for SOAP 1.1 request message. Change this field manually only in rare cases.
This field is auto-populated based on the WSDL operation definition. The field is used to determine how a sample SOAP message is generated. Change this field manually only in rare cases.
This field is auto-populated based on the WSDL operation definition. The field is used to determine how a sample SOAP message is generated. If Encoded is selected, you can also edit the Encoded URI in the field next to the choice. Change these fields manually only in rare cases.
If a SOAP fault is returned, perform On Error handling.
When selected, the step execution performs all of the normal SOAP message processing, but it does not send the generated SOAP message. Instead it sets the response to be the request message that would have been sent.
This method is recommended to use transports other than HTTP/S to send SOAP requests. For example, when using a JMS client, you can configure the WS step to only create the request and not send it. Then you can append a Generic JMS step to actually send the request and receive the response.
Select to maintain cookies across invocations.
Select to clear cookies across invocations. Clearing the session cookies acts like a new session was created. Old session cookies are not used and any new cookies in the response are not set on the session. However, because the session is not cleared, future steps can still use it.
Request Editor Tabs
Addressing Tab
You can send a WS-Addressing header with your request. The WSDL does not specify if WS-Addressing information is required so you must configure it.
Click the Addressing tab, and then specify:
Click to use WS-Addressing.
Select appropriate version. Several versions of the WS-Addressing specification are listed as options because some web services platforms (for example, .NET) still use the older Draft specifications. Determine which your web service platform is using.
DevTest populates as many values as possible. Then you can select to use the default value or override it. You can select not to send some of the default elements by clearing the Default check box for that element.
To assure that the web service can understand the WSAddressing header, select the Must Understand check box.
Security Tab
Click the Security tab and click Send.
Select to ensure that the server processes the WS-Security header.
Enter the name if needed: most web services do not use multiple Actors/Roles.
Click Add 
and select the security action type to add. You are presented with the configuration panel for that security action type.
Adding the security verification to the Response is similar:
Click the Security tab. Click Add , and select Receive.
and select the security action type. The configuration panel for that security action type opens.
Note: You can add as many security types as are necessary to execute your web service.
When you use a keystore in a security action type configuration, you can verify in the keystore settings that you are using the correct format, password, alias, and alias password. Clicking the Verify button on the editors for Signature, Encryption/Decryption, and SAML Assertion Token invokes the Keystore Verifier, which produces a verification report.
If you do not know the expected alias name for a WS-Security setting, use the Keystore Verifier to list all of the aliases in the keystore. Leave the Keystore Alias and Alias Password boxes empty and click Verify. The Keystore Verifier is described at the end of this section on WS-Security.
Note: You can load and save the security configuration information from and to a .wss file, using the Load 
and Save 
icons. This capability allows for quick and easy creation of new steps connecting to the same service.
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|