Previous Next vertical dots separating previous/next from contents/index/pdf

Testing Web Services with the Test Client

As you develop a web service, you can typically test it directly by using the Test Client. In some cases, you will need to test indirectly by creating a separate web service that acts as a client for testing.

Testing Web Services with the Test Client

The Test Client provides a user interface through which you can test web service operations with parameter values you choose. With the Test Client you can:

Note: You can also launch the Test Client without using the IDE.

For an example of using the Test Client, see Web Service Tutorial: Step 4: Test the Web Service.

Test Client User Interface

Basic Testing Steps

When you test web services with Workshop for WebLogic, you follow simple steps that launch the Test Client with a visual interface for invoking the web service's operations. Briefly, these steps are:

  1. Start WebLogic Server.
  2. Expand the project tree to display the web service source file.
  3. Right-click the source file, then click Run As -> Run on Server.
  4. When the Test Client is displayed, choose the operation you want to test.
  5. If the operation has parameters, enter test values in the boxes provided.
  6. Click the button labeled with the operation's name.
  7. Examine the result of the test.
  8. Use the Message Log list to view the results of multiple tests.
  9. If the web service is designed to receive a callback, click the callback's name in the Message Log list to view callback values. (You might need to refresh the Test Client if the callback is not designed to execute right away.)
  10. Click Show Operations to begin another test.

Choosing Operations to Test

When the Test Client is displayed, you choose an operation to test by clicking the button labeled with the operation's name. If the operation has parameters, the Test Client provides boxes for you to enter the values to test with.

Complex Types as Parameters

When an operation includes complex types as parameters, the Test Client will display an XML template with placeholders for your test values. For example, the following illustration shows a template in which "Gladys Kravitz" has been entered for one String placeholder and the other placeholder is about to be replaced with a test value.

Navigating Conversational Web Service Tests

The Test Client provides special links through which you can test conversational web services.

When testing a conversational web service, the Test Client will only display the operations that are valid in the current phase of the conversation. In other words, when you begin testing, only START methods show. The Test Client provides the following buttons for navigating conversations:

Note that the message log groups the operations invoked according to the conversation in which they were tested with each message shown chronologically within the conversation.

Examining Message Contents

When you execute an operation, the Test Client refreshes to display information about the message exchanged by the operation. The user interface provides a summary of message values as well as the message XML itself. This information is provided for both operation messages and callback messages. When an exception occurs, a fault message is displayed.

Notice that in the message XML, all but the most important parts of the message payload are displayed in grey.

Operation Messages

After you have executed a web service operation, the Test Client displays information about messages related to the operation. The request summary provides a shorthand version of the message's contents. It gives parameter and return values (if any), along with time stamp information.

Each test of a web service operation will have its own entry in the Message Log list. In this way you can compare tests that use different values.

Beneath the request summary the message XML is displayed, as shown in the following image. Messages for both the operation's request and its return value are displayed.

Callback Messages

If your web service sends a callback, you can view the results of the callback's execution by clicking its name in the Message Log list. Note that because the callback log entry won't show up until after the callback executes, you might need to refresh the Test Client after an interval to get the entry (you can click the Refresh button at the top of the message log).

As with operation messages, the Test Client displays callback message data as a summary as well as the message XML. The callback request message will describe the data sent to your web service by the callback.

Exception Messages

When testing the web service generates a fault or exception, the Test Client displays the resulting message. Note in the following summary example that a fault has been noted. Here, a String was provided for the operation's argument rather than an int.

The message XML below is also displayed.

Viewing the WSDL File

You can view the WSDL file for the web service you're testing by clicking the WSDL URL provided at the top of the Test Client window.

WSDL link

Choosing Another Web Service to Test

You can test another web service without closing the Test Client by clicking the Choose Another WSDL link at the top of the Test Client window. The Test Client will display a page with a box where you enter the WSDL URL, then click Test to display the test form for that web service.

Launching the Test Client Without the IDE

You can use the Test Client outside the IDE by launching the client through a web browser.

  1. With the server running, open a browser window and navigate to the following URL to start the Test Client:
  2. http://localhost:7001/wls_utc

  3. In the Enter WSDL URL box, enter the URL for the WSDL of the web service you want to test, then click Test.

Setting Up a Web Service Client for Indirect Testing

Some web services can not be tested standalone with the Test Client. In these cases, you will need to create a separate web service to act as a client of the main web service for the purpose of testing. You will need to test in this "indirect" way if the web service you want to test:

You can test it by setting up a service control and a client web service for that control. The following gives the basic steps for setting up a service control and control client. Note that you do not need to create a separate web service client for every testing scenario.

  1. To create a new web service project, select File > New > Project > Web Services > Web Service Project. You should create all of your client-related classes in a different project than the target web services.
  2. To generate a WSDL file, on the Package Explorer tab, right-click the target web service file and select Web Services > Generate WSDL. When the WSDL file has been generated, drag and drop it into the new web service project. The WSDL should be dropped into an appropriate package under the src directory.
  3. To generate a web service control, right-click the WSDL file and select Web Services > Generate Service Control.
  4. To generate a client web service, select File > New > WebLogic Web Service. Complete the New Web Service dialog to create a web service class.
  5. Add the web service control to the client by right-clicking anywhere in the source view of the client class and selecting Insert > Control. Select the service control generated above.
  6. Add any event handler to the client by right-clicking anywhere in the source view of the client class and selecting Insert > Control Event Handler. Select the desired event methods from the service control.
  7. Finally add methods to the client that invoke methods on the service control.
  8. Run the client by right-clicking it in the Package Explorer and selecting Run As > Run on Server. By default, web services are shown in Test Client.

Debugging Transactional and Conversational Web Services

When debugging a transactional web service, you should consider increasing the transaction timeout period in order to compensate for delays caused by the debugger. The default timeout is 30 seconds, which may be too short in some debugging situations, especially when the web service is conversational.

To increase the timeout period, use the timeout attribute on the @weblogic.jws.Transactional annotation:

    @Transactional(value=true, timeout=600) // Increase the timeout period to 600 seconds/10 minutes.
    public class TransactionalService implements Serializable {

Related Topics

Service Control


Skip navigation bar   Back to Top