Outbound Proxy - only system error (cx_ai_system_fault thrown) on Soap Fault

[JaySchwendemann]

Hi all,

I have a ERP (outbound proxy) --> PI --> 3rd party webservice scenario.

The 3rd party sends a soap fault back if something went wrong (e.g. not found, wrong parameters, etc)

The soap fault looks like this and the HTTP code sent is 200

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Body>
      <soap:Fault>
         <faultcode>soap:Server</faultcode>
         <faultstring>1002: SearchFor or LastId Invalid</faultstring>
         <detail>Cause: The SearchFor or LastId parameter was not recognised.
Resolution:Check the documentation for valid options.</detail>
      </soap:Fault>
   </soap:Body>
</soap:Envelope>

Problem is that cx_ai_system_fault does not give back a meaningful error. Only "PARSING.GENERAL" and I have to look to SXMB_MONI to get the real reason.

Any ideas how to overcome?

Thx

Jens

[engswee · Accepted solution]

Hi Jens

Did you define a fault message type for both the outbound proxy service interface and the inbound soap service interface? And link them both via a fault mapping in the operation mapping?

In my experience, when I want to catch the HTTP fault of a web service, I will do the above.

With the additional fault message type on the outbound SI, when generating the proxy, there will be an additional exception class. In the ABAP code, catch this exception to get the fault text instead of the system fault.

See below an example of an outbound proxy -> PI -> web service interface where the fault message is returned to the proxy.

Rgds

Eng Swee

[JaySchwendemann · Accepted solution]

Thanks Eng Swee,

I think my problem might be related to 2 things

1.) The 3rd party web service provides a WSDL without a fault message (https://services.postcodeanywhere.co.uk/CapturePlus/Interactive/Find/v2.10/wsdl.ws) . However, they send a standard soap fault message on error as shown in the original post. So far that seems indeed comply to the soap fault standard.

2.) They send (as far as I can see) HTTP 200, even on fault. However, I tried with a soupUI mockup service which sends HTTP 500 but with the same behavior.

To overcome 1.) I imported the W3C soap xsd (http://schemas.xmlsoap.org/soap/envelope/) as an external definition (type XSD) and refenced the "Fault" message within my inbound synchronous interface. However, this doesn't seem to do the trick

I don't know if 2.) is anything of an interest or if 200 or 500 should both be ok to catch application faults.

I also read about some people activating "do not use soap envelope" but this seems like a big backdraw, as normal response works fine

Many thanks

Cheers

Jens

[engswee · Accepted solution]

Hi Jens

If I am not mistaken, I think that a HTTP 200 response (even with a soap fault body) will not trigger the fault response path, and therefore does not go through any configured fault mapping. I will need to double check on this.

If that is the case, if you cannot get the web service provider to change the behaviour, I think you need to handle both normal response and soap fault response in the same response mapping. As the normal response and fault response have different root element, you might (or maybe not?) need a Java mapping to handle the different root element in the same mapping. You can map the soap fault text field to a new ErrorMessage field defined on your sender proxy interface. In this case, the ABAP logic checks the ErrorMessage field in the response structure to determine application errors such as this.

Rgds

Eng Swee

[iaki_vila · Accepted solution]

Hi all,

Great point Eng, I didn't know about the HTTP 200 and not to trigger the response path, i always have had this doubt because in some scenarios worked and in others not.

About the Do Not Use SOAP envelope trick, i usually developed it and my first response mapping i extract the SOAP payload a take the SOAP fault in a desired response tag, go ahead with this solution.

Regards.

[engswee · Accepted solution]

Hi Jens

Did you manage to resolve your issue?

There was another recent thread around sync soap faults. In one of the reply, it referenced note 856597 regarding the HTTP status.

Re: How to catch custom exception in sync interface

Here's a snippet from that note. From it, it looks like if your service is returning HTTP 200, the SOAP adapter just treats it as a normal response even though the content contains the SOAP fault details.

For synchrnous calls, a successful response should be returned with HTTP 200. In this case, the content of the SOAP body will be returned to the caller as the response payload.

Rgds

Eng Swee

[JaySchwendemann · Accepted solution]

Hi Eng / Iñaki / all,

ok, after fiddling around with this for some more time I think I had some fundamental misunderstanding how error handling / soap faults worked.

I though that if HTTP Status was 500 all nodes within <soap:Body> would be taken as payload for a fault message.

However, it seems to turn out that only stuff within the <detail> node of standard soap fault is actually taken into account and only then a application fault is thrown.

Example Soap Fault

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns0="urn:ec.europa.eu:taxud:vies:services:checkVat:types">
   <soapenv:Body>
      <soapenv:Fault>
         <faultcode>episode3</faultcode>
         <faultstring>nooooooooooooo</faultstring>
         <faultactor>darth.vader.com</faultactor>
         <detail>
            <ns0:checkVatFault>
               <ns0:error>Padme died!</ns0:error>
            </ns0:checkVatFault>
         </detail>
      </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

Example Fault Message Mapping in ESR

Example Fault Message in ABAP proxy systems SXMB_MONI

So this leaves me a little baffled. Is this really how handling standard soap faults (Proxy --> PI --> Web service) will work? What will happen if detail node is not filled by 3rd party web service? Will I then need to go the "Use no soap envelope" way?

Please be aware that I used a different service than the original intended one for this current testing session because the web service of the original post does indeed return HTTP 200 instead of 500. So I will need to cope with that one differently anyways. But for now let's concentrate on a proper HTTP 500 standard soap fault

Any further insights / best practices on the matter will be highly welcome. Sorry for not having all the ducks in a row in the first place.

Many thanks and kind regards

Jens