topic Re: User lock issue in BAPI BAPI_PRODORD_CHANGE in Application Development and Automation Discussions

User lock issue in BAPI BAPI_PRODORD_CHANGE

jagesh_lakdawala — Tue, 01 Oct 2013 11:42:29 GMT

Hello experts,

I have used the BAPI BAPI_PRODORD_CHANGE for updating the PO quantity within the Loop.

as per this BAPI's documentation, have not used the COMMIT BAPI after PO change BAPI.

after this BAPI execution, there is also CO02 BDC being used for changing the PO status within the same Loop statement.

Problem is now during the CO02 BDC execution, error comes as 'PO is being used by User_name'.basically this is the PO locking error for the same user id. This is happening only for few PO's and not for all.

please suggest me for resolving this issue.

Regards,

Jagesh

Re: User lock issue in BAPI BAPI_PRODORD_CHANGE

Arun_Prabhu_K — Tue, 01 Oct 2013 11:47:19 GMT

Hello Jagesh.

Why using BAPI and BDC to perform two different CO02 operations?

May be you can use BDC to do both the operations OR

Try with the statements COMMIT WORK AND WAIT or WAIT UP TO N SECONDS (N-1,2..etc) before calling BDC.

Regards.

Re: User lock issue in BAPI BAPI_PRODORD_CHANGE

Former Member — Tue, 01 Oct 2013 11:53:43 GMT

Hi,

Try passing WAIT = 'X' to the BAPI_TRANSACTION_COMMIT FM.

Re: User lock issue in BAPI BAPI_PRODORD_CHANGE

PeterJonker — Tue, 01 Oct 2013 12:03:37 GMT

Sounds like the order is still locked from the bapi call. I suggest to use statement WAIT UP TO 2 SECONDS

(or 3) and see if the problem persists.

Re: User lock issue in BAPI BAPI_PRODORD_CHANGE

jagesh_lakdawala — Tue, 01 Oct 2013 12:08:12 GMT

Hi,

I have used the seperate BDC for CO02 because PO change BAPI does not allow to change the PO status.

as per the PO CHange BAPI Documentation in SE37, we must not have to use the COMMIT BAPI after it so i havent used it.

Issue with the WAIT statement is it will put the delay in program.

Thanks for your reply.

Regards,

Jagesh

Re: User lock issue in BAPI BAPI_PRODORD_CHANGE

former_member201275 — Tue, 01 Oct 2013 12:33:06 GMT

Maybe you can check if it is locked or not:

http://scn.sap.com/thread/1097281

Re: User lock issue in BAPI BAPI_PRODORD_CHANGE

Former Member — Wed, 02 Oct 2013 03:27:18 GMT

Use BAPI STATUS_CHANGE_EXTERN to change the user status.

Re: User lock issue in BAPI BAPI_PRODORD_CHANGE

RaymondGiuseppi — Wed, 02 Oct 2013 07:47:38 GMT

as per the PO CHange BAPI Documentation in SE37, we must not have to use the COMMIT BAPI after it so i havent used it.

Can you post your version of documentation, this is surprising...

You should (must) either

Use a COMMIT WORK AND WAIT (or BAPI_TRANSACTION_COMMIT) if you immediately execute another operation on the order with CALL TRANSACTION.
Call also BAPI_PRODORD_SETUSERSTATUS, for external statuses, or, for internal status, BAPI like BAPI_PRODORD_RELEASE, BAPI_PRODORD_COMPLETE_TECH, BAPI_PRODORD_CLOSE, etc. and then a COMMIT WORK to commit both bapi.

Regards,

Raymond

Re: User lock issue in BAPI BAPI_PRODORD_CHANGE

Former Member — Wed, 02 Oct 2013 08:15:13 GMT

Hi Jagesh,

Even if its written in Documentation.... try with BAPI_TRANSACTION_COMMIT and pass wait = 'X'.

This may take less time than "wait for 2 or 3 seconds" statement. Then probably after execution, your BDC will not give this lock error.

Thanks,

Sumit

Re: User lock issue in BAPI BAPI_PRODORD_CHANGE

former_member201275 — Wed, 02 Oct 2013 08:35:20 GMT

Hi Jagesh,

Were any of the replies helpful, or solve your issue?

Re: User lock issue in BAPI BAPI_PRODORD_CHANGE

jagesh_lakdawala — Wed, 02 Oct 2013 09:44:18 GMT

Hi Anthony,

Initially i used the BAPI_TRANSACTION_COMMIT as well and then also i was getting the locking error in subsequent BDC execution.

Presently for a solution, i have used the FM ENQUEUE_ESORDER just before the CO02 BDC execution, if SY-SUBRC is not equal to 0 then i am using the WAIT UP TO 5 seconds statement and it is working fine for me so far.

Regards,

Jagesh

Re: User lock issue in BAPI BAPI_PRODORD_CHANGE

RaymondGiuseppi — Wed, 02 Oct 2013 10:00:42 GMT

Initially i used the BAPI_TRANSACTION_COMMIT as well and then also i was getting the locking error in subsequent BDC execution.

Did you set the WAIT parameter ?

5 seconds is too much (imagine when a huge batch of orders is to be processed....) I would suggest set of the _wait parameter in the enqueue FM and wait only 1 seconds in a DO/ENDDO loop (or do not wait at all as the lock attempt will wait itself).

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
   EXPORTING
     wait   = abap_true
   IMPORTING
     return = return.
 * Check return table also here
 DO.
   CALL FUNCTION 'ENQUEUE_ESORDER'
     EXPORTING
       aufnr  = lv_aufnr
       _wait  = abap_true
     EXCEPTIONS
       OTHERS = 1.
   IF sy-subrc EQ 0.
     CALL FUNCTION 'DEQUEUE_ESORDER'
       EXPORTING
         aufnr = lv_aufnr.
     EXIT.
   ENDIF.
 *  WAIT UP TO 1 SECONDS.
 ENDDO.

You did not try to call BAPI_PRODORD_CHANGE and BAPI_PRODORD_SETUSERSTATUS before a sibngle BAPI_TRANSACTION_COMMIT ?

Regards,

Raymond

Re: User lock issue in BAPI BAPI_PRODORD_CHANGE

jagesh_lakdawala — Wed, 02 Oct 2013 10:52:33 GMT

Hi,

Thanks for your reply and agree with your toughts that using the WAIT statement is going to put the 5 seconds of static delay for every locking.

i didnt use the WAIT parameter along with the COMMIT BAPI.

hence i am replacing the existing coding with the below one.

DO.
CALL FUNCTION 'ENQUEUE_ESORDER'
      EXPORTING
        AUFNR          = P_AUFNR
      EXCEPTIONS
        FOREIGN_LOCK   = 1
        SYSTEM_FAILURE = 2
        OTHERS         = 3.
    IF SY-SUBRC <> 0.         "Not equal to 0 means PO is found Lock here
      LD_COUNTER = LD_COUNTER + 1.
      CALL FUNCTION 'DEQUEUE_ESORDER'   "Try to unlock the locked PO
        EXPORTING
          aufnr = P_AUFNR.
      IF LD_COUNTER GE 5.
        EXIT.
      ENDIF.
    ELSE.
      EXIT.
    ENDIF.
ENDDO.

Regards,

Jagesh

Re: User lock issue in BAPI BAPI_PRODORD_CHANGE

former_member201275 — Wed, 02 Oct 2013 11:56:46 GMT

Okay, great. Just asked because i see your question is still open on the forum.