This topic explains how to create JMS, XPath, SOAP Header, and Database , properties that can be shared and referenced globally, as well as global authentications, key stores, tools, and WS-policy banks. In this section:
Table of Contents | ||
---|---|---|
|
...
Select the desired suite and click the Add Property button.
- In the Add Global wizard, choose Global Property> Database Account and click Finish. A Properties node displays and the Database Account panel displays in the right side of the GUI.
- Specify the settings in the Database Account panel as follows:
- If you want to change the default name, enter the new name in the Name field.
Click the Add Property to All button (if you don’t click this button, the global properties you add will be ignored by the tools in the suite). Depending on what you select from the drop-down list, one of the following will occur:
If Use Shared Property Only is selected from the drop-down list, the corresponding tools in the suite will be able to only use the global property you added.
If Use Local and Shared Properties is selected from the drop-down list, the corresponding tools in the Action suite will be able to use the global property you added and any properties configured within the individual tool itself.
- Configure the rest of the Database Account settings as needed.
- If the account settings are stored in a file, select File then specify the path to that file.
- To refresh/reload the file (e.g., if you edited it externally), click Refresh Configuration Settings.
If you want to specify the settings in this panel, enable Local and specify the driver settings. See
Database Configuration Parameters in SOAtest or Database Configuration Parameters in Virtualize for additional information
To export these values to a file, click Export Configuration Settings. Once the values are exported to a file, you can import the file through the File> Input File control (described above). This way, you won’t have to re-type the same values if you want to add this same account to a different suite.
Note that exported properties files contain the following properties:
- driver
- url
- username
- password
- close.connection
For example:
version=1
driver=org.hsqldb.jdbcDriver
url=jdbc:hsqldb:hsql://localhost/parabank username=sa
password=dGVzdA==
close.connection=true
- If the account settings are stored in a file, select File then specify the path to that file.
Global Authentications
You can add authentication methods to your test suite so they can be shared among your tests without needing to define authentication settings for each test. A default authentication method can be set for the test suite that will be automatically applied to every test, though individual tests can be configured to use alternative authentication methods, as needed. Multiple authentication methods can be created for the test suite, but only one can be set as the default.
To add a shared authentication method:
- Right-click on a test suite and choose Add New > Global Property...
- Expand the Authentication list, then choose an authentication method and click Finish.
The authentication method is added to the test suite's Authentications node. If this is the first shared authentication created for this test suite, the Authentications node is created automatically. - A configuration tab opens in the workspace. How you complete the configuration depends on which authentication method you selected:
- Basic
- Enter an easily identifiable name in the Name field.
- Enter the Username and Password to be used for this authentication.
- Digest
- Enter an easily identifiable name in the Name field.
- Enter the Username and Password to be used for this authentication.
- Kerberos
- Enter an easily identifiable name in the Name field.
- Enter the Service Principal to be used to authenticate.
- For more information about Kerberos authentication, see "Security Settings" on the Additional Preference Settings page.
- NTLM
- Enter an easily identifiable name in the Name field.
- Enter the Username and Password to be used for this authentication.
- OAuth 1.0
- Enter an easily identifiable name in the Name field.
- Enter the Customer Key and Customer Secret to be used for this authentication.
- Select the authentication mode from the Mode dropdown. The other fields you will need to complete depend on your selection:
- Obtain Request Token (requests the Request Token from the server using the Consumer Key and Secret)
- Scope: Restricts what information may be accessed. This information in embedded into the Consumer Key.
- Exchange Request Token for Access Token (exchanges the Request Token plus the verification code for the Access Token)
- Request Token: Specifies Temporary Request Token credentials obtained from the server (used to exchange for the Access Token).
- Request Token Secret: Specifies Temporary Request Token credentials obtained from the server (used to exchange for the Access Token).
- Verification Code: Specifies the verification code provided by the server; this confirms that the resource owner will grant permission.
- Sign Request for OAuth Authentication (uses the specified Access Token and Access Token Secret to give the client access to the user's private resources)
- Access Token: Specifies the Access Token used to give the client access to the user's private resources.
- Access Token Secret: Specifies the Access Token Secret used to give the client access to the user's private resources.
- Obtain Request Token (requests the Request Token from the server using the Consumer Key and Secret)
Add any additional OAuth parameters (for example, the timestamp and nonce) under Parameters.
For more information about using OAuth 1.0 in functional tests, see OAuth Authentication.
- Basic
Global Key Stores
Anchor | ||||
---|---|---|---|---|
|
...