SoAP -> PI -> RFC: Bapiret or other meaningful SOAP Fault

[JaySchwendemann]

Hi all,

after quite some research on SCN and some google requests I'm still stuck here.

I have a sender SOAP --> PI --> RFC synchronous scenario. RFC is a custom / Z FM so changing it is not a problem. If there is some error in processing within the RFC I want to give the sender some meaningful error information.

I know I could do fault mapping but this seems to leave me only with the ability to show something like this to the soap sender

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
   <SOAP:Body>
      <SOAP:Fault>
         <faultcode>SOAP:Server</faultcode>
         <faultstring>Application Error</faultstring>
         <detail>
            <ns1:MT_getShipmentFaultResponse xmlns:ns1="http://example.com/pi/WebService/example/10">
               <standard>
                  <faultText>ERROR</faultText>
                  <faultDetail>
                     <text>Some Error text!</text>
                     <id>005</id>
                  </faultDetail>
               </standard>
            </ns1:MT_getShipmentFaultResponse>
         </detail>
      </SOAP:Fault>
   </SOAP:Body>
</SOAP:Envelope>

So, ok I could have multiple, say n exceptions within my RFC and had to pick the right one but this seems odd. Would this be really the way to go?

I also know that i may just don't raise an exception within my RFC and could pass some bapiret structure in the normal response of the RFC. But this also seems not quite right because I really had an error and maybe...

a) would be able to see it as application error within SXMB_MONI and being able to create some PI alerts on this

b) would like to call the RFC from within SAP or some other system that maybe depends on raising exceptions to determine that the RFC just had an error.

--> Is there any nice way to get meaningful errror messages to the original sender and sticking to the whole SOAP fault paradigm / raising exceptions on error within RFC?

Any inputs on this would be really appreciated

Cheers

Jens

[udo_martens · Accepted solution]

Hi Jens,

one approach would be to wrap the RFC into a proxy, calling the rfc locally inside the ERP. Proxy technique allows filling fault message types in case of application errors. The response mapping needs to be a xsl to be able to influence the soap enveloap.

Regards,

Udo

[JaySchwendemann · Accepted solution]

Hi Udo,

thanks for your input and sorry for the delay in answering. Would using a proxy be the way you'd go to solve this problem?

What i figured out is, that if I don't raise an error at all but just throw a message like this...

MESSAGE 'Some dynamic error'
     TYPE 'E'.

... I'm getting an application error on SAP PI in this format (having set up a standard fault message type withing ESR and assigned it to the interface).

The response XML looks like this...

<rfc:Z_SDJSFBTEST002.Exception xmlns:rfc="urn:sap-com:document:sap:rfc:functions">
          <Name>RFC_ERROR_SYSTEM_FAILURE</Name>
          <Text>Some dynamic error</Text>
          <Message>
                    <ID>00</ID>
                    <Number>001</Number>
          </Message>
          <Attributes>
                    <V1>Some dynamic error</V1>
          </Attributes>
</rfc:Z_SDJSFBTEST002.Exception>

So assuming I would only need to throw the latest error this may be a way to go, right? The disadvantage would be, that I'm still stuck with the standard fault XML you see above and would not be able to insert any additional information, maybe a whole bapiret table with multiple lines that each holds information what happened during execution of this FM.

Anyhow, maybe this will help somebody out there.

Cheers

Jens