topic Re: BAPI_TRANSACTION_COMMIT with WAIT = 'X' does not work. Any suggestions? in Application Development and Automation Discussions

BAPI_TRANSACTION_COMMIT with WAIT = 'X' does not work. Any suggestions?

Former Member — Fri, 15 Apr 2011 15:49:54 GMT

1) 'BAPI_PRODORD_CREATE'

2) CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'

EXPORTING

wait = 'X'.

3) BAPI_PRODORD_CHECK_MAT_AVAIL

Sometimes it works fine, other times the BAPI_PRODORD_CHECK_MAT_AVAIL passes an error that says the "Order does not exist."

I tried a "Wait up to 10 seconds". That makes the processing go extremely slow and even that doesn't make it work 100%.

Any suggestions?

Re: BAPI_TRANSACTION_COMMIT with WAIT = 'X' does not work. Any suggestions?

Former Member — Fri, 15 Apr 2011 17:14:14 GMT

Have you checked your return from first bapi and corrected any situation where you order is not getting created? You are checking for success prior to last BAPI call?

Re: BAPI_TRANSACTION_COMMIT with WAIT = 'X' does not work. Any suggestions?

Tamas_Hoznek — Fri, 15 Apr 2011 17:40:26 GMT

Just before every BAPI call, try to use SET UPDATE TASK LOCAL.

Re: BAPI_TRANSACTION_COMMIT with WAIT = 'X' does not work. Any suggestions?

Former Member — Fri, 15 Apr 2011 17:41:58 GMT

Hi,

Why are u checking if the order was created?

The return of the bapi BAPI_PRODORD_CREATE gives u a number of order.

So, it means that it the order exits.

What u r doing it is not so good, as delays always occurs, so that's why sometimes it passes ok and others says that it is not create.

I guess better not check it using that bapi, try to see if the data is on the order table.

Regards

Re: BAPI_TRANSACTION_COMMIT with WAIT = 'X' does not work. Any suggestions?

Former Member — Fri, 15 Apr 2011 18:35:49 GMT

There is no error from the first BAPI. The production order is created correctly. The problem is that it hasn't committed in time for the production order material availability check BAPI. If I go to transaction co03 with the order number created by the bapi create the production order exists. It is all a timing issue.

I can even run this code 10 times in a row. Sometimes the availability check works, sometimes the production order hasn't committed to the database in time and the availability check fails because of no production order.

Re: BAPI_TRANSACTION_COMMIT with WAIT = 'X' does not work. Any suggestions?

Tamas_Hoznek — Fri, 15 Apr 2011 18:37:51 GMT

Try what I suggested and let us know if it worked.

Re: BAPI_TRANSACTION_COMMIT with WAIT = 'X' does not work. Any suggestions?

Former Member — Fri, 15 Apr 2011 18:56:05 GMT

I am going to try the following

SET UPDATE TASK LOCAL

After BAPI prod order create, select from table aufk for order number.

I will report back with details. Thanks for the suggestions. I bet one of them will work.

Re: BAPI_TRANSACTION_COMMIT with WAIT = 'X' does not work. Any suggestions?

Former Member — Fri, 15 Apr 2011 20:09:24 GMT

The programmer I have working on this has gone home for the weekend. I will have to follow up next week.

I gave some points for the helpfull suggestions. I will plan on returning next week with a solution that worked.

Re: BAPI_TRANSACTION_COMMIT with WAIT = 'X' does not work. Any suggestions?

Sandra_Rossi — Fri, 15 Apr 2011 23:35:16 GMT

Hello Joel,

I think you shouldn't give points before testing the solutions, because if the solution doesn't work, it misleads people who seek for right answers. Well you can still reassign them later.

My opinion is that COMMIT WORK AND WAIT (what does bapi_transaction_commit) has the same effect on waiting update task to be terminated than using the local update task. The only difference is a matter of performance. But I'd be happy if someone could tell me that I'm wrong

One possible reason is that an asynchronous RFC has been run to update the data, and so this is disconnected from the update task. Once, I couldn't say, it seemed that the only way was to add a WAIT UP TO 1 or 2 SECONDS (I couldn't check by myself so I'm always suspicious on this kind of solution!)

The best way to know is to run a trace (ST05 for example) to check what does the updates.

Sandra

Re: BAPI_TRANSACTION_COMMIT with WAIT = 'X' does not work. Any suggestions?

Former Member — Mon, 13 Jun 2011 21:59:34 GMT

From what I found,

1) the commit_wait is automatically ran in many BAPI's, but not all. It is oftern duplication to add it yourself

