Do I need to use COMMIT WORK even after execution of a Function Module?

[Former Member]

Hi Experts,

Let me clarify small doubts that, I knew that, I need to use COMMIT WORK immediately after any BAPI, to update the data base........so, Do I need to use the same COMMIT WORK even after a Func Module?

In my case, am parking the document with PRELIMINARY_POSTING_FB01 (= tx of FBV1)......so, after its execution Do I need to use COMMMIT WORK or not necessory?

repliaes appreciated

thanq

[Former Member]

When you Update or Insert data in Db then you should use COMMIT WORK to ensure that the entries are saved in DB.

Incase of BAPIs where data is being posted this is why we use COMMIT WORK.

In case of FMs also the same rule applies.

If you are creating a parfing document then it depends on the way you create it.

For example if you post Sales order using a BDC then there is no COMMIT WORK required as the transaction itself does it.

Revert if u need more.

[Former Member]

no need...because inside the FM PRELIMINARY_POSTING_FB01 ,they have done COMMIT WORK already.But if u want to ensure that the next step must execute only aftr updation then u can call FM IN UPDATE TASK.

CALL FUNCTION PRELIMINARY_POSTING_FB01 IN UPDATE TASK

[Former Member]

no u don't need to write COMMIT WORK after every FM . But with FM that effects database like updating it you should use it.

Even some BAPIs also have internal commit written for them so you don't need to write COMMIT WORK explicitly there also.

Thanx n Regards,

Vivek Gaur

Keep Rocking !!

[Former Member]

Hi

You use Bapi Trasaction commit work after the execution of function module.

Regards

Nagamani

[Former Member]

If there is database change , then you need to write commit.

[Former Member]

Hi SAP ABAPer ,

It's all about your transaction boundaries:

COMMIT WORK ends a SAP Logical unit of work (LUW) wich could be made of several database sessions.

If your BAPI covers a logical transaction a COMMIT WORK will

end the transaction and write all the changes to the database.

In case of failure a ROLLBACK WORK establishes the state BEFORE the transaction started.

As you might noticed a SAP LUW defines it's boundaries across several database transactions,

wich allows a better design for a complex business case transaction scenarios wich are not always correspond to the technical database transction boundaries. The undo values are stored in special SAP tables to restore the state in case of failure so they can survive the database commits.

The database handles it's transaction boundaries separatley (however, this does not mean SAP LUW and a db transaction can NOT have the same boundaries (it's up about your implementation):

Let's say we want to go in a BAPI from state A to B in a LUW :

BAPI starts
 SAP LUW starts from state A
                uses db session 1: tx starts - commits  - tx ends
                uses db session 2: tx starts - commits  - tx ends
                uses db session 3: tx starts - commits  - tx ends
 SAP LUW ends

 success:
      COMMIT WORK : all changes permanent defining state B

 failure:
     ROLLBACK WORK undo data from session 1- 3 to state A

BAPI ends


New BAPI starts state A or B 
....

bye

yk