Regarding Lock before BAPI

[former_member591635]

Hi,

I am using on FM: BAPI_BATCH_SAVE_REPLICA to change the order status from restricted to unrestricted.

I want to implement a lock before that and then unlock it afterwards.

How shall I do that?

Thanks.

[franois_henrotte]

This BAPI creates a new batch based on an existing one, so I don't see why/how to lock the new batch that is not yet created.

Am I missing something ?

[former_member591635]

Hi Francois, thanks for replying.

We are using the BAPI just to change the work order status from Restricted to Unrestricted.

This is the code:

IF ls_batchstatus-restricted EQ abap_true.

ls_batchstatus-restricted = ' '.
ls_batchstatusx-restricted = abap_true.

CALL FUNCTION 'BAPI_BATCH_SAVE_REPLICA'
EXPORTING
material = ps_outtab-matnr
batch = ps_outtab-charg
batchstatus = ls_batchstatus
batchstatusx = ls_batchstatusx.

but the thing is, sometimes I'm getting the message as "BATCH XXX OF MATERIAL XXX IS ALREADY LOCKED BY <User Name>". and if I just press ENTER, it is getting accepted.

So when that's why I thought this must be a lock issue. I tested with "Wait up to 5 seconds" and it's working fine but it's not good practice to write a code like this. Hence want to add locks before and after that FM call.

[franois_henrotte]

OK then you just have to use this FMto enqueue the batch (it gives error if already locked) :

VB_ENQUEUE_BATCH

[former_member591635]

Okay, so

Fm - VB_ENQUEUE_BATCH

and then FM - BAPI_BATCH_SAVE_REPLICA' call.

later, FM - VB_DEQUEUE_BATCH

Is this correct ?

[franois_henrotte]

Yes 🙂

And don't forget to commit.

[former_member591635]

Hey, got the same message still.

If I debug that FM, just for 10 sec(without changing anything) then no issues but if I execute directly then that message again.

[former_member591635]

All right, thank you so mcuh.

[former_member591635]

Hey, got the same message still.

If I debug that FM, just for 10 sec(without changing anything) then no issues but if I execute directly then that message again.

[RaymondGiuseppi]

Could you try to replace the call of VB_ENQUEUE_BATCH with a call of ENQUEUE_EMMCH1E (or ENQUEUE_EMMCHA) using the _WAIT parameter and/or wrap this request for lock in some do loop, which would be better than a wild WAIT UP TO n SECONDS. The COMMIT or ROLLBACK WORK (or BAPI_TRANSACTION_*) will remove the lock.

Question: under what circumstances are you calling the BAPI, in some BAdI at save/end of a transaction, in this case did you consider calling the BAPI in BACKGROUND UNIT/TASKto insure execution after previous transaction changes commited to database and locks removed?

[franois_henrotte]

Hi,

If you think that the batch should be unlocked, you have still the possibility to call function DEQUEUE_ALL before you start your processing.

About the call of a BAPI in background task, it may be necessary if you call it in an update task (the commit would generate a dump) but it does not seem to be the case here. However you can also try to use SET UPDATE TASK LOCAL before you call the BAPI and do the commit.

BR