Function module

[Former Member]

Hi experts,

can anyone tell me the functionality of Update Function Module of SE37.

and also tell me the difference between HIDE and GET CURSOR stmt.

Thanks in advance,

Regards

alson

[Former Member]

refer.

null

[seshatalpasai_madala]

Hi,

There are two types of UPDATE function modules. V1 and V2.

All V1 function modules are generally run as and when they are called and all V2 function modules will have functionality that is not that critical.

Its upto the developer to categorize a function module as V1 or V2 based on the functionality that you want to put in the FM.

HIDE is the statement used to PUSH the data back in to the programs workarea when a user event occurs on the LIST. Alternatively you can get this data from the system variable sy-lisel.

Regards,

Sesh

[Former Member]

Hi ,

For update function module read this .

Bundling using Function Modules for Updates

If you call a function module using the CALL FUNCTION... IN UPDATE TASK statement, the function module is flagged for execution using a special update work process. This means that you can write the Open SQL statements for the database changes in the function module instead of in your program, and call the function module at the point in the program where you would otherwise have included the statements. When you call a function module using the IN UPDATE TASK addition, it and its interface parameters are stored as a log entry in a special database table called VBLOG.

The function module is executed using an update work process when the program reaches the COMMIT WORK statement. After the COMMIT WORK statement, the dialog work process is free to receive further user input. The dialog part of the transaction finishes with the COMMIT WORK statement. The update part of the SAP LUW then begins, and this is the responsibility of the update work process. The SAP LUW is complete once the update process has committed or rolled back all of the database changes.

During the update, errors only occur in exceptional cases, since the system checks for all logical errors, such as incorrect entries, in the dialog phase of the SAP LUW. If a logical error occurs, the program can terminate the update using the ROLLBACK WORK statement. Then, the function modules are not called, and the log entry is deleted from table VBLOG. Errors during the update itself are usually technical, for example, memory shortage. If a technical error occurs, the update work process triggers a database rollback, and places the log entry back into VBLOG. It then sends a mail to the user whose dialog originally generated the VBLOG entry with details of the termination. These errors must be corrected by the system administrator. After this, the returned VBLOG entries can be processed again.

For further information about update administration, see Update Administration

This technique of bundling database changes in the last database LUW of the SAP LUW allows you to update the database asynchronously, reducing the response times in the dialog work process. You can, for example, decouple the update entirely from the dialog work process and use a central update work process on a remote database server.

Also refer to saphelp.

This statement stores - in the current list level - the content of the variable dobj together with the current list line whose line number is contained in sy-linno. The data type of the variables dobj must be flat and no field symbols can be specified that point to rows of internal tables, and no class attributes can be specified. The stored values can be read as follows:

For each user action in a displayed screen list that leads to a list result, all the row values stored using HIDE - that is, the row on which the screen cursor is positioned at the time of the event - are assigned to the respective variables.

If a list row of an arbitrary list level is read or modified using the statements READ LINE or MODIFY LINE, all the values of this row stored using HIDE are assigned to the respective variables.

Notes

The HIDE statement works independently of whether the list cursor was set. In particular, variables for empty list rows can be stored - that is, rows in which the list cursor was positioned using statements like SKIP.

The HIDE statement should be executed immediately at the statement that has set the list cursor in the row.

Outside of classes, constants and literals that cannot be read in list results and in the statement READ LINE can be specified for dobj outside of classes.

Example

Storing square numbers and cubic numbers for a list of numbers. The example shows that arbitrary variables can be stored independently of row content. In the real situation, one would more likely store only the number and execute the calculation, when required, in the the event block for AT LINE-SELECTION.

REPORT ...

DATA: square TYPE i,

cube TYPE i.

START-OF-SELECTION.

FORMAT HOTSPOT.

DO 10 TIMES.

square = sy-index ** 2.

cube = sy-index ** 3.

WRITE / sy-index.

HIDE: square, cube.

ENDDO.

AT LINE-SELECTION.

WRITE: square, cube.

GET CURSOR { {FIELD field [field_properties]}

| {LINE line [line_properties]} }.

Effect

If this statement is specified during list processing, it will transfer - depending on the specification of FIELD or LINE - the name of the output field or the number of the list line on which the screen cusor in the currently displayed list is positioned (after the user action) into the variables field or line. For field, a character-type (prior to Release 6.10 flat) variable is expected; for line, a variable of the type i is expected. With the additions field_properties and line_properties, further information on the cursor position can be imported.

With the FIELD addition, only the names of global data objects of the ABAP program can be determined. If the cursor is positioned on the output of a data object that is not visible in the current context or a literal, field will be initialized. The latter has no influence on the other additions or on sy-subrc.

Please reward if useful.

[Former Member]

Hi,

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 retrieve information about the current cursor position in an interactive event, use the GET CURSOR statement. You can retrieve information either about the current field or the current line.

For field information, use the variant:

GET CURSOR FIELD ...

For field information, use the variant:

GET CURSOR LINE ...

HIDE

The HIDE statement is one of the fundamental statements for interactive reporting. You use the HIDE technique when creating a basic list. It defines the information that can be passed to subsequent detail lists.

regards,

keerthi