Skip to Content
Author's profile photo Edward Pelyavskyy

Counting to 4 and committing your database changes

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:

  1. 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.
     
  2. 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.
     
  3. 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.

Assigned Tags

      3 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Martin English
      Martin English
      From both an OO and a functional perspective, when you write your own code (Z* modules) you should use the UPDATE TASK syntax. This allows for recording and management of the Update Records (see http://help.sap.com/saphelp_nw04/helpdata/en/e5/de870535cd11d3acb00000e83539c3/content.htm and http://help.sap.com/saphelp_nw04/helpdata/en/e5/de86ea35cd11d3acb00000e83539c3/content.htm ).  Unfortunately, one of the worst offenders against this rule is SAP written code.

      BTW, the title came about because the UPDATE TASK syntax was the third method you specified :))

      http://www.moviequotedb.com/movies/monty-python-and-the-holy-grail/quote_15708.html

      Author's profile photo Former Member
      Former Member
      There is one possible way of updating, update functions. There are two ways for updates, update function modules and inline updates. Amongst ways of updating data are diverse elements such as... (nobody expects the Spanish Inquisition!)

      Anyhow, nice quote there. I do think though that we should be very careful with giving out general recommendations as unfortunately many developers are not completely aware of the SAP LUW concept. Here are some further comments that might help to instill further interest in the readers of the blog to read-up on the SAP LUW concept...

      Form routines called on commit/rollback are considered bad usage by most, because they rely on global variables (and correspond to synchronous updates).

      As you mention the update functions allow the management of the update data (though really more for handling update failures), but I don't think that's the main reason to use them. One important reason for decoupling the updates is the shortened response time for a user (thus also freeing up the dialog work process). However, it introduces an overhead (logging in VBLOG) that might be considered useless in some cases (and if integrated in some bigger framework like in IDoc processing we sometimes start using "set update task local" to get around this).

      Another example might be massive database updates, where direct inline updates are often more appropriate.

      Also, when talking about update function modules, we have to distinguish between asynchronous updates (COMMIT WORK) and synchronous updates (COMMIT WORK AND WAIT). The latter cannot be restarted via SM13.

      In the end I think the main message is that *all* developers should have a good understanding of the SAP LUW concept.

      Author's profile photo Edward Pelyavskyy
      Edward Pelyavskyy
      Blog Post Author
      Thank you Martin and Harald for sharing your views.

      Database updates and SAP LUW are interesting topics to discuss. There are a few alternatives to approach updates. ABAP developers should be aware of the alternatives and make an informed decision to use one of them in a particular situation.