Client-Side SOAP Debugging

In this section we describe problems you may encounter in a Web service client and ways to fix them. However, we cover only some general troubleshooting issues. You ll need a good understanding of the ATL Server SOAP framework and the HTTP client code to debug more serious SOAP problems.

The first step in writing a Web service client is, usually, getting a proxy file for the Web service. The proxy file is generated by the sproxy tool that comes with ATL Server. You can invoke sproxy from the command line or by selecting the Add Web Reference menu item in Visual Studio .NET.

The result of running the sproxy tool is a header file that contains a class generated especially for the service indicated as parameter for the sproxy tool. You must then include the header in your application and invoke the methods of the proxy class. The code that accomplishes this looks very much like the following:

 #include "TWSService.h"  int SoapInvocation()  {      TWSService::CTWSService svc;      BSTR bstrIn, bstrOut;      bstrIn    =    ::SysAllocString(L"Test");      HRESULT    hr = svc.HelloWorld(bstrIn, &bstrOut);      printf("RetCode %d\n", hr);      if( SUCCEEDED(hr))      {          printf("%ls\n", bstrOut);          return 0;  }      return 1;   } 

Any failure in invoking the Web service will be signaled by the return value from the method of the proxy class. The SOAP infrastructure used in the proxy class will return simply E_FAIL if any problem occurs, and details are provided using a different mechanism that we describe a little bit later. This means that any failure that isn t E_FAIL is related to something other than the SOAP infrastructure, and you should try to figure out what the problem is.

A common non- E_FAIL code returned by a SOAP method is

 hr    0x800401f0 CoInitialize has not been called. 

This error code means that the COM library wasn t initialized . The solution is to call CoInitialize(NULL) (or any of the similar functions: CoInitializeEx , AfxOleInit , and so forth) in the executing thread before the first SOAP call is made.

COM is used in the proxy class to create an instance of ISAXXMLReader , the SAX parser used in handling SOAP payloads. If the user already has a SAX XML reader that isn t using COM, that reader can be passed as a parameter to the constructor of the proxy class and the COM initialization isn t required anymore ( assuming , of course, that the available reader isn t a COM object itself).

After the initialization succeeds, the SOAP infrastructure will signal any error by setting the client error member of the proxy class. You can access this error flag with code such as the following:

 SOAPCLIENT_ERROR    err = svc.GetClientError(); 

The possible values of the SOAPCLIENT_ERROR enumeration are described in the MSDN documentation. A line of code like the preceding will always make a developer s life easier, so it s strongly recommended that you have it in the error-checking code. Chapters 19 and 25 should provide enough details for you to debug the causes of most of the error codes in this enumeration.

In this chapter we discuss only the SOAPCLIENT_PARSE_ERROR flag, which signals an error in the response payload. To be able to debug this kind of problem, you need to see the XML payload returned by the server. You can do this by defining the _ATLSOAP_TRACE_XML constant before including atlsoap.h. That means either in the stdafx.h header or right before including the sproxy-generated header file. You can also do this by setting the compiler command-line flag /D _ATLSOAP_TRACE_XML .

With the newly built application, when a Web service method is invoked, both the request s and the response s XML payloads are going to be traced by the application and can be captured for investigation of the parsing problem.