Prologue
Recently I've been doing some investigation on a strange behavior of a user exit. After I fixed the problem I became even more respectful of theData Consistency in ABAP in general and the Update Techniques in particular.
I find SAP help a bit terse. Only after I lived through the pain of some peculiar problem can I fully understand the meaning of SAP help. May be it's just me.
Update Techniques
Let's take a look at the following update techniques, which are stamped with the four steps: 1-Start, 2-Insert, 3-Commit, 4-End.
| Inline | Perform On Commit | In Update Task |
write: / '1-1'.
data ls_tab type ztab.
ls_tab-key1 = 'T1'.
ls_tab-data1 = 'DATA 1'.
write: / '1-2'.
insert ztab from ls_tab.
write: / '1-3'.
commit work.
write: / '1-4'.
| write: / '2-1'.
data ls_tab type ztab.
ls_tab-key1 = 'T2'.
ls_tab-data1 = 'DATA 2'.
gs_ztab = ls_tab.
perform insert_record
on commit.
write: / '2-3'.
commit work.
write: / '2-4'.
| write: / '3-1'.
data ls_tab type ztab.
ls_tab-key1 = 'T3'.
ls_tab-data1 = 'DATA 3'.
call function
'ZTAB_INSERT'
in update task
exporting
is_ztab = ls_tab.
write: / '3-3'.
commit work.
write: / '3-4'.
|
The insert_record subroutine is defined as follows.
form insert_record.
write: / '2-2'.
insert ztab from gs_ztab.
endform.
where gs_ztab is a global variable:
data gs_ztab type ztab.
The ZTAB_INSERT update function module is defined as follows.
FUNCTION ZTAB_INSERT.
*"----------------------------------------------------------------------
*"*"Update Function Module:
*"
*"*"Local Interface:
*" IMPORTING
*" VALUE(IS_ZTAB) TYPE ZTAB
*"----------------------------------------------------------------------
write: / '3-2'.
insert zevp_db_test from is_zevp_db_test.
ENDFUNCTION.
If I execute the three types of updates here is what I'm expecting to see.
| Inline | Perform On Commit | In Update Task |
1-1
1-2
1-3
1-4
| 2-1
2-3
2-2
2-4
| 3-1 or 3-1
3-3 3-3
3-4 3-2
3-2 3-4 *
|
* - I will not be able to actually see '3-2' since the update is done in the update process. Also the update task is asynchronous therefore the timing of step '3-2' can be arbitrary.
Lab Settings
Then I thought it would be nice to have a "research lab" settings to demonstrate the update techniques.
Once you have your lab settings you should be able to explore other data consistency topics not covered in this blog. For example, COMMIT AND WAIT, implicit database commits.
Those of you who are interested in finding out how I created the lab settings to demonstrate the update techniques, you can read this PDF document.
Epilogue
In this blog I'm bringing to your attention the three types of updates:
- Inline
The inline updates are subject to the implicit database commits triggered by some ABAP statements. For example, the WAIT UP TO n SECONDS statement will commit the changes done with the inline updates. No inline updates in the user exit, please.
- Perform On Commit
A subroutine registered with PERFORM ON COMMIT multiple times will only execute once. The subroutine is using global variables. Subroutines are strangers in the ABAP Objects context. This update is synchronous meaning step 2-4 is waiting until step 2-2 is finished.
- In Update Task
Out of the three I prefer this one. It fits well into the ABAP Objects context. The function module has input parameters. The function module will be executed multiple times if it was called more than once. It is asynchronous but I can also wait for it to finish with COMMIT WORK AND WAIT.
When you need to make database updates please consider your options in all three types of updates.
Also you can take a look at Persistence Service to see if this something you may find useful.
A note not related to the update techniques: the test program demonstrates how to use the CL_RTM_SERVICES class to work with the checkpoint log records directly without going to the SAAB transaction.
