If an ABL application error appears (from error messages, for example) to result from attempts to access a Web service, you generally follow three phases of investigation to isolate the problem.
To investigate a problem related to using a Web service:
1. Determine if the WSDL file is still valid for the Web service you are accessing.
This is particularly necessary if you access the WSDL file at a location other than the URL specified by the Web service provider, for example using a local file system that stores a separate copy that you have made from the original. It is also very possible that the Web service provider has changed the URL or target namespace to reference the WSDL file. If this is the case, you must run the WSDL Analyzer against the new WSDL file to identify any changes that might affect your code. For more information, see Using the WSDL Analyzer.
This is a good first step to diagnose any Web service access failure.
2. If the WSDL file appears to be valid, use a SOAP message viewer at run time to compare the content of SOAP request and response messages with what the application expects and what the WSDL file specifies.
OpenEdge provides a set of SOAP viewers included with the installation, and many other viewers are available. This chapter describes three of them to varying levels of detail.
3. If you suspect a problem with SOAP request and response messages, you can debug sample SOAP messages for selected operations by creating them in local files. Specify the SOAP addresses of these files using Microsoft UNC pathnames in the WSDL Bindings for the selected operations.
4. Debug the ABL code, possibly using the OpenEdge Debugger. For more information on the Debugger, see OpenEdge Development: Debugging and Troubleshooting.
