SOAP webservice: changing status code?

[abo]

Hi.

We're developing a SOAP(ish) webservice in which the other party is asking that we modify the HTTP status code depending on the result of the operation, for example:

• 200: the operation was carried out successfully
• 500: the operation failed, for a number of reasons

As far as my understanding goes, this does not really make sense in the context of SOAP: the conversation happens via XML files and whatever message we have should be sent as a node within that file! In all cases, when the XML text is sent back correctly, the status code will always be 200, regardless of the underlying operation.

However, we managed to force the status code in a rather brutal way: MESSAGE 'some explanation' TYPE 'E' RAISING ZEXCEPTION. Actually, the key step is type E, the exception is ignored.

The outcome, as seen from SoapUI, is the following:

Good: 500 can be set

Bad: "some explanation" is not visible to the caller (perhaps in the SOAMANAGER logs but that's not enough).

I'm afraid I know the answer but.... trying anyway: is it at all possible, within the custom code which carries out the operation, to have an exception or error message of some sort which is then escalated through ICF in a way that is visible to the caller?

[abo]

Thanks, Robert.

In A4H, SRT_UTIL has nothing at all in it, but I use it so rarely that I'm probably using it wrong. Anyway, with RZ10 I set the flag to TRUE in the DEFAULT profile / ext.maint., then saved (got a new version), activated and restarted the container. After checking that it is correctly set, I have tried the SOAP call again but I still only get the 500 status code when I enable the following line in my sample code:

MESSAGE e001(zabo) RAISING zexception.

[Sandra_Rossi]

No idea what SOAP says about functional errors and 500.

What happens if you do this? (and any parameter you want)

RAISE EXCEPTION NEW cx_soap_application( ).

[abo]

No changes, I still get the 500 status with the generic message:

[Former Member]

Hello c5e08e0478aa4727abc4482f5be390b2,

the parameter is dynamic. You can change it in RZ11, no restart is needed.

In SRT_UTIL there is an Error Log button.

goes to

I tested it on S/4HANA FOUNDATION 2021, but there should be no difference.

My test function has just

MESSAGE 'some explanation' TYPE 'E'.

Happy New Year!

Robert

[abo]

You rock, Robert! RZ11 for the win!

And thanks for the SRT_UTIL tip, I found evidence of all the attempts.

Happy New Year to you as well! 🙂

[abo]

Update: after the RZ11 tip below, I am able to see the errors in the logs but the unhandled exception prevents any kind of reply from being sent back by the server. I will have to re-check the usage of exceptions, definitely!

[Sandra_Rossi]

I created a Web service provider via a dummy WSDL with just one fault. When activating it, it creates an exception class <prefix>cx_<fault> for the defined fault <fault>, which inherits from CX_AI_APPLICATION_FAULT. When implementing the Web service, you raise the fault using:

RAISE EXCEPTION NEW <prefix>cx_<fault>( ).

I feel that it should raise a soap-env:fault with all elements from this exception class + http 500. Now I didn't finish the verification.

[abo]

Enterprise services, create, external wsdl/schema: is that right?

In my case, I went for "existing abap object": my colleague had already created the function module and I wanted to test the same scenario.

[Sandra_Rossi]

Yes, it's what I did (SE80 > enterprise services > proxy object > use external key > external WSDL > service provider > ...)

If people don't want to activate the profile parameter is/HTTP/show_detailed_errors = TRUE for some security considerations, instead of using the Web service generated for the RFC-enabled function module, you may reuse the WSDL proposed for this function module (which proposes one generic fault for all exceptions), enrich the WSDL with all the faults you wish, create a Web service from scratch, it will create one exception class per fault, implement the ABAP class, call the function module and raise the faults when desired.