function modules

[Former Member]

Hi

what is updatable fm

[Former Member]

Hi Pravalika,

I think you are talking about Update function Modules.

Unlike transactions and executable programs, dialog modules do not start a new SAP LUW. Calls to update-task function modules from a dialog module use the same update key as the ones in the calling program. The result is that calls to update function modules from a dialog module are executed only if a COMMIT WORK statement occurs in the calling program.

If you place a COMMIT WORK in a dialog module, it does commit changes to the database (for example, with UPDATE).However, it does not start the update task. The function modules are not actually executed until a COMMIT WORK statement occurs in the calling program.

If you use dialog modules, try to avoid including calls to update function modules in subroutines called with PERFORM ON COMMIT. In general, any occurrence of PERFORM ON COMMIT(with or without update-task function calls) in a dialog module can be problematic.

This is because dialog modules have their own roll area, which disappears when the module finishes. Consequently, all local data (including data used for parameter values when calling an update function module) disappears as soon as the commit in the main program is reached.

If you must use this method in a dialog module (i.e. include the call to an update-task function in a subroutine), you must ensure that the values of the actual parameters still exist when the update-task function actually runs. To do this, you can store the required values with EXPORT TO MEMORY and then import them back into the main program (IMPORT FROM MEMORY) before the COMMIT WORK statement

Creating Update Function Modules

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 Interface

Function 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

Thanks.

Mark

[Former Member]

Hi,

The main update technique for bundling database changes in a single database LUW is to use CALL FUNCTION ... IN UPDATE TASK.

Function modules that run in the update task can run synchronously or asynchronously. You determine this by the form of the COMMITstatement you use:

· COMMIT WORK

This is the standard form, which specifies asynchronous processing. Your program does not wait for the requested functions to finish processing.

· COMMIT WORK AND WAIT

This form specifies synchronous processing. The COMMITstatement waits for the end of processing. Control returns to your program after all high priority (V1) function modules have run successfully.

The AND WAIT form is convenient for switching old programs to synchronous processing without having to re-write the code. Functionally, using AND WAIT for update-task updates is just the same as dialog-task updates with PERFORM ON COMMIT.

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.

Have a look at below link:

http://help.sap.com/saphelp_nw70/helpdata/en/41/7af4daa79e11d1950f0000e82de14a/frameset.htm

I hope it helps.

Best Regards,

Yogesh

Please mark all the helpful answers

[prasanth_kasturi]

hi,

Unlike transactions and executable programs, dialog modules do not start a new SAP LUW. Calls to update-task function modules from a dialog module use the same update key as the ones in the calling program. The result is that calls to update function modules from a dialog module are executed only if a COMMIT WORK statement occurs in the calling program.

If you place a COMMIT WORK in a dialog module, it does commit changes to the database (for example, with UPDATE).However, it does not start the update task. The function modules are not actually executed until a COMMIT WORK statement occurs in the calling program.

If you use dialog modules, try to avoid including calls to update function modules in subroutines called with PERFORM ON COMMIT. In general, any occurrence of PERFORM ON COMMIT(with or without update-task function calls) in a dialog module can be problematic.

This is because dialog modules have their own roll area, which disappears when the module finishes. Consequently, all local data (including data used for parameter values when calling an update function module) disappears as soon as the commit in the main program is reached.

If you must use this method in a dialog module (i.e. include the call to an update-task function in a subroutine), you must ensure that the values of the actual parameters still exist when the update-task function actually runs. To do this, you can store the required values with EXPORT TO MEMORY and then import them back into the main program (IMPORT FROM MEMORY) before the COMMIT WORK statement

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 Interface

Function 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

regards

prasanth