Ansicht
Dokumentation

SAPBC415_RFCSYNC_D4 - Synchr. RFC: Each RFC Call Maps its Own LUW Onto the Database!

Description
This program demonstrates Remote Function Call.

The program shows that each RFC call has its own logical unit of work (LUW) in the database (there is an automatic commit at the start and end of each RFC call). Consequently, you cannot split database updates that belong together between different RFC calls, since a rollback would only apply to the function module being processed at the time (exception: transactional RFC).

Below are the most important program statements:

Function module calls:
->Function module BC415_RFC_DELETE_SFLIGHT_SBOOK (synchronous call)
->Function module BC415_RFC_DELETE_SFLIGHT_ENTRY (synchronous call)
->Function module BC415_RFC_DELETE_SBOOK_ENTRIES (synchronous call)

The program implements the following functions:
1. The function 'Delete flight data' deletes an entry from table SFLIGHT and the corresponding entry in table SBOOK. Consistent database changes using synchronous RFC can only be assured if the deletion from both tables is made in the same function module (radio button 'Correct implementation'. In this case, the function module BC415_RFC_DELETE_SFLIGHT_SBOOK is used.)
You can simulate an inconsistent update by choosing the 'Incorrect implementation' radio button. In this case, two RFC calls are made when you choose 'Delete flight data'. In the first, the SFLIGHT entry is to be deleted; in the second, the logically-dependent SBOOK entry. For the purpose of the demonstration, the key for the SBOOK record to be deleted is changed. Consequently, the SFLIGHT entry is deleted, but the SBOOK entries are retained. This is an inconsistent situation.
2. After the demonstration, you can restore the consistent state by choosing the 'Restore data' function.
3. You can start the Data Browser (Transaction SE16) directly from the transaction (remotely if necessary).

Requirements

Output

Example