Monday 1 July 2013

Update Function module



It is basically used to bundle distributed updates within different programs spots, to one place (in FM).

Such FM would store all the UPDATE/INSERT/DELETE statements which otherwise you would write in some program place. Now when system reaches CALL FUNCTION 'XXX' IN UDPDATE TASK it doesn't go inside. Instead in registeres this XXX FM in VBLOG table (you can see update tasks in SM13) to be executed later. Now when in program it reaches COMMIT WORK statement, it looks into that table and calls each registered functions.
The aim is to either COMMIT all the changes at once, or ROLLBACK them all. This means that if inside one of any FM these statements are encountered system writes changes to DB permanently. Next it clears VBLOG table (so no FM are registered for change anymore) and continues the program.


*************************************************************************

Creating Update Function Modules  Locate the document in its SAP Library structure
To create a function module, you first need to start the Function Builder. Choose Tools ® ABAP Workbench, Function Builder. For more information about creating function modules, refer to the ABAP Workbench Tools documentation.To be able to call a function module in an update work process, you must flag it in the Function Builder. When you create the function module, set the Process Type attribute to one of the following values:
  • Update with immediate start
Set this option for high priority ("V1") functions that run in a shared (SAP LUW). These functions can be restarted by the update task in case of errors.
  • Update w. imm. start, no restart
Set this option for high priority ("V1") functions that run in a shared (SAP LUW). These functions may not be restarted by the update task.
  • Update with delayed start
Set this option for low priority ("V2") functions that run in their own update transactions. These functions can be restarted by the update task in case of errors.
To display the attributes screen in the Function Builder, choose Goto Administration.
Defining the InterfaceFunction modules that run in the update task have a limited interface:
  • Result parameters or exceptions are not allowed since update-task function modules cannot report on their results.
  • You must specify input parameters and tables with reference fields or reference structures defined in the ABAP Dictionary.
***************************************************************


CALL FUNCTION update_function IN UPDATE TASK
                             [EXPORTING p1 = a1 p2 = a2 ...]
                             [TABLES t1 = itab1 t2 = itab2 ...].

This statement registers the update function module specified in update_function. update_function must be a character-type field, which during execution of the statement contains the name of an update function module in uppercase letters.

An update function module is a function module, for which in the Function Builder the property update module is marked. The registration of an update function module is an essential part of the update task.

The function module is not executed immediately, but is scheduled for execution in a special work process (update work process). For this purpose, the name of the function module including the passed actual parameters is stored as a log record in the database table VBLOG. If the statement is executed during the update task, the addition IN UPDATE TASK is ignored.

If the statement
SET UPDATE TASK LOCAL is executed before registration of an update function module in the current SAP LUW, registration takes place in the ABAP memory rather than on the database, and for the current work process.

The actual execution is triggered by the statement COMMIT WORK. The formal parameters of the function module receive the values of the actual parameters from table VBLOG. A function module that is registered several times will also be excuted several times with the respective parameter values.
If a COMMIT WORK statement is not executed after registration of a function module during execution of the current program, the function module is not executed and is deleted from table VBLOG at the end of the program.

Addition 1

... EXPORTING p1 = a1 p2 = a2 ...

Addition 2

... TABLES t1 = itab1 t2 = itab2 ...

Effect

The additions EXPORTING and TABLES have the same syntax and meaning as in the parameter_list of the general function module call, except that for EXPORTING, no Referenzvariablen or data objects that contain reference variables can be output as actual parameters.

Notes


  • The additions IMPORTING, CHANGING and EXCEPTIONS of the general function module call may be specified, but they are ignored during the execution. The additions for a dynamic parameter transfer are not allowed.

  • While an update function module is processed in an update work process, you are not allowed to execute the statements SUBMIT, CALL DIALOG, CALL SCREEN, CALL TRANSACTION, COMMIT WORK, ROLLBACK WORK and all other statements that provoke a database commit.

  • If during the update an error occurs, the update work process executes a database rollback, returns the log record with a note into table VBLOG and informs the user whose program has created the log record by SAPMail. After removing the error cause, the returned log records can be updated again.

1 comment:

  1. Hi Sandeep,

    Very good explanation.
    But could you detail about, why we are not allowed to execute the statements SUBMIT, CALL DIALOG, CALL SCREEN, CALL TRANSACTION, COMMIT WORK, ROLLBACK WORK.
    please do explain the reason behind it.
    Thank you.

    ReplyDelete