Release 10.1A: OpenEdge Development:
Web Services

> ## Handling Web service errors

> As with invocation of any 4GL statement, invoking a Web service operation can raise an `ERROR` condition that you can handle in exactly the same way as an other 4GL statement error. The `ERROR` condition from a Web service request can result from one of three basic causes:

> 1. A SOAP fault returned by the Web service.

> 2. A 4GL internal error raised by OpenEdge.

> 3. An error intentionally raised by the 4GL application (using the `RETURN` `ERROR` statement) in one of the following procedures:

> - SOAP request header callback procedure.
> - SOAP response header callback procedure.

> The features of SOAP header callback procedures can add complexity to the error handling for Web service requests. For more information on managing errors for Web service requests, see Chapter 12, " Handling Errors in Progress 4GL Requests to Web Services."

> ##### SOAP fault errors

> For a SOAP fault, you start out by handling the `ERROR` condition as usual in the 4GL, whether it is:

> - Following the invocation of a synchronous Web service request.

> - In the event procedure of an asynchronous Web service request.

> If the Web service returns a SOAP fault from an error detected while processing a Web service request, OpenEdge receives the SOAP fault and turns it into a Progress error message. If the statement that invoked the request includes the `NO-ERROR` option, OpenEdge also attaches the error message to the `ERROR-STATUS` system handle.

> You can identify this error as a SOAP fault by the content of this message (using the `GET-MESSAGE( )` method) and also by examining the object referenced by the `ERROR-OBJECT-DETAIL` attribute on the `ERROR-STATUS` handle. If the error resulted from a SOAP fault, this attribute references a SOAP fault object, which in turn references an optional SOAP fault-detail object, depending on the Web service application.

> If there is no SOAP fault-detail object, you can get all the information available on the SOAP fault from the remaining attributes of the SOAP fault object and the methods of the `ERROR-STATUS` system handle.

> If there is a SOAP fault-detail object, it likely stores more information about the SOAP fault in XML defined by the Web service. You can access this XML in much the same way you access the XML for a SOAP header entry (see the "Handling the information in SOAP headers" section). That is, if the WSDL Analyzer identifies a temp-table or ProDataSet that can represent the SOAP fault-detail object, it provides the temp-table or ProDataSet definition for you to use, if you choose. Otherwise, you can obtain this SOAP fault information as a serialized XML string or as a DOM tree that you must interpret as required using the DOM or SAX tools provided in the Progress 4GL.

> For more information on using the `ERROR-STATUS` system handle, the SOAP fault object handle, and SOAP fault-detail object handle to manage SOAP faults, see Chapter 12, " Handling Errors in Progress 4GL Requests to Web Services."

> ##### 4GL internal errors

> You can handle an internal `ERROR` condition raised for invocation of a 4GL statement as usual by trapping it with the `ON ERROR` option or inspecting the `ERROR-STATUS` system handle directly after invoking the request with the `NO-ERROR` option.

> ##### Errors raised by the application

> Within a SOAP header callback procedure you can invoke the `RETURN` `ERROR` statement as though it were part of the 4GL statement that generated the request so it can be trapped using standard 4GL error handling. However, for an asynchronous Web service request, an unhandled internal error or `RETURN` `ERROR` statement invoked in the SOAP response header callback procedure is propagated from the callback to the event procedure, rather than the point following invocation of the asynchronous request (see the "Managing asynchronous requests" section).

> One reason to invoke `RETURN ERROR` in a SOAP header response callback procedure is to respond to a SOAP header fault. You must determine that there is an error in the header of a SOAP response message by inspecting the header XML. OpenEdge does not otherwise detect a SOAP header fault returned from a Web service.

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095