Creating Web Services and Web Clients in Caché
Troubleshooting Caché SOAP Problems
[Back] [Next]
Go to:

This chapter provides information to help you identify causes of SOAP problems in Caché. It discusses the following topics:

For information on problems that are obviously related to security, see Troubleshooting Security Problems in Securing Caché Web Services.
Information Needed for Troubleshooting
To identify the cause of a SOAP problem, you typically need the following information:
It is also extremely useful to handle faults correctly so that you receive the best possible information. See the chapter SOAP Fault Handling.”
Caché SOAP Log
To log the SOAP calls made to or from a Caché namespace, set the following nodes of the ^ISCSOAP global in that namespace:
Node Purpose
^ISCSOAP("Log") Specifies kind of logging. Use one of the following values (case-sensitive):
  • "i" — Log inbound messages
  • "o" — Log outbound messages
  • "s" — Log security information. Note that this option provides more detail than is generally contained in the SOAP fault, which is intentionally vague to prevent follow-on security attacks.
  • "h" — Headers only (no SOAP body). If you use "h" with "i" and/or "o", then the log includes only the SOAP Envelope element and SOAP headers (if any).
You can also use a string that contains any combination of these values, for example: "iosh"
^ISCSOAP("LogFile") Specifies the complete path and filename of the log file to create.
The log indicates the sender or the recipient as appropriate, so that you can see which web service or client participated in the exchange.
The following shows a partial example of a log file with line breaks added for readability:
01/05/2010 13:27:02 *********************
Output from web client with SOAP action =
<?xml version="1.0" encoding="UTF-8" ?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV='' 
      <Security xmlns="">

01/05/2010 13:27:33 *********************
Input to web client with SOAP action =

ERROR #6059: Unable to open TCP/IP socket to server localhost:8080
Note the following points:
HTTP Trace in the CSP Gateway
The CSP Web Gateway Management page enables you to trace HTTP requests sent to CSP pages (such as web services) and responses sent in return. See Viewing HTTP Trace in the CSP Gateway Configuration Guide.
Third-Party Tracing Tools
To test your web service, you can use tracing tools such as Wireshark, ProxyTrace, tcpTrace, XMLSpy, soapUI, or Web Service Studio Express. Some of these tools are free and others are licensed. Note that InterSystems does not make any specific recommendations about these tools; they are listed here for your general information.
Tracing tools enable you to see the actual method call, as well as the response. A tracing session listens on a certain port, shows you the messages it receives there, forwards those messages to a destination port, shows the responses, and forwards the responses to the listening port.
For example, suppose you have a Cache web service at http://localhost:57772/csp/gsop/GSOP.Divide.CLS
And suppose you have a Cache web client that you created to talk to that service. The web client has a LOCATION parameter equal to "http://localhost:57772/csp/gsop/GSOP.Divide.CLS"
To trace messages between the client and service, you need to do two things:
Now when you use the web client, the tracing tool intercepts and displays messages between the client and the web service, as shown in the following example:
The top area shows the request sent by the client. The bottom area shows the response sent by the web service.
Problems Consuming WSDLs
If you have a problem using the SOAP Wizard (or the %SOAP.WSDL.Reader class, which the wizard uses), the problem is likely to be one of the following:
Problems Sending Messages
If you have problems when sending SOAP messages to or from a Caché web service or client, consider this list of common scenarios: