04-20-2008 10:52 AM
Hi All,
I am updating Material Master and I am getting locking issues intermittently.
Which is better of the 2 processes below or any new ideas?
PROCESS 1:
Loop at Material.
...BAPI_MATERIAL_SAVEDATA (Material BAPI)
...BAPI_OBJCL_CHANGE (Classifications BAPI)
...BAPI_TRANSACTION_COMMIT (WAIT = 'X')
...BAPI_MATINSPCTRL_SAVEREPLICA (Inspection Control BAPI --- This BAPI saves to the database)
...BDC for Classifications View (If not all required information is passed to BAPI_OBJCL_CHANGE, then we need this BDC.)
Endloop.
PROCESS 2:
Loop at Material.
...BAPI_MATERIAL_SAVEDATA (Material BAPI)
...BAPI_TRANSACTION_COMMIT (WAIT = 'X')
...BAPI_OBJCL_CHANGE (Classifications BAPI)
...BAPI_TRANSACTION_COMMIT (WAIT = 'X')
...BAPI_MATINSPCTRL_SAVEREPLICA (Inspection Control --- This BAPI saves to the database)
...BDC for Classifications View (If not all required information is passed to BAPI_OBJCL_CHANGE, then we need this BDC.)
Endloop.
Thanks for the help.
Riyaz
04-20-2008 11:40 AM
Hi Riyaz,
Obviuosly second one will be the best and safe way to go ahead. Once u do the commit then all the database locks will be released. So there will be no interdependency. Also If the data from the second BAPI should be updated only if the first BAPI is success the u can put the checks like below.(Bolded)
*Here read with A if there are no errors and read with X if there *
are no Aborts.
Loop at Material.
...BAPI_MATERIAL_SAVEDATA (Material BAPI)
READ TABLE i_return WITH KEY type = E, A ,X.
CHECK NOT sy-subrc IS INITIAL.
...BAPI_TRANSACTION_COMMIT (WAIT = 'X')
...BAPI_OBJCL_CHANGE (Classifications BAPI)
READ TABLE i_return WITH KEY type = E, A ,X.
CHECK NOT sy-subrc IS INITIAL.
...BAPI_TRANSACTION_COMMIT (WAIT = 'X')
...BAPI_MATINSPCTRL_SAVEREPLICA (Inspection Control --- This BAPI saves to the database)
READ TABLE i_return WITH KEY type = E, A ,X.
CHECK NOT sy-subrc IS INITIAL.
BAPI_TRANSACTION_COMMIT (WAIT = 'X')
...BDC for Classifications View (If not all required information is passed to BAPI_OBJCL_CHANGE, then we need this BDC.)
Endloop.
But here also there is a problem. Suppose ur first BAPI is success and second bapi fails then once u do the commit of first BAPI then u can't revert those changes(Because of second BAPI failed). So it solely depends on the requirement.
Hope this cleared ur doubts.
Thanks,
Vinod.
Edited by: Vinod Kumar Vemuru on Apr 20, 2008 4:13 PM
04-20-2008 11:40 AM
Hi Riyaz,
Obviuosly second one will be the best and safe way to go ahead. Once u do the commit then all the database locks will be released. So there will be no interdependency. Also If the data from the second BAPI should be updated only if the first BAPI is success the u can put the checks like below.(Bolded)
*Here read with A if there are no errors and read with X if there *
are no Aborts.
Loop at Material.
...BAPI_MATERIAL_SAVEDATA (Material BAPI)
READ TABLE i_return WITH KEY type = E, A ,X.
CHECK NOT sy-subrc IS INITIAL.
...BAPI_TRANSACTION_COMMIT (WAIT = 'X')
...BAPI_OBJCL_CHANGE (Classifications BAPI)
READ TABLE i_return WITH KEY type = E, A ,X.
CHECK NOT sy-subrc IS INITIAL.
...BAPI_TRANSACTION_COMMIT (WAIT = 'X')
...BAPI_MATINSPCTRL_SAVEREPLICA (Inspection Control --- This BAPI saves to the database)
READ TABLE i_return WITH KEY type = E, A ,X.
CHECK NOT sy-subrc IS INITIAL.
BAPI_TRANSACTION_COMMIT (WAIT = 'X')
...BDC for Classifications View (If not all required information is passed to BAPI_OBJCL_CHANGE, then we need this BDC.)
Endloop.
But here also there is a problem. Suppose ur first BAPI is success and second bapi fails then once u do the commit of first BAPI then u can't revert those changes(Because of second BAPI failed). So it solely depends on the requirement.
Hope this cleared ur doubts.
Thanks,
Vinod.
Edited by: Vinod Kumar Vemuru on Apr 20, 2008 4:13 PM
04-20-2008 4:20 PM
Hi,
Look at sm12 what object are locked.
Insert in you code checks for locks:
...
Do x times.
CALL FONCTION 'ENQUEUE.... (find lock object in se11)
IF sy-subrc ne 0. " locked
WAIT XX seconds.
ELSE.
CALL FONCTION 'DEQUEUE....
EXIT.
ENDDO.
...
Reward if helpful...
Cheers,
Varishtah.