In the Security section, select the security token to verify. The security setting is

Testing Web Services 12-5 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. Figure 12–4 Data Validation Error 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 Web Service Page to test policies that use username tokens to authenticate users. 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 12–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: The results on the Response tab are a simplified version of the standard Web service results. 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. You cannot use this page to test a Web service with a message protection policy. Note: When testing RESTful Web services, because the SOAP protocol is not used, the only security options are HTTP Basic Authentication or None. 12-6 Oracle Fusion Middleware Security and Administrators Guide for Web Services Figure 12–5 Security Parameters on the Web Services Test Page Enabling Quality of Service Testing 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–6 . 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–6 Quality of Service Parameters on the Test Web Service Page Enabling HTTP Transport Options 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. Note: This section is not applicable when testing RESTful Web services. Note: This section is not applicable when testing RESTful Web services.