11 Testing Web Services
This chapter includes the following sections:
Testing Your Web Services
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 that 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 one typical way to do so.
-
In the navigator pane, expand WebLogic Domain to show the domain in which you want to test a Web service.
-
Select the domain.
-
Using Fusion Middleware Control, click WebLogic Domain drop-down menu, 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 and click Parse WSDL. If you do not know the WSDL, click the search link and select from the registered Web services, if any.
-
The Test Web Service page appears, as shown in Figure 11-1 and Figure 11-2.
Figure 11-1 Top Portion of Test Web Service Page
Description of "Figure 11-1 Top Portion of Test Web Service Page"
Figure 11-2 Bottom Portion of Test Web Service Page
Description of "Figure 11-2 Bottom Portion of Test Web Service Page"
-
Select the operation to perform during the test from the Operation control. 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 and make the change.
-
Select the Request tab if it is not already selected.
-
In the Security section, select the type of security token to verify. The security setting is not determined from a policy in the WSDL; you can specify the type of token you want to test. The default is None. If you do specify a username and password, they must exist and be valid for the WebLogic Server.
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-Addressing, or a MTOM policy.
Note:
This section is not available when testing RESTful Web services.In the default setting of Auto, WS-RM, WS-Addressing, and MTOM policies found in the WSDL are taken into consideration.
-
In the HTTP Transport section, the test mechanism uses the WSDL to determine whether a SOAP action is available to test.
Note:
This section is not available when testing RESTful Web services. -
In the Additional Test Options section, set the Stress Test control if you want to invoke the Web service multiple times simultaneously. If you set this control, you can provide values for the stress test options or accept the defaults.
-
In the Input Arguments section, the parameters and type are determined from the WSDL, and require you to enter values of the correct type.
You can view this section in Tree view or XML view.
-
Click Test Web Service to initiate the test.
-
If the test is successful, the Test Status field indicates passed, and the response time is displayed, as shown in Figure 11-3.
Note:
The results on the Response tab are a simplified version of the standard Web service results. -
If the test fails, an error message is displayed. For example, Figure 11-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.
Editing the Input Arguments as XML Source
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.
Enabling Authentication
You can use the Test Page to test policies that use username tokens to authenticate users.
Note:
Only policies that expect a username and password are supported by the test function, including custom policies. Policies that require certificates or other tokens are not supported.The security setting is not determined from a policy in the WSDL; you can specify the type of token you want to test. The default is None. If you do specify a username and password, they must exist and be valid.
The password must be passed in plain text. Authentication credentials may be supplied in the request by selecting one of the options in the Security section of the page (Figure 11-5). Select one of the following:
-
WSS-Username Token – A WS-Security SOAP header is inserted. Username is required, and password is optional.
-
Http Basic Auth – Username and password credentials are inserted in the HTTP transport header. Both the username and password are required.
-
Custom Policy – A custom policy can be used to authenticate the user. You must specify the URI for the policy. The username and password are optional.
-
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.Figure 11-5 Security Parameters on the Web Services Test Page
Description of "Figure 11-5 Security Parameters on the Web Services Test Page"
Enabling Quality of Service Testing
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 Web Services Test Page (Figure 11-6). For each type of Quality of Service, there are three options:
-
Auto – Execute the default behavior of the WSDL. For example, if Auto 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 11-6 Quality of Service Parameters on Web Services Test Page
Description of "Figure 11-6 Quality of Service Parameters on Web Services Test Page"
Enabling HTTP Transport Options
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 SOAP Action is enabled.
When a request is sent with SOAP Action enabled, then the SOAP action HTTP header is sent.
To change this behavior, clear the 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 text box. (You must already know the SOAP action that you want to test, and the syntax.)
Figure 11-7 HTTP Transport Options on Web Services Test Page
Description of "Figure 11-7 HTTP Transport Options on Web Services Test Page"
Stress Testing the Web Service Operation
Select the Stress Test Enable check box (Figure 11-8) to display the options to create and configure a continuous series of invocations of the Web service operation (Figure 11-8).
-
Number of Concurrent Threads – The number of concurrent threads on which the invocations should be sent. The default is 5 threads.
-
Number of 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 11-8 Stress Testing Parameters on the Test Page
Description of "Figure 11-8 Stress Testing Parameters on the Test Page"
When you invoke the test, a progress box indicates the test status.
When the test completes, a stress report page is returned. The report page identifies the service end point and operation being tested, the size of the message sent, the number of concurrent threads on which it is run, the number of times it is run on each thread, and the delay between each operation invocation.
Disabling the Test Page for a Web Service
Note:
This section does not apply to JEE 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 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 Endpoints page.
-
Click the Configuration tab.
-
In the Test Enabled field, select False from the list.
-
Click Apply.