‎2009 Aug 06 6:15 AM
Hi Experts,
Why should not use COMMIT WORK in BAPI ? If I give COMMIT WORK in BAPI what is will happen?
‎2009 Aug 06 6:19 AM
Hi buddula1 5 ,
if we give commit work after bapi it will update the database
other wise we wont get proper output
‎2009 Aug 06 6:29 AM
‎2009 Aug 06 6:31 AM
‎2009 Aug 06 6:33 AM
Hi ,
Please check my thread , i have mentioned the solution and the final outcome of it.
My Thread number is :
it is a part of the BAPI programming model that BAPIs use a certain transaction model. This transaction model says that one BAPI has to follow the so called ACID (atomar, consistent, isolated, durable) principle. To ensure that a BAPI is atomar you cannot put a commit work just anywhere in mid of a BAPI as this would violate the modell. Furthermore BAPIs shall allow external commit handling that means it has to be possible to include several BAPI calls in one LUW. For this there are BAPIs which are only for committing or rolling back a transaction. For more detailed information you can check as usual the SAP help click me
If would suppose that when you throw a workflow event it is triggered once the LUW is closed. At least SAP should work that way. But I have to admit in newer ABAP OO developments SAP often just calls the Event raising function module with the option to not wait for the DB commit. Seems there are some problems with the newer LUW concepts / OO and the old workflow technology. This can lead in worst case to events raised for objects which were rolled back later but SAP seems to accept that so it is in my oppinion an acceptable solution.
Hope that helps a bit
‎2009 Aug 06 6:34 AM
‎2009 Aug 06 6:41 AM
Hi,
1. Why should not use COMMIT WORK in BAPI
I suppose you are asking this in context of Z BAPI and not standard BAPI.
The reason why we should not use is bcos SAP has recommended the design for BAPI in that manner.
2. If I give COMMIT WORK in BAPI what is will happen?
Well, as such there is nothing wrong going to happen. (Unless there is some dependent update in database)
To give you an example.
Suppose we have to update ZTABLE1 and ZTABLE2- the code for which is in TWO SEPARATE BAPIs.
Also it is requierd that if one fails, then other should not get updated. Either All or Either None case.
ZBAPI1 - TABLE1
ZBAPI2 - TABLE2
If ZBAPI1 is called and we have written commit work inside that, TABLE1 will get updated.
Then if there is any error in ZBAPI2, then TABLE2 will not get updated in hence the information will be INCONSISTENT.
3. Hence, the flow should be like this; (No commit work inside the bapi)
Main Program.
Call ZBAPI1.
Call ZBAPI2.
COMMIT WORK.
This will ensure that ALL or NONE happens.
regards,
amit m.
‎2009 Aug 06 6:42 AM
Hi,
We use COMMIT WORK outside the BAPI to create one LUW for updating the database instead of Calling COMMIT WORK several times for multiple line items if it is used with in the BAPI.
E.g. Say you are creating many sales orders using a BAPI, so one sales order would have many line items .
while using this BAPI if you COMMIT inside the BAPI this would update the database each time after passing the line item details. to avoid this we generally use COMMIT after populating all the details and out side of BAPI.
The othe use is ROLL BACK is much easier in case of any problems.
Hope this helps you.
Regards,
Raghavendra
‎2009 Aug 06 6:43 AM
Hi,
In simple terms , generally BAPI are called from outside (R/3) so , if you have put COMMIT WORK inside that BAPI , it will end that LUW butmay be from where it was called (for eg Webdynpro) is still not been completely processed.
Since you have put commit work and let say,with that BAPI you are Updating DB than data will be saved irrespective of whether Webdynpro transaction is completed or not.
If your ZBAPI is only called in R/3 than you can Put Commit work.
Regards,
Mayank
‎2009 Aug 06 7:02 AM
Hi Buddul1 5,
COMMIT WORK is required to update the database.
it is not required for all BAPI but for some BAPI it is required.
sometimes you can find that in bapi return parameter you are getting success message & document have been created but if you go to table you can find out that document.
That is why commit work is required.
But don't use commit work for BAPI.
after calling the BAPI, use FM: BAPI_TRANSACTION_COMMIT
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
WAIT = 'X'
IMPORTING
RETURN =
.
Hope you understand well.
Regards,
Tutun