2021 Sep 06 3:49 PM
hi,
I am getting below error like :
The plant data of the material <XXXX is locked by the user <XXXX>
My requirement is kind of Creating Reservations using Bapi and doing changes.
After posting inbound delivery one badi will trigger. here on FM is triggering in background task.
Imagine i have 3 batch split in Inbound delivery. (which means 3 lines)
So. badi will triggers.
in loop.(3 lines are there from inbound delivery)
Fm will trigger. 3 times in background task.
endloop.
In Fm (total 3 lines inbound having 3 lines.).
For 1st line of inbound. (loop1)
below Bapi calling 2 times. (line 1 having 2 diff movement types creating 1 after another immediately)
movement type .Fixed in coding.
BAPI_RESERVATION_CREATE1
movement type. Fixed in Coding.
BAPI_RESERVATION_CREATE1
Note: Here Should i call bapi commit statement.
2nd line of Inbound delivery .(loop2) (Changing the reservation bcz already reservation exists)
BAPI_RESERVATION_CHANGE
3rd line of Inbound delivery (loop3)(Changing the reservation bcz already reservation exists)
BAPI_RESERVATION_CHANGE
Note: If i run the Fm (background task) in debug mode (enable TRFC enabled ) and in Sm58 I am checking. If i check i am not getting any error. without debug mode i am getting error. this is also not every time. Some times i am getting. After line 1 ... I am thinking can i call Bapi Commit Statement. Do u think is it wrong. Bcz. After line1 .. again line 2 and 3 will be there.. here again using 'Bapi_Reservation_Change',
calling 2 times for line 2 and 3. Need suggestions. Where exactly i need to put commit Statement.
Note: 1)I tried. wait up to 3 seconds.. after each time calling 'Bapis' But not worked.
2)I am sure ,, i am not opening any screen which is belongs to material , which is using in Bapi.
all screens are closed. and sm12 also i am checking... have not found anything.
2021 Sep 06 4:42 PM
Check the error message and try to determine the lock object. Then add to your program a DO loop to check for it until the lock is over or some time has passed.
When you debug, the process works because you are delaying it enough to allow the system to finish its work and release the lock, I guess.
2021 Sep 06 5:11 PM
Hello,
you should never call Commit Worki or BAPI_COMMIT_WORK during Badi or User-Exit Call.
If I want a special action to be processed after Delivery created/ changed/ GI posted I am using the Workflow-System. I let the system trigger Workflow-Event using the message output.
Another possibility would be not to call the FM in background but in update task, then it will get processed one after the other in the update process and they're normally sharing the lock item.
Regards
Holger
2021 Sep 07 2:59 PM
The OP call some BAPI, calling them in update task is IMHO not a good option?
2021 Sep 15 10:56 AM
The primary FM is a normal Z-Function ... why should it be a bad option to call it in update task ... don't misunderstand me its not that I do not believe what you're telling me. I only want to extend my knowledge because I already did this in the past and I did not see any risks or problems.
2021 Sep 07 3:09 PM
You could/should execute a COMMIT WORK (BAPI_TRANSACTION_COMMIT) with the WAIT option between the BAPI call, or explicitally lock the records yourself (in a LOOP with _WAIT option) but you must in the second case first identify the locked object, so the ENQUEUE FM to call. ( e.g. ENQUEUE_EMMARC, ENQUEUE_ECKMLMV_VVERSS or some others)
2021 Sep 08 11:04 AM
thanks for your reply...
I tried...
bapi_transaction_commit. Before calling two bapis... continuously..
Still causing the issue.
and i found the obejct sm12.. which is causing the issue. It is Marc obejct.. so need to pass
sy-mandt and material and plant combination.... then need to check using
ENQUEUE_READ Fm. like below.
luckily in debug mode.. I got the lock . Even after 10 times also . the log was not Delete after wait up to 2 seconds...
So, can i increase the lock. do 20 to 30 times... Dynamically don't want to put the do n times.
thinking it may go to infinite loops. in some conditions... just thinking... do u think it will unlock if i put 20 30 times... automatically...
2021 Sep 13 3:46 PM
I wouldn't use the ENQUEUE_READ and a WAIT UP with a fixed duration within the loop, but the ENQUEUE_EMMARC with the WAIT option (DEQUEUE when successful).
2021 Sep 13 4:57 AM
Sorry, I'm not sure I understand exactly your case, and I'm not sure other people do. Only COMMIT WORK can start a background task. At the time of COMMIT WORK it starts asynchronously the function modules called in tRFC. You can't know when it's finished.
What I assume you are doing:
------
1) You post an inbound delivery (VL31N?)
------
2) Your BAdI implementation (which one? which method?) is called once and does:
LOOP AT the 3 lines of inbound delivery.
CALL FUNCTION 'ZFM' IN BACKGROUND TASK ...
ENDLOOP.
NB: the standard will do the COMMIT WORK, which starts ZFM three times asynchronously.
------
3) Your ZFM does:
IF first line of inbound delivery
CALL FUNCTION 'BAPI_RESERVATION_CREATE1' ... movement type 1
CALL FUNCTION 'BAPI_RESERVATION_CREATE1' ... movement type 2
ELSE.
CALL FUNCTION 'BAPI_RESERVATION_CHANGE' ...
ENDIF.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' EXPORTING wait = 'X'.
------
Which one sends error "The plant data of the material <XXXX is locked by the user <XXXX>"?
I guess that maybe you have conflicts between the update tasks of the 2 ZFM running at the same time.
Maybe you should serialize the 2 calls (bgRFC, inbound queue) so that they execute sequentially.
Or simpler solution maybe, can't you call ZFM only once, to process all three lines? (by using another BAdI method which runs once)