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 an 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 only ASCII characters. 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.
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 and then 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.
Select the operation to perform during the test from the Operation control. The available operations are determined from the WSDL.
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.
In the Quality of Service section, specify whether you want to explicitly test a Reliable Messaging, WS-Addressing, or a MTOM policy.
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.
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 10-3.
If the test fails, an error message is displayed. For example, Figure 10-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.
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 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 10-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.
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 10-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.
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.)
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).
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.
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.
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.