This chapter includes the following sections:
This section describes how to use the Fusion Middleware Control Test Web Service page to verify that you are receiving the expected results from the Web service.
The Test Web Service page allows you to test any of the operations exposed by a Web service. You can test Web services that are deployed on any accessible host; the Web service does not have to be deployed on this host.
Note:
The Test Web Service page can parse WSDL URLs that contain ASCII characters only. If the URL contains non-ASCII characters, the parse operation fails. To test a Web service that has non-ASCII characters in the URL, allow your browser to convert the WSDL URL and use the resulting encoded WSDL URL in the Test Web Service page.
When testing Web services that use policies, the Oracle WSM component must be installed in the same domain from which Fusion Middleware Control is being run. Otherwise, an invalid policy exception will be returned.
You can navigate to the Test Web Service page in many ways. This section describes two typical ways to do so.
Access the Test Web Service page using either of these typical ways to do so.
From the Oracle WebLogic Server Domain Home page:
In the navigator pane, expand WebLogic Domain to show the domain in which you want to test a Web service.
Select the domain.
From the WebLogic Domain menu, select Web Services, and then Test Web Service. The Test Web Service input page appears.
Enter the WSDL of the Web service you want to test. If you do not know the WSDL, click the search icon and select from the registered Web services, if any.
Click Parse WSDL.
If the WSDL is secured with HTTP Basic Authentication, click HTTP Basic Auth Option for WSDL Access and enter the username and password before parsing the WSDL.
The complete Test Web Services page displays, as shown in Figure 12-1.
From the Web Service Application Home page:
In the navigator pane, expand Application Deployments to view the applications in the domain.
Select the application for which you want to test the Web service.
In the Web Services section of the page, click Test for the Web service endpoint you want to test.
The Test Web Service page displays, as shown in Figure 12-1. Note that the WSDL field is automatically populated with the WSDL for the endpoint.
Click Parse WSDL.
If the WSDL is secured with HTTP Basic Authentication, click HTTP Basic Auth Option for WSDL Access and enter the username and password before parsing the WSDL.
The Test Web Service page is shown in Figure 12-1. Note that the test option sections are collapsed by default.
Figure 12-1 Test Web Service Page in Collapsed View
Select the service and port to be tested. If the WSDL has multiple services and ports, these fields are available as drop-down menus. If the WSDL has only one service and port, these fields are read-only, as shown in Figure 12-1.
Select the operation that you want to test from the Operation menu. The available operations are determined from the WSDL.
To test a RESTful Web service, select the GET or POST service port operations.
If you want to change the endpoint URL of the test, click Edit Endpoint URL and make the change.
Select the Request tab if it is not already selected.
Expand the test option sections by clicking the plus sign (+) next to the section name. The expanded view of the Test Web Service page is shown in Figure 12-2.
Figure 12-2 Bottom Portion of Test Web Service Page in Expanded View
In the Security section, specify whether you want to test a Web service using Oracle WSM security policies, basic HTTP authentication, authentication from a custom policy, or no credentials. The security setting is not determined from a policy in the WSDL; you can specify the type of security you want to test. The default is None. Depending on the option selected, additional fields are displayed. For details about the options available, see "Enabling Security Testing".
When testing RESTful Web services, because the SOAP protocol is not used, the only security options are HTTP Basic Authentication or None.
In the Quality of Service section, specify whether you want to explicitly test a Reliable Messaging (WS-RM), WS-Addressing, or MTOM policy. For details about the options available, see "Enabling Quality of Service Testing".
Note:
This section is not available when testing RESTful Web services.
In the HTTP Transport section, the test mechanism uses the WSDL to determine whether a SOAP action is available to test. If available, specify whether you want send the request with the SOAP action HTTP header. For more information, see "Enabling HTTP Transport Options".
Note:
This section is not available when testing RESTful Web services.
In the Additional Test Options section, select the Enable Stress Test option if you want to invoke the Web service multiple times simultaneously. If you select this option, you can also provide values for the stress test options, or accept the defaults. For more information, see "Stress Testing the Web Service Operation".
In the Input Arguments section, enter the input arguments for the Web service in the Value fields. The parameters and type, and the required input values, are determined from the WSDL.
Select Tree View or XML View to toggle between a hierarchical list of input parameters and the XML content.
Click Test Web Service to initiate the test.
The test results appear in the Response tab upon completion.
If the test is successful, the Test Status field indicates Request Successfully received and the response time is displayed, as shown in Figure 12-3.
Note:
When running SOA composite tests, the Response tab will indicate whether a new composite was generated. You can also click the Launch Flow Trace button to open the Flow Trace window, where you can view the flow of the message through various composite and component instances.
If the test fails, an error message is displayed. For example, Figure 12-4 shows an error resulting from a type error in the var-Int parameter. In this particular instance, string data was entered when an int was expected.
Note:
The results on the Response tab are a simplified version of the standard Web service results.
You can view the input arguments in a user-friendly form, or you can edit the XML source code directly. If you edit the XML source directly, you must enter valid XML. Use the drop-down list in the Input Arguments section of the page to toggle between Tree View and XML View.
You can use the Test Web Service Page to test Web services security using Oracle WSM security policies, HTTP basic authentication, or custom policies. You can choose the type of test by selecting one of the options in the Security section of the page.
The security setting is not determined from a policy in the WSDL; you can specify the type of security you want to test. The default is None.
The following options available, and described in more detail in the subsequent sections:
OWSM Security Policies– Uses the credentials and other security options required by the Oracle WSM security policies for authentication and message protection.
HTTP Basic Auth – Inserts the username and password credentials in the HTTP transport header. Both the username and password are required.
If you do specify a username and password, they must exist and be valid.)
Advanced – Uses a custom policy to authenticate the user. You must specify the URI for the policy. You can also specify configuration overrides.
None – No credentials are included.
Note:
When testing RESTful Web services, because the SOAP protocol is not used, the only security options are HTTP Basic Authentication or None.
The options available when you select OWSM Security Policies, are shown in Figure 12-5. Note that in this figure the Advanced Options field is selected to display all of the available fields.
Figure 12-5 OWSM Security Policies Test Options
To test the Web service security using Oracle WSM security policies:
From the Compatible Client Policies list, which displays the compatible client policies as specified in the WSDL, select the client policy to test.
Alternatively, to perform a negative test on the endpoint, you can select a non-compatible policy, or All from the Other Client Policies list.
Notes:
Non-security policies and policies not supported by the test function are shown as read-only and cannot be selected. For a list of client policies supported by the test function, see "Supported Client Security Policies".
Service polices that support multiple client security policies are not supported by the test function.
The Configuration Properties required by the selected policy are indicated with an asterisk (*). For example:
For username_token and http_token policies, the Username and Password fields are required; for SAML policies only the Username field is required.
For message protection and two-way SSL policies, the JKS Keystore Location and JKS Keystore Password fields are required. (These fields are not required to be set for one-way SSL policies.)
Provide values for the required fields as determined by the policy.
If the JKS Keystore Location and JKS Keystore Password fields are required by the policy, enter the location and password of a temporary user-created keystore that is NFS accessible and click Load Keys. The associated keystore fields under Advanced Options are populated with the aliases specified in the keystore.
For more information about creating a keystore, see "Generating Private Keys and Creating the Java Keystore".
Click Advanced Options. Additional keystore alias and SAML properties fields are displayed. Properties required by the selected policies are indicated with an asterisk. Enter the required values, or provide override values in the applicable fields.
This option requires Username and Password credentials that are inserted into the HTTP transport header. The username and password must exist and be valid for the WebLogic Server.
The options available when you select the Advanced option are shown in Figure 12-6.
The Advanced option allows you to use a custom policy to test the Web service security. To do so:
Specify the URI of the custom policy in the Policy URI field. This field is required.
Specify any configuration overrides for the policy in the Name and Value fields. To add properties, click Add and provide the name/value pair for the configuration override. To delete a property, select it in the table and click Delete.
Note:
Properties must be specified using the full name of each property, for example oracle.wsm.security.util.SecurityConstants.ClientConstants.WSS_KEYSTORE_LOCATION
. For a complete list of property names for overridable properties, see Table 11-2 in "Using Client Programmatic Configuration Overrides".
The following Oracle WSM client security policies are supported by the test function:
oracle/wss_http_token_client_policy
oracle/wss_http_token_over_ssl_client_policy
oracle/wss_saml_token_bearer_over_ssl_client_policy
oracle/wss_saml_token_over_ssl_client_policy
oracle/wss_saml20_token_bearer_over_ssl_client_policy
oracle/wss_saml20_token_over_ssl_client_policy
oracle/wss_username_token_client_policy
oracle/wss_username_token_over_ssl_client_policy
oracle/wss10_message_protection_client_policy
oracle/wss10_saml_token_with_message_integrity_client_policy
oracle/wss10_saml_token_with_message_protection_client_policy
oracle/wss10_saml_token_with_message_protection_ski_basic256_client_policy
oracle/wss10_saml20_token_with_message_protection_client_policy
oracle/wss10_username_id_propagation_with_msg_protection_client_policy
oracle/wss10_username_token_with_message_protection_client_policy
oracle/wss10_username_token_with_message_protection_ski_basic256_client_policy
oracle/wss10_x509_token_with_message_protection_client_policy
oracle/wss11_message_protection_client_policy
oracle/wss11_saml_token_identity_switch_with_message_protection_client_policy
oracle/wss11_saml_token_with_message_protection_client_policy
oracle/wss11_saml20_token_with_message_protection_client_policy
oracle/wss11_username_token_with_message_protection_client_policy
oracle/wss11_x509_token_with_message_protection_client_policy
Note:
This section is not applicable when testing RESTful Web services.
Three characteristics of Quality of Service (QoS) can be tested: reliable messaging (WS-RM), WS-Addressing, and Message Transmission Optimization Mechanism (MTOM) in the Quality of Service section of the Test Web Service Page (Figure 12-7). For each type of Quality of Service, there are three options:
WSDL Default – Execute the default behavior of the WSDL. For example, if WSDL Default is selected for MTOM, and the WSDL contains a reference to an MTOM policy, the policy is enforced. If the WSDL does not contain a reference to an MTOM policy, then no MTOM policy is enforced.
None – No policy for the specific QoS, even if it is included in the WSDL, is executed. For example, if None is selected for WS-RM, no reliable messaging policy is enforced. If the WSDL contains a reference to a reliable messaging policy, it is ignored.
Custom – Enforce a custom policy. For example, if a WS-Addressing policy is referenced in the WSDL, this policy will be ignored, and the policy specified in URI will be used instead.
URI – Specify the location of the policy to be enforced.
Figure 12-7 Quality of Service Parameters on the Test Web Service Page
Note:
This section is not applicable when testing RESTful Web services.
The test mechanism uses the WSDL to determine whether a SOAP action is available to test. If the WSDL soap:operation has a soapAction attribute, then this is displayed and Enable SOAP Action is enabled.
When a request is sent with Enable SOAP Action enabled, then the SOAP action HTTP header is sent.
To change this behavior, clear the Enable SOAP Action box, in which case the HTTP header is not sent. Or, you can override the behavior by providing a different value in the SOAP Action field. (You must already know the SOAP action that you want to test, and the syntax.)
Figure 12-8 HTTP Transport Options on the Test Web Service Page
Select the Enable Stress Test check box (Figure 12-9) to invoke a continuous series of invocations of the Web service operation (Figure 12-9). The following options are available:
Concurrent Threads – The number of concurrent threads on which the invocations should be sent. The default is 5 threads.
Loops per Thread – The number of times to invoke the operation. The default is 10 times.
Delay in Milliseconds – The number of milliseconds to wait between operation invocations. The default is 1000 milliseconds (1 second).
Figure 12-9 Stress Testing Parameters on the Test Web Service Page
When you invoke the test, a progress box indicates the test status. When the stress test is complete, a confirmation page displays the results of the test.
The Response tab provides additional information about the stress test, including the number of tests with errors, and the average, minimum, and maximum response times. Details about each test are provided in tabular form. For each test, you can view the thread and loop numbers, the duration of the test, the start and end times for the test, and the invocation status. You can filter the fields displayed in the table using the View menu.
Figure 12-10 Stress Test Results on Test Web Service Page
Note:
This section does not apply to Java EE Web services.
Disabling the test page for a Web service allows you to increase security by reducing the externally visible details of an application that exposes Web services.
Note:
Disabling the Endpoint Test Enabled control affects only the Web service's externally-visible test page. It does not affect the Web service test feature described in this chapter.
To disable the Test Page using Fusion Middleware Control
Navigate to the Web Services summary page, as described in "Navigating to the Web Services Summary Page for an Application".
In the Web Service Details section of the page, click on the plus (+) for the Web service to display the Web service ports if they are not already displayed.
Click the name of the port to navigate to the Web Service Endpoint page.
Click the Configuration tab.
In the Endpoint Test Enabled field, select False from the list.
Click Apply.