2) The commit_wait logic appears to end on the application server. Once the application server passes the commit to the database then the application server thinks it is done and continues processing the program. In reality the database is still processing and the record is still locked in the database. This means the commit and wait code is not a 100% guarantee.

Solution:

1) Function module ENQUEUE_READ (or transaction SM12). This checks to see if the database lock is in place. Set a break-point in the code and in a separate window run one of these. You will see the locks. Now you know the lock condition add some ABAP code to Do loop at reading the results on the relevant lock. Exit and continue processing when the locks are removed. See my comments in step 2 about a wait a few seconds between loops and providing an exit time to avoid infinite loops. I think solution 1 is better than solution 2, even though I implemented solution 2.

2) loop on a select from the database (you need to know the table being updated by the bapi to do this). exit the loop when the record is inserted. This is what I did since I hadn't found the solution in step 1 when I implemented my fix. Don't put a wait statement in the loop though. The wait is taxing on the database because it executes a commit. I used "get time field" to handle a 2 second wait between database reads. I also used this to exit after 30 seconds to avoid an infinite loop.

Below is some sample code of solution 2. I used it in between a BAPI production order create and BAPI check production order material availability. I was getting an error saying the production order hadn't been created in the material availability check when in fact it had been created but just not committed to the database.

DO.

Only select from DB every two seconds

CLEAR do_time3.

do_time3 = do_time1 - do_time2.

IF do_time3 GT gc_000002.

* Determine if confirmation has committed to database

SELECT SINGLE aufnr FROM resb INTO lv_aufnr WHERE aufnr = g_aufnr AND

xloek = space AND

xwaok = gc_x AND

kzear = gc_x AND

matnr IN r_range.

IF sy-subrc EQ 0.

EXIT.

ENDIF.

GET TIME FIELD do_time1.

do_time2 = do_time2 + gc_000002.

do_exit = ( do_time1 - do_time ).

IF do_exit GT gc_000030.

EXIT.

ENDIF.

CLEAR do_exit.

ENDDO.

Re: BAPI_TRANSACTION_COMMIT with WAIT = 'X' does not work. Any suggestions?

Former Member — Mon, 13 Jun 2011 22:05:09 GMT

Add code to check for database lock on the relevant record using function module ENQUEUE_READ (or transaction SM12)

Re: BAPI_TRANSACTION_COMMIT with WAIT = 'X' does not work. Any suggestions?

Sandra_Rossi — Tue, 14 Jun 2011 09:02:02 GMT

Hi Joel,

thank you for the feedback, but you are wrong, especially on the first point.


> 1) the commit_wait is automatically ran in many BAPI's, but not all.  It is oftern duplication to add it yourself

No, maybe a few old BAPIs do that (see SAP note 131838 - Collective note for BAPIs w/ 'Commit Work' command), but since a long time now, they don't do it anymore, hopefully, this is a basis principle of BAPIs, as explained here -> http://help.sap.com/saphelp_nw70/helpdata/en/43/b46c4253c111d395fa00a0c94260a5/frameset.htm


> 2) The commit_wait logic appears to end on the application server.  Once the application server passes the commit to the database then the application server thinks it is done and continues processing the program.  In reality the database is still processing and the record is still locked in the database.  This means the commit and wait code is not a 100% guarantee.

Yes and no. Yes, BAPIs usually use the principle of update in a SAP LUW. Very useful when you have multiple screens. It is not specific to BAPIs. But NO, because calling function module BAPI_TRANSACTION_COMMIT with WAIT='X' does a COMMIT WORK AND WAIT, and it waits for the end of the asynchronous update task. Statement SET UPDATE TASK LOCAL is another way to execute updates synchronously as the updates are done in the same workprocess, so it does not require a wait.


Solution : ...

Your solutions are usually not needed if the BAPIs and the calling program are correctly written. Each time I've seen some WAIT UP TO x SECONDS or such solutions, that was a bad use of function module calls and COMMITs, most often due to a misunderstanding how SAP LUWs work (when they are really started or ended, for example using SUBMIT and RFCs).

There could be some (very rare though) issues with the SAP lock system also, the SAP notes should be searched.

Sandra

Re: BAPI_TRANSACTION_COMMIT with WAIT = 'X' does not work. Any suggestions?

Sandra_Rossi — Tue, 14 Jun 2011 12:35:43 GMT

In complement to what I said, the locks which may occur in the V2 updates may cause issues, because the commit with wait only for V1 upates (see for example the comment in SAP note 744403). However, V2 are normally used for history, logs, etc., so lock issues should be unfrequent. Usually people do a WAIT UP TO SECONDS, or restart the failed transactions. But your solution could be used too. I think I would try to delay the V2 updates, if possible.

Sandra