Debugging web services

You can find web service errors in various ways.

To debug your web service, use the following tips to find errors:
  • If you are trying to comply with an outside WSDL, use IBM® Product Master WSDL auto-generation feature to see the WSDL of your web service. Modify the Java™ and WSDD to correct any errors.
  • Use the Java2WSDL followed by Java2WSDL to get a basic WSDD. Compare this WSDD to your current WSDD to find any errors. For more information, see Example of creating a web service that retrieves information from an item.
  • With simple web services, you can view the XML of the web service return message through a URL. For more information, see Examples of implementing and deploying web services.
  • To analyze the XML packets traveling over the wire, use a packet monitoring application, such as TCPMon or Ethereal.
  • Use try..catch blocks in your root web service method. Unless you configure SOAP faults and other error handling information through WSDD, it can be difficult to determine where your exception went within your web service.
To debug a deployed web service and to determine which information you should collect, complete the following steps:
  1. Click Collaboration Manager > Web Services > Web Service Console.
  2. In the Web Service Console, select the web service in question by clicking its name. The Web Service Detail screen shows WSDL information and the Style that is used, which is mostly DOCUMENT_LITERAL on script-based web services and the Implementation Script for the web service. Also, the URL for the web service and the WSDL URL can be found on this screen.
  3. Verify that the check box Deployed at the end of the screen is checked.
  4. Verify the following settings in the common.properties file that is in $TOP/etc/default directory:
    # SOAP username and company.  This can be any valid username and
    # company for which a login is available.  SOAP services will run
    # with the permissions of this company/user combination.

    soap_company=<your company>
    soap_user=<your user running the webservice>

    # This defines the SOAP Envelope Schema URL.
    # By default it points to "http://schemas.xmlsoap.org/soap/envelope/"
    # This can be changed to another URL which hosts the SOAP Envelope schema v 1.1
    #
    soap_envelope_schema_url=http://schemas.xmlsoap.org/soap/envelope/


    # The fully-qualified URL, including port number, of the web site
    # where users should point their browsers to access this
    # instance.  It should NOT include a trailing "/" character.  If this
    # value is kept empty, it will be deduced from the appserver hostname
    # and port.  Do NOT leave this value empty for WebSphere.
    #
    # Example: product_center_url=http://myinstance.trigo.com:1234
    #
    #
    product_center_url=http://stan.munich.de.ibm.com:7505
    1. Copy the web service URL, found at the top of the Web Service Detail screen, into the address bar of your web browser.
      Note: This step tests only to see that the web service can be found and is deployed at that location.
    2. Test the WSDL URL, which can be also found near the top of the Web Service Detail screen, by copying it into the address bar of your web browser.
      Note: This step tests only to see that the WSDL file can be found. If the browser shows the XML file, then also a basic schema check is done which means that the XML file (WSDL File) is a formed XML file. This schema validation works successfully only if no known schema definitions is used.
  5. Certify that the endpoint (location) of the web service shows the same host name and port as defined for the parameter product_center_url.
    Note: The endpoint is the host name of the box where the service is deployed.
  6. The following script should be used from the sandbox of the Product Master that is starting the web service. This is to assess whether the communication is also working from a different computer or if there is for example a firewall that is blocking the communication. Ensure that you adapt the URL to your URL as found for the parameter product_center_url in the common.properties file.
    var sURL = "http://stan.munich.de.ibm.com:7505/services/GDS.WebService";
    var hmRequestProperties = [];
    var hmParameters = [];
    var sRequestMethod = "GET";
    var hmResponse = getFullHTTPResponse(sURL, hmRequestProperties, hmParameters, sRequestMethod);
    forEachLine(hmResponse["RESPONSE_READER"], line){
    out.writeln(line);
    }
    Note: In some cases, the information from the WSDD file might be overwritten. For example, after every new deployment of the product after the install_war.sh script is run, the information that is found in the server-config.wsdd WSDD file at $WAS_HOME/installedApps/<hostname>/<application.ear>/ccd.war/WEB-INF/ is overwritten. If so, then your test in the previous step fails. In this case, the web service just needs to be saved again from the Web Services Console. This re-creates the server-config.xml file and the following XML information is found:
    service name="GDS.WebService" provider="java.TrigoRPC">
    <parameter name="allowedMethods" value="invoke"/>
    </service>
    Where service name is the name of the web service and provider is showing the type of the web service, TrigoRPC is a "complex" web service of type RPC mostly used if Java Objects like Items are used instead of simple script objects like a Primary Key.
  7. Ensure that the log appender for "soap" is set to debug level logging, which is the most verbose and granular logging mode. The log4j2.xml file is found under $TOP/etc/default directory. Debug level logging ensures, that complete stack traces are shown in the $TOP/logs/appsvr_<hostname>/ipm.log file. You can then reproduce the problem again and send the set of log files and all the information from the previous steps to Support for further analysis.