problem when using Call FM IN UPDATE TASK.

[larry_lv]

we plan to update ztable using Call FM in update task, and write the success/error message into log.

Does below is right?? I found the commit work can not be used here. Thanks..

_____________________________

CALL FUNCTION 'ENQUEUE_ETABLE'.

IF sy-subrc = 0.

CALL FUNCTION 'update_ztable'' IN UPDATE TASK.

Endif.

COMMIT WORK and wait.

IF sy-subrc <> 0.

ROLLBACK WORK.

write error log.

Else.

Write successful log.

Endif.

CALL FUNCTION 'DNQUEUE_ALL'.

[Former Member]

Hi,

roleback statement doen't work after commit .

use committ work before rolleback.

[larry_lv]

thanks jee, how about if uncomment the "rollback work" statement in program?? Does it works??

[Former Member]

hi,

it works try it.

[larry_lv]

thanks all, I will take a deep check and feedback soon.

[Former Member]

Hi ,

Please see the refernce of UPDATE FUNCTION MODULES:

-

---

UPDATE FUNCTION MODULE

-In the attributes tab, under processing type, choose Update Module,

Start Immediately. Define your import parameters, enter the source

code, All validations should have been done prior to the call to this

function module, so all you need in the source, is the updating of the

database, INSERT, MODIFY, UPDATE, whatever.

-When you call you function module, use IN UPDATE TASK, after the call,

COMMIT WORK. The commit work will trigger the db update.

Why do we use this " In Update Task " ??

The main update technique for bundling database changes in a single

database LUW is to use CALL FUNCTION... IN UPDATE TASK.

How do we Use ??

A typical R/3 installation contains dialog work processes and at least one update work process. The update work processes are responsible for updating the database. When an ABAP program reaches a COMMIT WORK statement, any function modules from CALL FUNCTION... IN UPDATE TASK statements are released for processing in an update work process. The dialog process does not wait for the update to finish. This kind of update is called asynchronous update.

What is the Use... ??

Asynchronous update is useful when response time from the transaction is critical, and the database updates themselves are so complex that they justify the extra system load

Real time scenario.

Suppose a user wants to change an entry in a database table, or add a new one. He or she enters the necessary data, and then starts the update process by choosing Save. This starts the following procedure in the ABAP program:

Firstly, the program locks the database entry against other users, using the enqueue work process (or the message server in the case of a distributed system). This generates an entry in the lock table. The user is informed whether the update was successful, or whether the lock could not be set because of other users.

If the lock is set, the program reads the entry that is to be changed and modifies it. If the user has created a new entry, the program checks whether a record with the same key values already exists.

In the current dialog work process, the program calls a function module using CALL FUNCTION... IN UPDATE TASK, and this writes the change details as an entry in table VBLOG.

When the program is finished (maybe after further dialog steps), a COMMIT WORK statement starts the final part of the SAP LUW. The work process that is processing the current dialog step starts an update work process.

Based on the information passed to it from the dialog work process, the update work process reads the log entries belonging to the SAP LUW from table VBLOG.

The update work process passes this data to the database for updating, and analyzes the return message from the database. If the update was successful, the update work process triggers a database commit after the last database change and deletes the log entries from table VBLOG.

If an error occurred, the update work process triggers a database rollback, leaves the log entries in table VBLOG, flags them as containing errors, and sends a SAPoffice message to the user, who should then inform the system administrator.

The corresponding entries in the lock table are reset by the update work process.

Q:We are calling Sales Order Change in update task inside the user Exit MV50FZ1. We can see that the FM is called in update task after the commit work and the return of the FM shows the success message. But still the changes are not saved to the DB.

A: check sm21 or sm13 to see if the update was successful .. In SM21 I checked. It is giving me the error Transaction Failed

-

---

Reward if useful

Thanks

Jagadeesh.G

[Former Member]

Hi Larry,

May i know why u said COMMIT WORK can not be used?

At the first place, do not explicitly code ROLLBACK WORK. Because it is being handled under your FM update_ztable. Basically u just need to launch a message type E in the FM if the DB operation fail.

Do you mind to paste your FM code here?

Thanks.

[larry_lv]

Hi abc,

no exception handling when using asynhronous update technique, please refer to PA BC414.