Application Development and Automation 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: 
Read only

BAPI Lock issue

Former Member
0 Likes
5,507

Hi,

     In my program i use two bapi one by one . BAPI_PRODORDCONF_GET_HDR_PROP to get production order details. then i use

BAPI_PRODORDCONF_CREATE_HDR' to do order confirmation . I use commit bapi after each bapi call with wait = 'x' . But still i get the below error very frequently

"Order 1000435 is already being processed by SHANEK" .I could not figure out why this lock error occur every time.

Thanks,

Srini

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
3,688

Material availability check job was running ..that was causing this lock issue..SAP standard behavior.

17 REPLIES 17
Read only

Former Member
0 Likes
3,688

Hi,

Did you try calling ENQUE and DEQUE function modules before and after the BAPI?

Regards,

Vidya.

Read only

0 Likes
3,688

hi...

      No i dont use enque and deque FM

Thanks.

Read only

Former Member
0 Likes
3,688

Hello Srinivas ,

The only possible reason i can think of is : ABAP Runtime "DUMP"..can you check in the target system using transaction ST22 that , Is there any runtime errors exist?( which is restricting unlocking of the order )

Thanks

~Raj

Read only

Former Member
0 Likes
3,688

srini, generally this issue should not occur when we use commit and wait. please do check whether u really need commit bapi after first bapi. if you need it, then check in debug mode what is happenning after first commit. if you say everything is quite good and yet you are facing the same problem, then you have to increase wait time (but this should be your last option.)

regards

satish chandra

Read only

former_member189779
Active Contributor
0 Likes
3,688

Check SAP Note 208477. This problem is described.

Read only

0 Likes
3,688

That note was helpful.But my doubt is confirmation is done by differenct user but error thrown is for user shanek . He did not actually use the custom program to do Confirmation !

Read only

0 Likes
3,688

May be check if there are any background task running at same time frame for different user. Or check in SM58 any TRFCS processing at the same time.

Read only

Former Member
0 Likes
3,688

Hi all,

          Lock issue still exist. I even saw this lock error in CO11 when doing order confirmation . So its not related to program . There is only one background job that runs on this name and that too for 15 sec once a day . So that wont be the cause. We even asked that user to stop logging into PRD system for one day . Even on that day we got this lock error in co11 screen . Please advice .

Thanks
Srini

Read only

Clemenss
Active Contributor
0 Likes
3,688

Hi,

you may first determine if it is a temporary or permanent lock. Identify the lock object in question. Try to lock using enqueue function in a loop until successful, then dequeue. Then call BAPI.

Count the loops, exit with error after too many (say 1 million) loops or too long loop time.

Regards,

Clemens

Read only

Former Member
0 Likes
3,688

Its a temporary lock . It will be there for only 5-10 sec..What you have suggested is a good idea.I will implement that . But how do i find what is locking the order? which process of that user is causing this issue. If i find that i will ask the user to stop doing that when doing confirmation . This error even occurred when user did not log on system for the entire day .

Thanks,
Srini

Read only

Clemenss
Active Contributor
0 Likes
3,688

Actually, I do not fully understand all the update and locking secrets. For example, there are so-called second-level update processes that will start not directly with commit work but some (?) time later. As far as I know, these are used for statistics update like i.e. LIS. I don't know if these second level-updates keep or even set any locks. For my understanding, BAPI_COMMIT with wait = 'X' waits for first level update process only.

Also, user exit or BAdI or SAP event coupling may trigger processes in background that trigger locking.

Anyway - you can't always solve all miracles. Just wait in a (limited) loop for the locks being released and then continue. If it does not put too much harm on performance, just let it be.

Eventually, FM GET_ENQUEUE_DETAILS may help do find out more about the lock, i.e. transaction where.it was set from.

Regards

Clemens

Read only

Former Member
0 Likes
3,688

Check if there is some custom development (enhancement, exit, etc) raising a process in background.

Regards,

Felipe

Read only

Former Member
0 Likes
3,688

Hi all,

        I almost narrowed down the issue. For every 5 minutes i can see many records getting into lock table in that user name . SM12 showed me the lock table entries. No background job in his name. I am wondering what might trigger the process(not sure which process) for every 5 minutes. SM12 did not give me tcode .information

1 sample record ,

ClientUser nameTime......Lock modeTableArgumentUse Count.Use Count.
700SHANEK17:10:55EAUFK70000000100000010

Thanks,
Srini

Read only

Former Member
0 Likes
3,688

Hi all,

          I found the reason for locking of production order.There is a job running for every 15 minutes and it is locking more order during its process. I switched off the job and now no lock error. But this job has to run ,so i need to find a way to suppress the lock ..

Program in the job - PPIO_ENTRY - This program is to do availability check materials. So its locking all the production order during its process.

How do i suppress the locking in the above mentioned program

Thanks,
Srini

Read only

0 Likes
3,688

Just lock yourself the order (with _WAIT parameter) before calling the BAPI. (Of course the background job must do the same.

Regards,

Raymond

Read only

0 Likes
3,688

If the order is being locked by job ,how would i be able to lock it using _wait .You mean to say that program has to wait until the job releases the lock. Thanks.

Read only

Former Member
0 Likes
3,689

Material availability check job was running ..that was causing this lock issue..SAP standard behavior.