In this scenario, a Web service is deployed but not enabled. At this point:
1. The client sends the following connection request:
Connect_OrderInfo("","","")
2. The WSA gets the request and determines the Web service is disabled. At this point:
a. The WSA sends the client a SOAP response containing a SOAP fault.
b. The log files do not show any error.
The following is the SOAP response containing the SOAP fault:
<?xml version="1.0" encoding="UTF-8" ?>
<soap:Envelope namespaces defined here…>
<soap:Body>
<soap:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>An error was detected … request. (10893)
</faultstring>
<detail>
<FaultDetail xmlns="http://servicehost:8080/wsa/wsa1">
<errorMessage>The urn:www-progress-com:samples:OrderInfo
:OrderInfo service is unavailable (10921)
</errorMessage>
<requestID>2e62cab6b81150d5:-17c6a3c:f1dffbd11b:-8000#1f
</requestID>
</FaultDetail>
</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
3. The interface translates the SOAP fault into a SOAP exception.
4. The client code catches the SOAP exception.
5. The client displays the following error message (assuming the client application has a user interface):
Note: All client applications should always catch SOAP faults and handle them. For client applications without a user interface, all error information must be written to an application log file to ensure it is not lost. If a .NET client does not do this, the .NET Framework's default exception handler displays the SOAP fault general error information. This might well hide and cause the loss of the more useful error detail information in the SOAP fault.
