cancel
Showing results for 
Search instead for 
Did you mean: 

Catch exception thrown on sender RFC (RFC => PI => SOAP)

JaySchwendemann
Active Contributor
0 Kudos

Hi all,

I have a scenario sender RFC => SAP PI = SOAP receiver that is actually working fine. However, I changed the hostname on the receiver SOAP adapter on purpose to some wrong value. When this happens, sure enough I get an error within SXMB_MONI stating "com.sap.aii.af.ra.ms.api.DeliveryException: A remote host refused an attempted connect operation.". At the same time the RFC call in my sending system (my ERP system) dumps with this message:

Runtime Error: CALL_FUNCTION_REMOTE_ERROR

Short text: "call to messaging system failed: com.sap.aii.af.ra.ms.api.DeliveryException:

Error analysis:An error occurred when executing a REMOTE FUNCTION CALL. It was logged under the name "RFC_EXTERNAL_ABORT" on the called page.


How do I catch this Error? The actual FM I call is just an empty shell that is used to pass the parameters to SAP PI. I even haven't created the FM in the PI system as that seemed not necessary to have this function (not having intentionally changed the hostname to a wrong value as said above, of course). Creating the FM in the PI system however does not change the behavior.

Any clues on this?

Cheers

Jens

Accepted Solutions (1)

Accepted Solutions (1)

JaySchwendemann
Active Contributor
0 Kudos

Hi all,

apparently I was missing the obvious. Kate's answer should have brought me on the right track in the first way but it was Nabendu's second comment that got me thinkin.

Of course I can catch any "other" exception of the FM. So I did that and all was fine 🙂

So this is what I came up with (this is the call of the RFC in the sender ERP system)

CALL FUNCTION 'Z_CRM_SEND_DEBITOR_TO_CRM' DESTINATION i_destination

  EXPORTING

    i_user        = i_user

    i_pwd         = i_pwd

    it_customer   = it_customer_request

  IMPORTING

    et_customer   = et_customer_response

  EXCEPTIONS

    error         = 1

    OTHERS        = 2.

IF sy-subrc <> 0.

*  do error handling here

ENDIF.

So the trick was really to use "OTHERS" when calling the RFC.

Sorry for missing something that basic but maybe this thread helps someone to avoid this caveat.

Cheers

Jens

Answers (5)

Answers (5)

sunil_singh13
Active Contributor
0 Kudos

Jans,

For the dumps you are getting in Sending system you can't do anything in PI. Also as the scenario that you have mention is related to System error (and not application error) so even fault messages will not help here. Can you try encapsulating that RFC in Proxy and making call?(if Possible) So your scenario will change to Proxy - > PI -> SOAP.

Dump in Sending system is due to timeout?

Thanks,

Sunil

nabendu_sen
Active Contributor
0 Kudos

Hi Jens,

Please clarify whether it is a Synchronous RFC scenario involving Request, Response and Fault message mapping in your Operation Mapping. At the time of Destination failure, fault message is getting back to SAP RFC. Please confirm.

Former Member
0 Kudos

Along the same lines as Nabendu is asking... if your scenario is asynchronous perhaps the RFC will complete OK in SAP side, and the request gets cached in PI. When PI cannot contact the SOAP reciever for some reason it would retry several times before giving up and raising a PI exception.

This could maybe help your error handling and resolution because there would be fewer cases where the call fails on the SAP side.

JaySchwendemann
Active Contributor
0 Kudos

Hi Nabendu, Aaron,

sorry to be unclear about this. Let me answer your questions:

1. Is it synchronous or asynchronous?

--> It's synchronous scenario

2. Is it involving request, response and fault message

--> Yes, it involves all three messages. So yes, I use the fault message where appropriate. However: With my forced error I simulated a "destination host down" scenario, hence there's no chance I will get a SOAP fault back from destination. Thad said, SOAP fault is working fine on application errors like "Unable to find customer record" or such. Just to complete the picture

3. Going asynchronous seems not an option because I would then loose the ability of SOAP fault messages, right?

So just to be precise about the scope of the question: The error I am forcing now and that is causing a dump in the sender ERP system is actually very unlikely to happen (e.g. destination system down, destination service unavailable, etc). I covered all the application errors with SOAP Fault messages. However, I would assume that there should be some way avoiding a dump in the sender ERP system. My administrators will be rather "unhappy" if not 🙂

Cheers

Jens

nabendu_sen
Active Contributor
0 Kudos

Hi Jens,

I think we are missing some basics. If SAP calls a RFC and expect response and in that between if any System error happens, then to close the call at SAP side some error needs to be sent back. Otherwise how SAP can understand whether the process needs to be closed or it should wait further or for Monitoring purpose what actually happened to that call.

If SAP system wants some different message or different process, they need to handle that at their side.

Former Member
0 Kudos

Hello Jens,

In the abap code, when calling the RFC, try this:

CALL FUNCTION Remotefunction

   DESTINATION Dest

   EXPORTING...

   IMPORTING...

   TABLES...

    EXCEPTIONS

      communication_failure = 1

      system_failure        = 2.

If you use the "EXCEPTIONS" when calling the RFC, you will probably not have a dump if something goes wrong in the PI side.

Kate

JaySchwendemann
Active Contributor
0 Kudos

Hi Kate,

I already tried this to some extend. However, with a sender RFC there isn't actually a need to have a stub of the FM in the destination system (here: the PI system) it works anyway. But as I was curious I also created the stub and used exceptions. Though that was to point where I was not sure, what to catch actually because there's actually no code (no code needed to be precise) within the RFC stub in PI system. It acts merely as a shell to transport parameters to SAP PI. Below you find a example of the RFC. As you see, no code there. How would I raise an exception then? I already tried put a big try catch in the body of the RFC but no luck.

FUNCTION z_crm_send_debitor_to_crm.

*"----------------------------------------------------------------------

*"*"Lokale Schnittstelle:

*"  IMPORTING

*"     VALUE(I_USER) TYPE  ZCRM_USER

*"     VALUE(I_PWD) TYPE  ZCRM_PWD

*"     VALUE(IT_CUSTOMER) TYPE  ZCRMTT_CUSTOMER_REQUEST

*"  EXPORTING

*"     VALUE(ET_CUSTOMER) TYPE  ZCRMTT_CUSTOMER_RESPONSE

*"  EXCEPTIONS

*"      ERROR

*"----------------------------------------------------------------------

*========================================*

* Raise error if necessary

*---------------------------------------------------------------------*

   TRY.

       IF sy-subrc <> 0.

         RAISE error.

       ENDIF.

     CATCH cx_root.

       RAISE error.

   ENDTRY.

*---------------------------------------------------------------------*

ENDFUNCTION.

Any further hints on this?

Kind regards

Jens

JaySchwendemann
Active Contributor
0 Kudos

Thanks for the input. I am aware that I may create alerts within SAP PI. However, that would not prevent the dump from happen, would it?

I will surely add alerting to this scenario but would like to know If there's any chance to not having a dump within my systems (at least not within the sending ERP system) if possible.

Thanks and kind regards

Jens

former_member201264
Active Contributor
0 Kudos

Hi Jens,

You  can create Alert in PI as below link:

http://scn.sap.com/community/pi-and-soa-middleware/blog/2005/09/09/xi-alerts--step-by-step

Regards,

Sreeni.