How to handle RFC Application Errors

[Former Member]

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

[Former Member]

Guys,

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

Best regards/ Sanjeev

[Former Member]

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

[Former Member]

Jason, thanks for your reply.

One of the sugestions you make is exactly what I am doing. I have a Z wrapper around a BAPI and a commit. The issue is that XI does not flag this message as error when the BAPIRET2 table interface is populated with TYPE = "E" messages. On a technical level this message was successfull, it failed at the application level. My question is how to track and reprocess such messages without asking the sender to resend.

Thanks

Vad

[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