Regarding execution of bapi for goods movement creation - Commit / Self locking

[Former Member]

Hi,

In our programs we are using the bapi  BAPI_GOODSMVT_CREATE  to post the goods movement for different movement types. We are processing this bapi inside a loop . Inside the loop after each bapi call we are doing the commit work by executing the function module BAPI_TRANSACTION_COMMIT.

Problem:-

We are getting material locking issue inside the loop as we are using the same material, batch in the loop for creating different goods mvmt for multiple times.

Steps we tried for resolution:-

1. We added SET UPDATE TASK LOCAL before calling the Goods Mvmt Bapi.

2. Call the bapi Bapi_Transaction_commit to commit the changes as below.

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'

     EXPORTING

       wait = abap_true.

3. Used the wait statement to hold the processing for some time to clear the buffer / locks.

WAIT UP TO 4 SECONDS.

After doing all this we found very less issues with self locking inside the loop, but still getting some locking issues some times not every time may be when CPU have load request / peak load and in some unidentifiable times also.

Now my request is :-

We tried all the above options by googling and some other member's inputs. This time I am looking to get actual underlying architecture in this process. So that I want to fix the issue on permanent basis.

1.could you please anyone help me what will be the actual memory / locks processing in executing a bapi,

2. Why Set update task local is required?

3. Why wait statement is required?

4. When and how locks will be released / created ?

5. How to check after each bapi call for goods mvmt, how can I check that the current bapi call commited successfully and released l

Regards,

Chitturi.

[Former Member]

Hi,

In our programs we are using the bapi  BAPI_GOODSMVT_CREATE  to post the goods movement for different movement types. We are processing this bapi inside a loop . Inside the loop after each bapi call we are doing the commit work by executing the function module BAPI_TRANSACTION_COMMIT.

Problem:-

We are getting material locking issue inside the loop as we are using the same material, batch in the loop for creating different goods mvmt for multiple times.

Steps we tried for resolution:-

1. We added SET UPDATE TASK LOCAL before calling the Goods Mvmt Bapi.

2. Call the bapi Bapi_Transaction_commit to commit the changes as below.

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'

     EXPORTING

       wait = abap_true.

3. Used the wait statement to hold the processing for some time to clear the buffer / locks.

WAIT UP TO 4 SECONDS.

After doing all this we found very less issues with self locking inside the loop, but still getting some locking issues some times not every time may be when CPU have load request / peak load and in some unidentifiable times also.

Now my request is :-

We tried all the above options by googling and some other member's inputs. This time I am looking to get actual underlying architecture in this process. So that I want to fix the issue on permanent basis.

1.could you please anyone help me what will be the actual memory / locks processing in executing a bapi,

2. Why Set update task local is required?

3. Why wait statement is required?

4. When and how locks will be released / created ?

5. How to check after each bapi call for goods mvmt, how can I check that the current bapi call commited successfully and released l

Regards,

Chitturi.

[Former Member]

Hi,

May be this would help:

1)trace execution with st01 and figure out which locks created during execution.

2)insert code in your program that checks locks exists (FM ENQUEUE_READ)

inside loop (with wait 1 sec for example) until all locks released.

Best regards,

Nick.

[Former Member]

Hi Nick,

Thank your points mentioned.

Now I am looking to know the underlying architecture in data processing rather than solution. As of now we are not getting the issue all the times with the same data. i.e. when I am trying to post the data now sometimes it is getting the locking issue but not every time. That is why we can't use the tracer also to capture the error.

Regards,

Chitturi.

[Former Member]

Hi,

Any idea on what are all the lock objects will be used in Creating the goods movement bapi?

Regards,

Chitturi.

[Former Member]

Hi,

You have to use tracer (st01) not for capturing error, but for determine what lock objects created.

Many database operations are asynchronous, so after performing bapi and commit there are some update requests may still active (you can view them in tr.SM13).

I faced similar obstacles when performing mass goods movement in batch input: stock amount data not yet updated when next data record have to proceed.

In your case (if you have only errors related with locks) to assure avoid error you have to wait until all lock objects are released - .

Wait for fixed amount of time helps, but not always.

Best regards,

Nick.

[Former Member]

Hi Nick,

This sounds good .

I agree with your point.

"You have to wait until all lock objects are released" i.e. How can we check whether all the locks released or not before proceeding to next iteration. After bapi_transaction_commit we have to check for the lock objects.

Regards,

Chitturi

[Former Member]

Hi,

You can check it by call FM ENQUEUE_READ.

See this thread for example:

Best regards,

Nick.

[Former Member]

Hi Nock,

I got your point now. Can we further drill down the results which happened for this goods movement bapi only? i.e. If the same user had locked some other object apart from this goods mvmt bapi program the lock will be there like that only in the lock table right.

You asked me to wait till all the locks released that means after bapi transaction commit I have to check the function module inside a do--enddo loop and exit once the lock obejcts came to zero?

Is there any fixed lock object in the goods mvmt creation like EMMARAE?

Thanks for your prompt help..

Regards,

Praveen Chitturi

[Former Member]

Hi,

you can use tr.ST05 to figure out tables and keys. Pick "Enqueue trace" only.

Then provide them in ENQUEUE_READ as GNANE and GARG parameters to restrict scope.

Best regards,

Nick.

[Former Member]

Also, you can provide only GNAME, then search for particular values in result table ENQ (material number for example).

[Former Member]

Noted..  Got better understanding this time.

What is the use of statement SET UPDATE TASK LOCAL ?

In the Bapi_transaction_commit bapi why wait parameter is? Even though I pass it as 'X' , it is returning immediately and self locking issue is coming.

Regards,

Praveen Chitturi

[Former Member]

Hi,

I not sure it's necessary to set update task local here.

See this: Local Update - ABAP Programming (BC-ABA) - SAP Library

If may be better not to set it.

About BAPI_TRANSACTION_COMMIT. It's code very short and you can see:

...

IF WAIT EQ SPACE.

   COMMIT WORK.

ELSE.

   COMMIT WORK AND WAIT.

...

https://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm#&ABAP_VARIANT_1@1@

"If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating), but instead is resumed immediately after COMMIT WORK. However, if the addition AND WAIT is specified, program processing afterCOMMIT WORK

will not continue until the update work process has executed the high-priority update function modules (synchronous updating)."

I think there is some asynchronous tasks running by bapi itself (such things as call FM .. in update task, you can trace it), so even if you specify wait, it would not help. Yes, it would wait for bapi code itself, but not for such asynchronous tasks.

[Former Member]

Thank you Nick Patrick.

For your valuable inputs. I am going through another document about commit work and lock status at

I got one point clear that we have to check the lock entries table using the FM Read_eneque and no locks are there means proceed ahead otherwise set some fixed time frame as maximum wait time and notify the user about the locking issue.

Once again Thank you for your valuable inputs.

Regards,

Praveen CHITTURI.