Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Commit work

Former Member
0 Likes
984

Hello Friends,

This is not yet another cross post on commit work. I have a doubt and could not get clear picture in SDN as well as documentation.

There is a general perception that COMMIT WORK must not be used inside user exit .

But how about calling a method from user exit and doing a commit work after performing a series of actions in that method.

Comradely,

K.Sibi

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
843

We don't do explicit COMMIT WORK commands in exits, or in any code used in an SAP transaction that updates the database, for one very important reason: COMMIT WORK "flushes" the update queue for the user context, shoving all the queued up updates to the database, regardless of whether or not the SAP transaction has completed all the internal table and structure builds, etc., necessary for a complete, correct database update.

A commit work in a report may be (relatively) harmless, but in an SAP update transaction, one can cause some real damage (but often just causing an abend and rollback and loss of everything the user has just entered) by inserting an explicit commit work or by writing code that results in SAP issuing a commit work at the wrong place or time. Let SAP's update programming control the COMMIT WORK process.

On the other hand, COMMIT WORK (perhaps through the COMMIT BAPI) is sometimes necessary, in cases like:

.... code

transaction or bapi call

..... more code

transaction or bapi call

COMMIT WORK... "need a document number and values just created for next step...

....more code

another transaction or bapi call....etc.

7 REPLIES 7
Read only

Former Member
0 Likes
844

We don't do explicit COMMIT WORK commands in exits, or in any code used in an SAP transaction that updates the database, for one very important reason: COMMIT WORK "flushes" the update queue for the user context, shoving all the queued up updates to the database, regardless of whether or not the SAP transaction has completed all the internal table and structure builds, etc., necessary for a complete, correct database update.

A commit work in a report may be (relatively) harmless, but in an SAP update transaction, one can cause some real damage (but often just causing an abend and rollback and loss of everything the user has just entered) by inserting an explicit commit work or by writing code that results in SAP issuing a commit work at the wrong place or time. Let SAP's update programming control the COMMIT WORK process.

On the other hand, COMMIT WORK (perhaps through the COMMIT BAPI) is sometimes necessary, in cases like:

.... code

transaction or bapi call

..... more code

transaction or bapi call

COMMIT WORK... "need a document number and values just created for next step...

....more code

another transaction or bapi call....etc.

Read only

kesavadas_thekkillath
Active Contributor
0 Likes
843

HI a transaction flow must adhere to its ACID properties.

Atomicity,Consistency,.......

The ACID properties of a DBMS allow safe sharing of data

and also you may be aware of the states of transaction

like start,rollback,commit,abort......

In the transaction flow diagram the commit state comes at last.

Just think if you give a commit work in between the flow and if the data gets replicated in db

and if the transaction gets aborted after the exit, does this make any sense.

In the transactional states the rollback state always comes before commit state.

Its not possible to roll back after a commit state.

You can get these details in any of the RDBMS books available.

As far as i knoe Its not recommended to give a commit in between a transactional flow( ex:in bapi,exits,badi etc )

Forum members : please correct me if im wrong.

Read only

Former Member
0 Likes
843

Hi dave and keshav,

Thanks for your valuable reply .

I would explain the scenario in more detail.

I am writing a FM to update the status of the IDOC using' IDOC_STATUS_WRITE_TO_DATABASE' , since its not reflecting without a commit work , I am have added it .

Another thing is that i am using MODIFY custom database table based on some values of processing and even though the sy-subrc is returned as 0 and there is no change in the table , i was forced to use a commit work.

If there are any other alternative , please let me know .

Comradely ,

K.Sibi

Read only

0 Likes
843

Hi,

Make your FM as RFC enabled and call the FM using BACKGROUND TASK addition. This make sures that your IDOC and Z-table won't be updated in case of transaction is not saved because of some errors. Else even if your transaction is not saved, IDOC and Z-table will be updated which is not a correct way i feel.

You can try by calling the FM in UPDATE TASK as well. (Make the FM as UPDATE Module in attributes).

Thanks,

Vinod.

Read only

0 Likes
843

Hello Vinod,

Sorry for the inconvenience , its not a FM which i am writing .

Its a method .

Comraely ,

K.Sibi

Read only

0 Likes
843

Hi,

No problem. Create a new Z-FM with the same interface and call your method inside the Z-FM.

Thanks,

Vinod.

Read only

anup_deshmukh4
Active Contributor
0 Likes
843

Try using the additin IN UPDATE TASK for the function module ...!