Cannot cumulate lock within update task

[Former Member]

Hi,

I am writing a BAPI to update several materials asynchronously.

1. The BAPI will lock those materials for update by ENQUEUE_EMMARAE with scope 2

2. Calls another function module IN UPDATE TASK, which calls BAPI_MATERIAL_SAVEDATA several times to update those materials.

However, the BAPI_MATERIAL_SAVEDATA fails to accumulate the lock on EMMARAE and rejects the changes.

The BAPI is to return without waiting for the material changes, but block other change attempts in the mean time.

As a work around, I tried to release the lock in the FM before locking again, but it could not be done by DEQUEUE_ALL nor DEQUEUE_EMMARAE.

Please help.

Many thanks,

MF

[Former Member]

Hi

The lock should automatically be released after commit work, so you couldn't call several times the BAPI BAPI_MATERIAL_SAVEDATA without to call a commit for every call.

Max

[Former Member]

Hi Max,

Thanks for the reply.

I tried commit work in the FM. It caused update termination in the update task.

Please help.

MF

[Former Member]

HI M Fung,

1. Write COMMIT

and Dequeue for unlocking

(in the main program, not in the update FM)

(this will not give error)

(commit in update FM is not allowed at run time)

regards,

amit m.

[Former Member]

Hi Amit M,

I understand the commit to trigger the update FM and then dequeue for the FM to acquire the lock again. There is a small risk it may be lost to another process during the short release-and-lock.

Is there no other way to keep the original lock throughout ?

Many thanks,

MF

[Former Member]

Hi again,

1. Lets take this sequence

a) program logic

b) enqueue

update FM

Commit Work and Wait

dequeu

2. In above,

all the 4 statements in B

are executed immediately in sequence.

3. When update FM is called,

it does not execute immediate.

However,since the immediate next

statment is commit work and WAIT,

the update FM will execute (immediate now)

and after completion,

dequeu will be exectued.

4. I think this is the most shortest span

of time, in which u won't have any problem.

regards,

amit m.

[Former Member]

Hi Amit m,

Thanks again for the reply.

Let me see if i am getting this right.

When the update FM executes (in 3), the lock is held by the (1b) enqueue. The FM calls BAPI_MATERIAL_SAVEDATA, which tries to lock again and make the actual changes. Somehow, BAPI_MATERIAL_SAVEDATA fails to cumulate the lock here due to foreign lock. This is within the update FM due to 'commit and wait' before the 'dequeue'.

Please help.

Many many thanks,

MF

[Former Member]

Hi

Your problem is on BAPI_MATERIAL_SAVEDATA, because you have a process in UPDATE TASK where this fm is called severel times, but you do (I understood so) one only commit to run the process in UPDATE TASK.

Your flow should be:

BAPI_MATERIAL_SAVEDATA

commit and wait

BAPI_MATERIAL_SAVEDATA

commit and wait

......

In this way every lock is released after running BAPI.

but you can't do a commit statament in the update process, so I believe it would be better to run the process in update task for only one BAPI

Max

[Former Member]

Hi again,

1. BAPI_MATERIAL_SAVEDATA, which tries to lock again and make the actual changes

If this is so, then i don't think

we need to explcitly Enqueu/Deuque in our code.

The FM will automatically take care of it.

2. FM calls BAPI_MATERIAL_SAVEDATA,

Just after this use commit work and wait !

regards,

amit m.

[Former Member]

Hi,

1. The enqueue before BAPI_MATERIAL_SAVEDATA is to ensure the change should not fail due to another change lock in progress.

2. The whole idea is to commit but not wait, while blocking other attempts to the same materials before the update completion.

I wonder if there is a way to do this with ABAP.

Again, many thanks for the input and discussion.

MF

[Former Member]

Hi Max,

Thank you very much for your reply.

The whole purpose of the BAPI is to commit but not wait, and coordinates the master changes on several materials at the same time. If I can wait, I would have used your suggestion.

I split the lock and update into 2 tasks to ensure commit but no waiting. Update IN UPDATE TASK to inherit the lock. However, although the update task has ties to the lock, it is not exactly its owner, and could not acquire the lock again.

I think I am stuck here.

MF