Summary

When invoking a Web service from within PRPC using Rule-Connect-SOAP, you might experience two types of SOAP Service Failed exceptions if the request has made it out of PRPC:

• ResourceUnavailableException
• RemoteApplicationException

For each type of exception, you can use the following tools, in the sequence summarized, to debug the SOAP Connection failure:

1. Run the open-source tool, SoapUI.
2. Run the Apache TCPmon tool to monitor traffic on TCP connections.
3. Run the PRPC Tracer. Under General Options, check Local Variables.
4. From the Pega button, click System --> Tools --> Logs --> Log Level Settings to debug the following Logger:
   • Rule_Obj_Activity.InvokeAxis2.Rule_Connect_SOAP.Action
   • com.pega.pegarules.integration.internal.ServiceHelper
   • com.pega.pegarules.integration.internal.util.SOAPUtils

Errors

com.pega.pegarules.pub.services.ResourceUnavailableException: SOAP service failed

com.pega.pegarules.pub.services.RemoteApplicationException: SOAP service failed

Explanation

ResourceUnavailableException

com.pega.pegarules.pub.services.ResourceUnavailableException: SOAP service failed

This error indicates that the service resource did not respond in time, most likely because of a timeout.

Caused by: java.net.SocketTimeoutException: Read timed out

RemoteApplicationException

com.pega.pegarules.pub.services.RemoteApplicationException: SOAP service failed

This exception should include a Caused by: com.pega.apache.axis2.AxisFault: < fault message > in the PegaRules log file. The fault message includes the response message that was received from the Web service call.

Suggested Approach

Follow the procedure for the exception that causes the SOAP service failure.

ResourceUnavailableException

com.pega.pegarules.pub.services.ResourceUnavailableException: SOAP service failed

To prevent this exception, adjust the Service Connection Response Timeout:

In the Connect SOAP form, navigate to the Service tab, then the Connection section, to find the Response Timeout field and adjust the value as needed.

This field specifies, in milliseconds, the time that PRPC will wait for a response from the service.

• If the service will take longer to respond at certain times, you can increase the timeout value.

  For example, the Response Timeout specifies 30000 milliseconds. If you expect heavy load or large requests to slow the service to 60 seconds, you can increase the Response Timeout to 60000 milliseconds.

• If you do not expect the service request to take longer than 30 seconds (or if greater than 30-second periods will be rare), do not change the Response Timeout value.
• If, after increasing the Response Timeout value, you still see a ResourceUnavailableException before the specified timeout period is reached, a response timeout is probably set on the service end.

  For example, you have increased the SOAP Connection Response Timeout to 60000 milliseconds, but you see ResourceUnavailableException before 60 seconds.

  To determine whether a response timeout is set on the service end, use the SoapUI tool to call the service outside of PEGA and see if you get the same timeout.

RemoteApplicationException

com.pega.pegarules.pub.services.RemoteApplicationException: SOAP service failed

To prevent this exception, follow this procedure:

1. Use the SoapUI tool on the same node as the application server that is running PRPC to test the call to this Web service from outside of PRPC.
   • If the service call also fails with SoapUI, this is not a PRPC issue. Investigate what is wrong with the service's WSDL.
   • If the call from SoapUI is successful, capture the request and response envelope to compare it with what PRPC issues.
2. When trying to investigate issues with Connect SOAP rules, it is helpful to turn on debug in the InvokeAxis2 activity to see the SOAP request envelope that PRPC sends out.
3. To get the request and response envelope from when the Connect SOAP call is made from PRPC, run the Tracer, making sure that General Options-Local Variables is checked.

   Alternatively, you can use a tool such as TCPMon to capture the request being sent.

4. Turning on debug in the ServiceHelper and SOAPUtils classes allows you to see how the request/response maps to the Clipboard. Turning on debug in InvokeAxis2 activity allows you to see –
   • How the request envelope is being generated based upon your Connect SOAP rule, and
   • What step in the activity is failing.

At times, even after turning on debug for this activity, you might not see the debug messages being written to the log. If this occurs, do a private checkout of InvokeAxis2; then run the debug.

Additional Information

Tracer - Setting options

Connect SOAP form - Completing the Service tab