+

Search Tips   |   Advanced Search

Troubleshooting WSRP


We can troubleshoot WSRP using different methods such as logging and racing, debugging, and monitoring.


Set traces and using the portal run time log file for WSRP diagnosis

To diagnose problems that might occur during the use of WSRP, we can set WSRP specific traces and enable run time logs for the Consumer, Producer, and administration components of the WSRP implementation. Use the administration portlet Enable Tracing.

We can enable the following trace loggers for the WSRP implementation:

Component Trace string
Administration com.ibm.wps.command.wsrp.*=all
com.ibm.wps.wsrp.cmd.*=allcom.ibm.wps.wsrp.common.*=all
com.ibm.ws.webservices.trace.MessageTrace=all
Consumer com.ibm.wps.wsrp.consumer.*=all
com.ibm.wps.wsrp.common.*=all
com.ibm.ws.webservices.trace.MessageTrace=all
Producer com.ibm.wps.wsrp.producer.*=all
com.ibm.wps.wsrp.common.*=all
com.ibm.ws.webservices.trace.MessageTrace=all
XMLAccess com.ibm.wps.command.xml.*=all
com.ibm.wps.wsrp.common.*=all
com.ibm.ws.webservices.trace.MessageTrace=all


Debugging and monitoring the WSRP protocol flow

We can trace SOAP messages that are exchanged between a WSRP Consumer and a WSRP Producer using a monitor or sniffer application to capture network traffic between the two points. We can use the utility TCPMon that is shipped with the WAS. As an alternative, most AIX or Linux operating systems provide suitable utilities, for example, tcpdump, which can be run on either side and record network traffic captured by a network interface. There are also free tools available.


Parallel portlet rendering with remote portlets

If you encounter errors with parallel portlet rendering of remote portlets in the Consumer portal, try to improve this situation by further increasing the value of the timeout parameter parallelRenderingTimeOut beyond the value of 10000. For details about parallel portlet rendering with remote portlets, refer to the appropriate topic.


Monitoring WSRP messages between the Consumer and Producer using TCPMon

We can use the TCPMon tool to monitor the WSRP messages between the Consumer and Producer, as described in the WebSphere Application Server Information Center topic about Tracing Web services messages. The TCPMon application uses the man-in-the-middle approach. TCPMon listens on a TCP port, logs the HTTP or SOAP traffic, and forwards the request to the designated server and TCP port. Therefore you need to redirect the communication from the Consumer to the TCPMon application and let TCPMon forward the request to the WSRP Producer.

If you already have an Producer configuration on the Consumer portal, we can modify the host and port for each WSRP port URL to monitor. To change the WSRP port URLs that the Consumer uses to communicate with the integrated Producer, we can either use the portal administration user interface or xmlaccess.sh.

Alternatively, to debug a certain scenario, we can also create a new Producer definition on the Consumer with a WSDcontaining WSRP port URLs that point to the TCPMon host und port.

The portal allows us to manipulate the WSDL contents by adding URL parameters to the WSDL URL.

After you have redirected the traffic, configure the TCPMon tool to listen on the port that you have specified on the Consumer side to communicate with the Producer. Also, set the target port to the actual port values of the Producer WSRP interfaces. For the WebSphere Portal Producer, these are the porto that appear in the WSDL file when you request the WSDL without the port parameter.

To run the TCPMonitor tool, follow the instructions given in the WAS information center under Tracing SOAP messages with tcpmon .


Parent: Reference for using WSRP with the portal
Related:

WAS information center

Tracing SOAP messages with tcpmon