The Test View page is loaded in your web browser when you build and run a web service or page flow from WebLogic Workshop. You can use Test View to test your component.
If you are testing a page flow, Test View functions like a web browser. You can navigate through all of the pages that make up your page flow and test the functionality of individual pages and the flow of data across pages.
Note that the first time you try to run a JSP page by clicking on the Start button, WebLogic Workshop displays a message saying that the corresponding page flow will be run instead. You can test just an individual JSP page by right-clicking on the JSP page and choosing Run JSP Page.
Test View has four tabs that provide information about a web service:
By default, the Test Form tab is selected when you load Test View by clicking on the Start button.
In addition, each page lists the URL of the web service being tested. Each segment of the URL is a link to the WebLogic Workshop Directory at that level of the application. The WebLogic Workshop Directory is a page that lists the files in each level of the project directory. You may access it directly at any level via the URL http://<server>:<port>/AppName[/folder]/wlwdir.
The Overview tab displays public information about the web service, including:
A link to the WSDL that describes the public contract for the web service. Clients of the web service use the WSDL file to determine how to call the web service and what data will be returned. The WSDL describes both methods and callbacks on the web service.
The callback WSDL for clients that cannot handle the callbacks described in the complete WSDL. Clients wishing to receive callbacks by implementing a callback listening service can communicate with the web service using this WSDL.
The Java source code for a WebLogic Workshop service control for the web service. A developer using WebLogic Workshop who wishes to call your web service from their WebLogic Workshop application can use this source to construct a Service control.
The Java proxy for calling the web service from a Java client. A Java client can call your web service by creating a class from the Java proxy and invoking its methods.
The description of the web service, which lists the web service's methods and callbacks.
Links to useful information such as specifications for WSDL and SOAP.
Note: To learn how the comments associated with each method are obtained, and how you can document your web service's methods, see Documenting Web Services.
The Console tab displays private information about your service, including:
How the service is implemented on the back end, and the version of WebLogic Workshop with which it was created. For example, web services built using WebLogic Workshop are implemented using Enterprise JavaBeans; they may also use other J2EE components.
Links to the WebLogic Server console application.
Settings for the message log on the Test Form tab.
Persistence settings, for clearing the conversational state and logs for the service, and for redeploying the Enterprise JavaBeans underlying the service.
The Test Form tab provides a simple test environment for the public methods of the web service. You can provide parameters for a method and examine its return value. You can also track and test the different parts of a conversation.
Note: The Test Form tab may only be used for web services (or methods of web services) that support HTTP-GET. Web service methods that do not support GET or that receive raw XML messages must be exercises via the Test XML tab.
The following image shows how the Test Form tab appears for a service called HelloWorldAsync, which demonstrates a simple conversation:
To test the service, click the HelloAsync button. If this method took parameters, you would enter values for them here.
The Test Form page displays information about the service request and response, including the XML message that was returned, as shown in the following image:
If the web service implements conversations, as the HelloWorldAsync service does, you can use Test View to test the methods that start, continue, or finish a conversation and the callbacks that continue or finish a conversation. You can also test multiple conversations at once.
The conversation ID that appears in the message log uniquely identifies each conversation that is underway. Click on this value to select and work with this conversation. You can view the results for each method or callback that has participated in this conversation by clicking on its name in the list. Click the Refresh link to refresh the message log.
The following image shows Test View with multiple conversations underway:
Note: To learn how the comments associated with each method are obtained, and how you can document your web service's methods, see Documenting Web Services.
The Test XML tab shows the XML data that is being sent to your service when you test its methods. You can use this page to examine and modify the XML data that is passed to a method of your service.
If your method takes parameters of a data type other than String, you must modify the parameter placeholders in the SOAP body before you click the button to call the method. For example, if your method expects an integer, you must supply a valid integer in the SOAP body.
The following image shows the Test XML tab for a service called SimpleCalc, which performs simple arithmetic calculations:
The WebLogic Workshop Directory contains a sortable list of the files that comprise the different levels of the Project directory. You can use this page to select another service to test, test a control file, and clean up the service.
There are two ways to navigate to the service directory:
Click on any of the links that make up the service address listed on the upper right-hand corner of the Test View pages. Each part of the path is a link to the directory listing of the files stored in this part of the project directory.
Click on the See other services in your project link in the upper right-hand corner of the Overview page.
You can use the WebLogic Workshop Directory to:
See the complete list of files and folders stored at this level.
Use filters to show files of a particular type such as JWS, Control, XML, ECMAScript, and WSDL files.
Click on a JWS file name and test it.
Click on a JCX file, see information about this file, and choose to generate a Test JWS for testing the JCX.
Use the Clean All command to delete all generated .java, .class, and directories; erase cached dependency graph information, get rid of all conversation instances, undeploy all beans, and clear logs while leaving your application sources intact.
If your control exposes callbacks, you need to take extra steps for testing.
The test interface can receive the request, but it cannot respond to it because it does not implement the callback interface set by the service. If the service is invoked from the test interface, the callback request is never sent. Because the request is never sent, the handlers are never invoked.
If the service with the callback handlers is invoked via a service control, then the callback handlers get invoked. So, to test callbacks, the callback handlers must be tested from a client that implements the callback interface. To do this you might create callbacks within the test JWS, then call these from your control's callback handlers.