Skip to Content

The class cl_system_transaction_state contains several useful utility methods:

get_in_update_task: return the flag whether current code is running with normal work process or in update work process

get_on_commit: return flag whether current code is called because of a previous registration via PERFORM ON COMMIT and triggered by COMMIT WORK

get_sap_luw_key: return current LUW ID

I just use a very simple report to test them. First I call the FM ZSQF in a normal way, then call it via update task, then register it with PERFORM ON COMMIT and trigger it via COMMIT WORK.

WRITE: / ‘Direct call ZSQF begin…’.

DATA(lv_luw_key) = cl_system_transaction_state=>get_sap_luw_key( ).

WRITE:/ ‘LUW key in main program:’, lv_luw_key.

CALL FUNCTION ‘ZSQF’.

WRITE: / ‘Direct call ZSQF end…’.

CALL FUNCTION ‘ZSQF’ IN UPDATE TASK.

PERFORM call_fm ON COMMIT.

COMMIT WORK AND WAIT.

lv_luw_key = cl_system_transaction_state=>get_sap_luw_key( ).

WRITE:/ ‘LUW key in main program after COMMIT WORK:’, lv_luw_key.

FORM call_fm.

   WRITE:/ ‘ZSQF is called on COMMIT begin…’.

   CALL FUNCTION ‘ZSQF’.

   WRITE:/ ‘ZSQF is called on COMMIT end…’.

ENDFORM.

In the function module ZSQF, I just print out the three flags.

DATA(lv_in_update) = cl_system_transaction_state=>get_in_update_task( ).

DATA(lv_on_commit) = cl_system_transaction_state=>get_on_commit( ).

DATA(lv_luw_key) = cl_system_transaction_state=>get_sap_luw_key( ).

WRITE: / ‘Am I in update task? ‘ , lv_in_update.

WRITE: / ‘Am I triggered via PERFORM ON COMMIT?’, lv_on_commit.

WRITE: / ‘Current LUW Key’ , lv_luw_key.

The execution result shows the fact that the normal FM call, the FM registered to COMMIT WORK and the update task all run within the same LUW, and also proves the explanation of COMMIT WORK in ABAP help: “The COMMIT WORK statement closes the current SAP LUW and opens a new one”. 🙂

/wp-content/uploads/2014/01/clipboard1_355860.png

The WRITE keyword executed in update task will not generate any output in SE38 list, and apart from switching on “update debugging” and check the three flags in debugger, there is also another way to log the content of the variable like lv_luw_key:

Just create a new checkpoint group via tcode SAAB, specify option “Log” for Logpoints and maximum validity period.

/wp-content/uploads/2014/01/clipboard2_355861.png

Then append the following code in the FM implementation:

IF lv_in_update = 1.
LOG-POINT ID ZUPDATELOG SUBKEY ‘Current LUW KEY’ FIELDS lv_luw_key.

ENDIF.

Now after report execution, go to tcode SAAB, click Log tab, and we can find the content of lv_luw_key which is logged by the above ABAP code LOG-POINT ID ZUPDATELOG SUBKEY ‘Current LUW KEY’ FIELDS lv_luw_key.

/wp-content/uploads/2014/01/clipboard3_355871.png

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Eitan Rosenberg

    Hi,

     

    Thanks for sharing.

    I was wondering if you can help me with this question:

    We have a program that call several SAP programs in sequence using BCD.

    From the user point of view they are considered a single business transaction.

    How we can include all those programs in a single luw ?

    Regards.

    (0) 
    1. Paul Hardy

      You can’t.

      After a BDC returns succesfully a COMMIT WORK is called by whatever standard SAP transaction you called.

      The only thing you can do is, in the event of failure, not only do not process the rest of the BDC calls in the sequence, but do make BDC calls to reverse the already completed transactions.

      That is not always possible i.e. if a BDC creates a piece of equipment you can’t delete that, you have to flag the equipment for deletion, and what if the reversal BDC fails?

      However that is the only approcah I can think of. Even if you were using BAPIS (and these don’t exist for many common SAP transactions) you would still usually need a COMMIT half way through as often the next transaction in the sequnce needs the results of the first transaction to be in the database (e.g. order number)

      Cheersy Cheers

      Paul

      (0) 
  2. Paul Hardy

    That is very useful information in regard to seeing if the code is running in an update transaction or whatever. One of my colleagues has been programatically queting the stack to achieve the same thing. This is much better.

    I have always wanted to know how I can programatically tell if code is running during an EXIT-COMMAND sequence, fr the simple reason that if you try to output certain types of message in such a situation you get a short dump.

    I imagine the response from SAP would be “don’t use AT EXIT-COMMAND, that is so ten minutes ago”. “They” want me to use the replacement technology for screen processing in SAP GUI (i.e. not in a web browser), except there is no such replacement techonology.

    (0) 
  3. Yuvaraj Shanmugam

    Thanks for the information.

    I have used the FM ‘TH_IN_UPDATE_TASK’ to find out if the FM is called in update task.

    Interestingly CL_SYSTEM_TRANSACTION_STATE=>GET_IN_UPDATE_TASK() uses a different set of system calls to get the same information.

    And LUW id could be useful too.

    (0) 

Leave a Reply