How can I process a SOAP Fault element received from a web service?

[VolkerBarth]

Sometimes I send an invalid SOAP request to a web service and receive a HTTP 500 Internal Server Error with an according SOAP Fault element in the SOAP body. Say, it's because I have sent a request with data in a newer XSD version which the older web service does not understand, and the SOAP Fault's faultstring does tell via a validation message which element is unexpected, thereby helping to solve the problem.

Is it possible to receive that SOAP Fault element within a web client procedure?

Currently, I'm using a web client procedure of type 'HTTP:POST:text/xml' so I can usually receive the full response including its headers.

However, when the web service returns a HTTP 500 status, the web client procedure raises a -983 SQLCODE ("HTTP request failed. Status code '500 Internal Server Error'"), and so I cannot access the SOAP response with the SOAP Fault details. Only the web client log (dbsrv12 -zoc) contains the full SOAP response.

I would prefer to be able to return the SOAP Fault message to the client. Is there a way to do so?

[Breck_Carter]

Does the ERRORMSG() contain anything of use, inside an EXCEPTION WHEN OTHERS THEN block?

Or the TRY CATCH ERROR_MESSAGE() call?

[VolkerBarth]

Well, I'm on v12.0.1 here, so TRY/CATCH/ERROR_MESSAGE() are not available.

However, I'm using the ERRORMSG() function within an exception handler, and it just returns the cited error message "HTTP request failed. Status code '500 Internal Server Error'".

According to the docs, that error message for SQLCODE -983 has just one parameter ("HTTP request failed. Status code '%1'), so I guess there's no chance to give more details within the error message itself.

[VolkerBarth · Accepted solution]

With version 17.0.4 - cf. the news - it's now possible to receive a SOAP Fault element when setting the new HTTP option EXCEPTIONS=OFF.

Note that quote from the docs:

When set to OFF, HTTP client functions will always return a response, independent of the HTTP status code. The HTTP status code will not be available.

So the caller is now responsible to check whether the desired result or an exception has been returned by the web client function/procedure.

Thanks for the nice enhancement!

[VolkerBarth · Accepted solution]

Thanks for the nice enhancement!

Particularly as during my tests with v17, I noticed that the syntax for "SET <protocol-option-string>" is checked more strictly (v12.0.1 apparently accepts several such SET clauses, v17.0.4 does not), and my initial "corrections" led to faulty requests, so I surely got those SOAP faults unexpectedly...