Call function module IN Update Task

[Former Member]

Hi,

I have already read the forum posts about the update task addition and subsequent 'commit work', so please dont post links.

I am trying to update custom tables using statement -

MODIFY ZZ* from ITAB

. The enqueue and dequeue function modules are wrapped around the modify statement and this code is in a custom function module (called from a EDI user exit)

The values in this custom table are not getting updated sometimes and this has been a issue. To address this issue I have decided to call the custom function module using the addition 'IN UPDATE TASK' and commit the changes using COMMIT WORK in asynchronous mode.

CALL FUNCTION XXX IN UPDATE TASK
    EXPORTING XX
    TABLES      XX
  COMMIT WORK.

My question is - Does the COMMIT WORK statement commit only the LUW in the function module or could it commit all the pending changes of other LUW as well.

I am worried about using this statement since a COMMIT WORK in user exit could commit some VBAK or VBAP changes that should not have been committed.

[matt]

If, within the same transaction, other functions have been called in the update task, then they will also be triggered by COMMIT. It will not affect any other LUW.

You say: The values in this custom table are not getting updated sometimes

That worries me. It indicates that something is going wrong, and you don't know what, but you're attempting to fix it by rewriting your code. Before you can fix a problem, you have to know what caused it. Maybe the same problem would prevent calling your function module in the update task from working, sometimes.

[Clemenss]

Hi Grame,

saving data in update task is always the correct approach. You must not do COMMIT WORK in any kind of called function (user exit, BAdi etc.) because the [COMMIT WORK|http://help.sap.com/abapdocu_702/en/index.htm] will commit all pending database changes and trigger the start of all functions called in update task, executes all subroutines registered using PERFORM ON COMMIT, triggers an internal event for the persistence service of the Object Services, closes all database cursors,...

Usually, the calling application will COMMIT if everything has been done without error and ROLLBACK in case of any error. This helps to keep database consistency.

Just omit the [COMMIT WORK|http://help.sap.com/abapdocu_702/en/index.htm] and see that it works.

Note: As a rule of thumb, an LUW is started with a job, report, transaction, RFC call and is ended by the next interruption (screen, message, RFC call).

Regards,

Clemens

[matt]

> Note: As a rule of thumb, an LUW is started with a job, report, transaction, RFC call and is ended by the next interruption (screen, message, RFC call).

This is not quite right - or a bit misleading. The logical unit of work concept was established because you cannot rely on database locking to retain database integrity. It is specifically designed to cover multiple screens. For example, MM02 - allows you to update many screens before hitting save. It is the action of saving, in this instance, that closes that specific LUW.

But everything else Clemens said is absolutely correct.

[Former Member]

Hi,

I am checking the answers just now. Thanks a lot for the detailed replies.

This code is a part of a user exit in function module IDOC_INPUT_ORDERS. In case of large sales order with several line items, the custom table is not updated with all the input data from the IDOCs.

I am guessing that the asynchronous processing (with ENQUEUE and DEQUEUE locks) is causing these problems, hence I was considering the UPDATE TASK addition as a possible solution to this problem. I have removed the COMMIT WORK statement as per your suggestions (but still retained the UPDATE TASK addition).

Will let you know the results. Thank you.

[Former Member]

Hi Grame,

Clemens is right, you do not have to invoke a "COMMIT WORK" after you "call FM in Update task" statement, also an even more important thing is that you should not have a COMMIT WORK(or any statements that might invoke an IMPLICIT COMMIT...like call screen, wait etc) inside this FM that you are calling in an update task.

Regards,

Chen

[Former Member]

Hi Grame,

As you said that your custom table is not getting updated sometimes. Have you tried to rectify your piece of code before jumping onto the FM.

I guess the ABAP statement you have written is not correct, thats why your custom table is not getting updated.

I suggest you to rectify your modify statement with table addition for the internal table, as below:

Modify zz* from table ITAB.

Hope this will help you to resolve your issue.

BR,

Vinit