Lock issue

[Former Member]

Hi ,

I am working on a change master material workflow,

first i am trying to lock my Engineering change number and then the material, below the code

CALL FUNCTION 'ENQUEUE_ECAENRE'

EXPORTING

mode_aenr = 'E'

mandt = sy-mandt

aennr = AENNR

x_aennr = ' '

_scope = '2'

_wait = ' '

_collect = ' '

EXCEPTIONS

foreign_lock = 1

system_failure = 2

OTHERS = 3.

if sy-sybrc = 0.

CALL FUNCTION 'ENQUEUE_EMMARAE'

EXPORTING

mode_mara = 'E'

mandt = sy-mandt

matnr = lv_material

x_matnr = ' '

_scope = '2'

_wait = ' '

_collect = ' '

EXCEPTIONS

foreign_lock = 1

system_failure = 2

OTHERS = 3.

if sy-sybrc = 0.

here i am updating my revision level of the material. after the update i am using commit work and wait (to wait till the updates are completed)

endif.

• once my update is done i am releasing the locks.

CALL FUNCTION 'DEQUEUE_EMMARAE'

EXPORTING

mode_mara = 'E'

mandt = sy-mandt

matnr = lv_material

x_matnr = ' '

_scope = '3'

_synchron = ' '

_collect = ' '.

CALL FUNCTION 'DEQUEUE_ECAENRE'

EXPORTING

mode_aenr = 'E'

mandt = sy-mandt

aennr = AENNR

x_aennr = ' '

_scope = '3'

_synchron = ' '

_collect = ' '.

All the above code is executed in one step.

when i am trying to lock my material one more time, i.e. in next subsequent step, the lock is getting failed. to resolve this i am current waiting for 2-3 min and executing the same step again , this time the locking is successful.

can any one tell me why is this happening, and why the immediate locking is not successful even after i used commit work and wait.

[Former Member]

Hi,

the system might need some time to unlock. Either because updates are done in parallel processes or any other reason. If you need to lock the same material again, then you can build a loop around the lock, something like

DO 300 TIMES.

CALL FUNCTION <enqueue>.

IF sy-subrc NE 0.

WAIT UP TO 1 SECONDS.

ELSE.

EXIT.

ENDIF.

ENDDO.

This will wait max. five minutes for the locks to be removed.

Roy

Edited by: RobbdB on Aug 17, 2011 9:33 AM

Edited by: RobbdB on Aug 17, 2011 9:33 AM

[Former Member]

As i told that i am currently waiting for 2-3 if lock is not successful, i am actually implementing the same logic as your do loop.

[Former Member]

Hi,

maybe you should change your lock concept: do not unlock the material after the COMMIT WORK if you need to lock it a second time. Set the _SCOPE parameter to '1' and unlock manually after you are done with the material.

Roy

[Former Member]

Hi,

Here i have to tell you one more thing, i haven't tried using scope as 1 but i tried the rest as you said with scope as 2.

step1: i locked it,

step2: i performed my first update

step3: performed my second update (here i cant combine my first updated and second update as i have some preconditions to validate in my workflow)

step4: unlocking

here, the function module responsible for the second update is actually returning zero, indicating update is successful but the data is not getting updated.

[Former Member]

Well,

if you leave the scope at '2' the commit work statement will delete the lock, so the second update will be done without the material being locked. Which should work fine technically, you only have the security issue.

My guess is that you actually need the first update to be complete before you can execute your second step. If that is the case, then you have no other logical option then to wait the 2/3 minutes.

Roy

[Former Member]

Thanks Roy,

I suspect the problem might be with enque workprocess, but not sure