Application Development 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: 

Need suggestions Object is locking while calling Bapis..

former_member196331
Active Contributor
0 Kudos

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.

8 REPLIES 8

VXLozano
Active Contributor
0 Kudos

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.

hohoman
Active Participant
0 Kudos

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

0 Kudos

The OP call some BAPI, calling them in update task is IMHO not a good option?

hohoman
Active Participant
0 Kudos

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.

raymond_giuseppi
Active Contributor
0 Kudos

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)

0 Kudos

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...

0 Kudos

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).

  • Have you checked with the system admins to see if there are any performance issues causing a long delay that could be easily solved?
  • Did you add the WAIT option to the BAPI Commit?

Sandra_Rossi
Active Contributor
0 Kudos

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)