Skip to Content
avatar image
Former Member

How to handle RFC Application Errors

I am make an RFC call to SAP to call a function module that for example should create or change a salesorder or a quote. A change salesorder in sap could fail for many different reasons one of which is "object locked". When such a call fails the BAPIRET2 structure is populated with TYPE = "E" messages. One solution is to ask the sender to resend, but this is not always the most efficient and convenient way. Could some of you share you ideas and experiences regarding this issue.

Thanks

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

2 Answers

  • avatar image
    Former Member
    Nov 22, 2004 at 11:45 PM

    Hi Vad,

    First of all I assume you mean sRFC (synchronous) not tRFC (asynchronous). Please correct me if I am wrong.

    The RFC adapter does not support application level commits so using a BAPI will not work unless you wrap it in a "Z" function and include a commit work. This approach is also technically flawed because the commit could occur but the return communication could be interrupted giving the caller the impression the posting failed when in fact it worked. They then proceed to post again causing duplicate posting. Posting should be done asynchronously while the RFC adapter does not support application level commit.

    Next, synchronous is QoS BE (Best Effort). So if it fails the application is not supposed to manage the error, it simply reports the problem back to the user and it is their choice to resend or not.

    If that is not what you want, or you want the application to manage posting the data then you should choose an asynchronous QoS (ie. EO or EOIO). This can be both convenient and efficient. To do this you can use IDOC adapter. Each BAPI either already has an ALE interface, or you can generate one easily in a couple of minutes. The ALE interface is basically an Idoc that calls the BAPI for you.

    Often the customer insists they need a response from the destination application before continuing. In the case of posting data this is difficult because as pointed out above it can lead to problems.

    One approach is to wrap the BAPI in a "Z" function, include the commit BUT ensure that multiple postings in the application layer is prevented, or of no consequence. Some BAPI's might do this already, some might require additional logic. It seems ridiculous, but it is necessary.

    Another option is to use the synch-asynch bridge in BPM (assuming you are on 3.0). This is the best of both worlds (with an additional performance hit). The sender can be synchronous while the posting takes place asynchronously. Reasonable solution for now.

    Hope this helps.

    Jason

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      Hi Vad,

      I guess the short answer is, if the sender expects QoS BE, then you shouldn't attempt to reprocess. It would be inappropriate for the middleware to reprocess in this circumstance.

      If, on the other hand, the sender expects QoS EO or EOIO, then you have the opportunity to reprocess using BPM if you are on version 3.0.

      Regards,

      Jason

  • avatar image
    Former Member
    Jul 26, 2005 at 03:28 PM

    Guys,

    any clues to this problem? I'm facing the same problem. Any immediate insights will be greatly helpful.

    Best regards/ Sanjeev

    Add comment
    10|10000 characters needed characters exceeded