cancel
Showing results for 
Search instead for 
Did you mean: 

SOAP receiver system error behavior still valid when not having a "detail" node?

JaySchwendemann
Active Contributor
0 Kudos

Hi all,

we are using PI 7.0 SP25. I have a HTTP sender --> PI --> SOAP receiver scenario. So basically I'm consuming a webservice from a third party system that can send a http request to PI.

I managed to get basic communication going but if the webservice provider encounters an error it will (conform to standard) send a SOAP fault message with HTTP status 500. However, the resulting SOAP fault message does not have a detail tag / node. This results in PI treating the message as system error.

My questions are

  1. Is this behavior still the same in the current version of SAP PI (7.3 as of the time this was written)
  2. Is there any (elegant) workaround for this problem? I know that using AXIS would be a way but I never used that and would not want to go that way if there's an easier solution. Also know about "Do not use SOAP envelope" and applying the module parameter XMBWS.NoSOAPIgnoreStatusCode. I however would prefer using SOAP as this is really what the webservice provider is sending out

Pretty much can't believe that SAP would insist on the "detail" node to be existent to distinguish between application error and system error, especially given the fact that "detail" is optional according to W3C.

Could anybody clarify this?

Here's the SOAP fault message the webservice provider sends back on error:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

   <SOAP-ENV:Body>

      <SOAP-ENV:Fault>

         <faultcode>50</faultcode>

         <faultstring>Error returned from Gateway: 50 (Fehler bei Login)</faultstring>

      </SOAP-ENV:Fault>

   </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Thanks andybody. Cheers

Jens

Accepted Solutions (1)

Accepted Solutions (1)

udo_martens
Active Contributor
0 Kudos

Hi Jens,

Is this behavior still the same in the current version of SAP PI (7.3 as of the time this was written)

yes

Is there any (elegant) workaround for this problem?

You can use "Do not use SOAP envelope". That means, the adapter will not create a soap enveloap in request and will not remove it in response. You have to do that in mapping time.

You can for example create a very simple xsl where you create the envelope static and copy your message with xsl:copy-of.

In the response you need to extract the xml. XSL is not dependend from a data/message type and is here the right choice to catch the error:

<xsl:if test="string-length(//faultstring) &gt '0' ">

     <ApplicationError>

          <xsl:value-of select="//faultstring"/>

     </ApplicationError>

<xsl:otherwise>

     <xsl:copy-of...

(Pseudo Code)

You can combine the XSLs with your existing mapping.

Regards,

Udo

Answers (0)