Hi,
The following is in SAP Notes 730870 FAQ XI 3.0 RFC Adapter
Q 10.
<i> A: The following only applies to RFC receiver channels.
BAPIs can be implemented as RFC enabled function modules or IDocs. By their nature the RFC functionen modules are synchronous, the IDocs are asynchronous. Thus, if the communication should be asynchronous, it is a good idea to use the IDoc implementation of a BAPI.
The RFC function module implementation of a BAPI will not only report it's result in the synchronous response. It also will report it's execution status (like Success, Error, ...). If the RFC call to such a function module was asynchronous, there will be no response and also no knowledge about the execution status. Even if the RFC call was synchronous, the RfcAdapter does no special handling for this values. It will treat a response value of any kind as a successful execution because it does not implement some BAPI application logic.
Nevertheless the RfcAdapter will treat each RFC call like described in Q 9: A XI message with QoS BE will lead to a (synchronous) sRFC call, a message with QoS EO will lead to a (asynchronous) tRFC call.
BAPIs with a database update or write functionality expect a special form of commit (ABAP application COMMIT WORK) to actually fulfill their tasks because they (often) use the SAP update technique. Within RfcAdapter there is no special handling of transactions like a commit, so database update BAPIs may have a problem. If the BAPI RFC function module is called (asynchronous) via tRFC, the tRFC-subsystem of the SAP-System will issue a database commit by itself (no ABAP COMMIT WORK). So direct database updates will be possible but no updates via the SAP update process. Also the problem with the missing execution result persists.
The following can be considered to use BAPIs with RfcAdapter regarding the interpretation of the execution result and the commit of the transaction. If it is required that one update BAPI is called, it can be put in a wrapper RFC function module which first calles this BAPI, does the interpretation of the execution result and than does the commit or rollback of the transaction. If it is required that multiple update BAPIs get commited together within one transaction, these BAPIs can be encapsulated in a wrapper RFC function module which first calls the BAPIs and at the end does the commit of the transaction depending on their execution result. In either case the wrapper RFC function module can be called by RfcAdapter.
Anyway you have to keep in mind that this can compromise the quality of service (QoS) which was guaranteed by the original message. Imagine these two possibilities: a synchronous message with QoS BE or a asynchronous message with QoS EO.
• The message was send synchronous with QoS BE (which will result in a synchronous RFC call, also called sRFC). The call reaches the receiver system and the function module is executed successful with the commit at the end. But during the sending of the return value a problem occurs (like network, ...). This can also happen if there even is no return value in the function module, because the receiver system at least will send back a indication that the execution has finished. So the RfcAdapter will generate an error (like timeout, ...) and send this one back to the sender of the message. As seen in this example the sender will not know if the message (containing the RFC call) has reached the receiver system and also it will not know if the execution happened in the receiver system.
• The message was send asynchronous with QoS EO (which will result in a transactional RFC call, also called tRFC). The call reaches the receiver system and the function module is executed successful with the commit at the end. But during sending back the indication that the RFC call was executed (which actually will be synchronous) a problem occurs (like network, ...). The RfcAdapter will generate an error and send it back to it's persistency layer, the Adapter Framework Messaging. The message now marked as erroneous will be scheduled for a new execution because for messages with QoS EO the delivery will be guaranteed. When send again, the receiving system tRFC implementation decides whether the call was already successfully received or not. This guarantees the exactly once protocol of the tRFC implementation.
To handle this behaviour the approach to call a BAPI via a wrapper function module will not solve the problems described above. Some mechanism within the application has to deal with this type of problems.
As of SP 14 support for commit handling for single BAPI calls was added to the RfcAdapter receiver channel. If activated in the receiver channel setting, the received XI message will be executed as synchronous RFC (sRFC) in the receiving system. This is also true for asynchronous (QoS EO) XI messages to receive and analyze the execution result by the RfcAdapter.
The received response is parsed by the RfcAdapter to get the BAPI return parameter with name "RETURN". This return parameter can be of BAPIRETURN, BAPIRET1 or BAPIRET2 types. The "RETURN" parameter is checked for the response status (field TYPE) which can take following values:
1. 'S' : Success
2. 'I' : Information
3. 'W' : Warning
4. '' : Empty String
5. 'A' : Abort
6. 'E' : Error
If the response contains one amongst the first four response status then it implies that the BAPI was successful. If the response contains one amongst the last two response then the BAPI failed. If the BAPI "RETURN" parameter is of not of type ABAP structure rather of type ABAP table, a empty table is also considered as successful execution result.
In case of a successful execution the BAPI function module "BAPI_TRANSACTION_COMMIT" is called within the same context to trigger the commit of the BAPI. In case of a failure the BAPI function module "BAPI_TRANSACTION_ROLLBACK" is executed by RFC Adapter which rolls back the changes.
If the XI request message was of QoS BE, the result of the BAPI execution is send back as XI response. In case of a QoS EO request message nothing is send back as response.</i>
Chilla..
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.