Kbase P81667: How to properly handle errors coming back from a Web Service call made from the 4GL
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
25/05/2004 |
|
Status: Unverified
GOAL:
How to properly handle errors coming back from a Web Service call made from the 4GL
FACT(s) (Environment):
OpenEdge 10.0x
FIX:
If you invoke a Web service operation from the 4GL, you will probably want to include the NO-ERROR option on the invoking statement to capture error information. If the Web service returns a SOAP fault, the ERROR-STATUS handle will have a 4GL SOAP-FAULT object attached to it, and you will need to examine that handle for information about the fault. However, since the effective lifetime of a SOAP-FAULT object lasts only until the end of the next statement
that has the NO-ERROR option, you must process the SOAP-FAULT information without adding NO-ERROR to any statement that is executed before you are done with the SOAP-FAULT. This applies also to any SOAP-FAULT-DETAIL object that may be available through the SOAP-FAULT handle.
As an example, the following statements would raise the errors "Attempt to dereference a stale widget handle (3137)" and "Invalid widget handle. Not initialized or points to a deleted widget (3135)" during the execution of the MESSAGE statement. That happens because the RUN of the local internal procedure includes the NO-ERROR option (and it would happen regardless of the statement to which NO-ERROR was applied -- the problem would show up even if the second NO-ERROR were on the assignment to the hSF variable):
DEFINE VARIABLE hSF AS HANDLE NO-UNDO.
RUN echo IN hPort (INPUT "ABC", OUTPUT cRes) NO-ERROR.
ASSIGN hSF = ERROR-STATUS:ERROR-OBJECT-DETAIL.
RUN SomeLocalInternalProc() NO-ERROR.
IF hSF NE ? THEN
MESSAGE "SOAP-FAULT-CODE: " hSF:SOAP-FAULT-CODE.
Note that this behavior happens because SOAP fault data attached to the ERROR-STATUS handle, like all other data attached to the ERROR-STATUS handle, persists only until the end of the next statement that has the NO-ERROR option on it. The behavior, therefore, is consistent with normal 4GL error handling, but the implications may not be obvious when dealing with SOAP-FAULT objects.