function module in update task

[Former Member]

i have a fm and i have to use it in update task

in order to do it i changed the fm in the attributes

to update mode but i get error exporting parameters are not allowed in the update task.

what do i have to do in order to fix it?

thanks

[Former Member]

You should post your question in the ABAP forum you will get very good responses there.

Post has been moved.

Message was edited by: Mark Finnern

[Former Member]

Hi Craig,

how to go to ABAP Forum.

BR

Sandeep

[Former Member]

First question to ask is :

a) <b>Why do we use Function Module in Update Task ?</b>

We need to do updates in different tables and they are organised as parts of a large update code. We need the update to happen as a whole or update should not happen at all. Atomicity rule - (A)CID.

When you mark a function module in update task, SAP update work process ensures the above.

b) <b>When is the Function Module called ?</b>

This function module is called as soon as a COMMIT WORK is encountered. So all function modules called with UPDATE TASK and subroutines with PERFORM ...ON COMMIT are called as soon as a COMMIT WORK statement is encountered. So if you have any processing below your call to FM , those statements would already be processed.

As from the above statements you can see that, having an EXPORT parameter makes no sense, as you can never use the value in that export parameter.

Hope this is clear to you.

Regards,

Subramanian V.

[Former Member]

Subramanian,

I'd like to add two things to your reply.

1) In order for the function module to be executed in update task (after COMMIT WORK), it has to called as follows:

CALL FUNCTION (name) IN UPDATE TASK

EXPORTING

... = ...

If the addition "IN UPDATE TASK" is omitted, the fm will be called instantaneously instead of after COMMIT WORK.

2) The main differences between PERFORM .. ON COMMIT and CALL FUNCTION ... IN UPDATE TASK are:

- A form registered with PERFORM ... ON COMMIT will be executed exactly once immediately after COMMIT WORK, no matter how often is has been called before the COMMIT.

A function module called IN UPDATE TASK is executed as many times as it was called.

- A form registered with PERFORM ... ON COMMIT has full access to the global data of its surrounding program (i.e. function group) and other data available in the internal mode in which is was called (other function groups, instances and static data of global classes).

A function module called IN UPDATE TASK is executed in a different internal mode and is isolated from these things.

- No parameters can be passed to a form registered with PERFORM ... ON COMMIT.

A function module called IN UPDATE TASK can be called with parameters.

So in order to bundle many data changes into few mass updates to be executed after COMMIT WORK, the following strategy works best:

A function group is implemented that records all the pending database operations (updates, deletes, inserts) in internal tables.

Instead of each individual update, delete, insert statement, the entries in the function group's memory are maintained via access function modules, and two form routines are called:

- perform ... on commit and

- perform ... on rollback.

The form routine to be called on commit is executed once after COMMIT WORK. It retrieves the list of pending database operations from the memory of its function group and calls a function module IN UPDATE TASK, passing the tables for insertions, deletions, and updates.

The function module performs mass database changes on the basis of its importing parameters (insert/update/delete .... from table ...).

The form routine to be called on rollback clears the tables of pending database operations so they won't be passed to the update function module during the next commit work.

Best regards,

Thorsten Franz