BAPI_REQUISITION_CREATE Problem with COMMIT WORK AND WAIT

[Former Member]

I ran into an issue and wanted to get your opinions about what might be happening.

This is my original code that did not work correctly using COMMIT WORK AND WAIT. After the select statement, lv_count was zero even though there were PR items that had been created. I'm thinking that the database update was not complete, but why would that be?

    CALL FUNCTION 'BAPI_REQUISITION_CREATE'
      IMPORTING
        number            = lv_number
      TABLES
        requisition_items = gt_reqitem
        return            = gt_return.

*   Purchase requisition has been created
    IF lv_number IS NOT INITIAL.
      COMMIT WORK AND WAIT.

*     Get number of items in PR
      SELECT COUNT( DISTINCT bnfpo ) INTO lv_count
        FROM eban
        WHERE banfn = lv_number.

This is my corrected code that works. I removed the AND WAIT from the commit statement and added a separate wait statement. I now get the correct number of PR items that were created.

    CALL FUNCTION 'BAPI_REQUISITION_CREATE'
      IMPORTING
        number            = lv_number
      TABLES
        requisition_items = gt_reqitem
        return            = gt_return.

*   Purchase requisition has been created
    IF lv_number IS NOT INITIAL.
      COMMIT WORK.
      WAIT UP TO 1 SECONDS.

*     Get number of items in PR
      SELECT COUNT( DISTINCT bnfpo ) INTO lv_count
        FROM eban
        WHERE banfn = lv_number.

Any ideas?

Brenda

[arseni_gallardo]

Brenda,

Insert this statement just before the BAPI call:

SET UPDATE TASK LOCAL.

And remove your WAIT statement.

I think this will solve your problem.

[Former Member]

Hi,

Commit Work and Wait. is used for synchronous update, since this scenario is of Asynchronous update hence your correct code is working. I am pretty sure even if you remove WAIT UP TO 1 sec. it will work. All it requires is COMMIT WORK.

PS. To commit work after calling a BAPI, you should use,FM "BAPI_TRANSACTION_COMMIT" instead of any other statement(s).

Hope you find this useful!

Thanks,

Reetesh

Edited by: Reetesh Tiwary on Nov 11, 2011 6:53 PM

[Former Member]

Hello Reetesh,

According to SAP note 809747 I am using COMMIT WORK correctly.

The caller of BAPIs must complete the transaction at the end of a 
LUW and trigger the update.
- If you call a BAPI from outside the SAP system, use the Service 
BAPI BapiService.TransactionCommit or function module 
BAPI_TRANSACTION_COMMIT.
- If you call a BAPI in a program within a system, complete the 
transaction with the ABAP command 'commit work'.
If you want to test a BAPI in the test environment of the function 
library (transaction SE37), you need to define a test sequence 
which first executes the BAPI you want to test and then 
BAPI_TRANSACTION_COMMIT.
Note also that, with the asynchronous update, the data may not 
be available immediately even with a successful 'commit work'. 
Either wait a moment or use the 'WAIT' parameter with module 
BAPI_TRANSACTION_COMMIT. See also Note 192235.

Is there a reason why you suggested using BAPI_TRANSACTION_COMMIT?

Regards,

Brenda

[arseni_gallardo]

Brenda,

Try what I suggested before (set update task local). It will work.

[Former Member]

Can you tell me how/why it will work?

[Former Member]

Hi,

See there are two types of LUW`s Database and SAP LUW`s. There can be lot of database LUW`s within a SAP LUW.

SAP LUW work all or nothing principal, i.e. when you complete a transaction, all the data gets written in all the respective tables that gets used within a transaction (and that happens at the end with the help of COMMIT WORK) or nothing get written to the database and all the temporary updates (that was triggered by DB LUW) gets rolled back.

Now in your case since this process requires Asynchronous update COMMIT WORK is working (in the case of WAIT UP TO when there large # of update to take place so you need to give time, as stated in notes).

OR you can use standard COMMIT WORK Function Module.

The reason why COMMIT WORK AND WAIT is not working because system does not know where to go what to do and when to come back hence actual COMMIT WORK never happens and yet you can see PR is generated but since commit is not happening all the DB LUW`s gets rolled back.

I hope after this clarification we are on same page. Let me know!

Regards,

Reetesh

[Former Member]

For your reference, go thru the help link:

Synchronous and Asynchronous Updates:

http://help.sap.com/saphelp_nw04/helpdata/en/e5/de86e735cd11d3acb00000e83539c3/frameset.htm

LUW`s

http://help.sap.com/saphelp_nw70/helpdata/en/41/7af4bfa79e11d1950f0000e82de14a/frameset.htm

Also, I can tell you another way to check this, execute the BAPI thru SE37, and unless you execute them in sequence with COMMIT WORK FM you will see what I said. i.e. PR created but will get rolled back.

I am sure this will clear most of your doubts!

Regards,

Reetesh

[arseni_gallardo]

If you take a look (or debug) to the source code of the BAPI you will see several "CALL FUNCTION xxx IN UPDATE TASK".

This is what the documentation says about IN UPDATE TASK:

The function module is not executed immediately, but is scheduled for execution in a special work process (update work process). For this purpose, the name of the function module including the passed actual parameters is stored as a log record in the database table VBLOG. If the statement is executed during the update task, the addition IN UPDATE TASK is ignored.
If the statement SET UPDATE TASK LOCAL is executed before registration of an update function module in the current SAP LUW, registration takes place in the ABAP memory rather than on the database, and for the current work process

A COMMIT WORK AND WAIT does not wait for the V2 tasks to finish and that's why you are experiencing problems. If you use the SET UPDATE TASK LOCAL before the first call IN UPDATE TASK LOCAL then all the function modules will be executed in your same process, not in a parallel one, and so the updates will have finished right after the commit.

That's why I suggest you to do a SET UPDATE TASK LOCAL before calling the BAPI and get rid of the WAIT xx SECONDS.

Edited by: Arseni Gallardo on Nov 11, 2011 10:53 PM

[Former Member]

See, the moot problem is not with or without LOCAL TASK that you might and might not use, idea is to understand the concept of Synchronous and Asynchronous update and what COMMIT WORK and COMMIT WORK AND WAIT does.

Btw, SET UPDATE TASK LOCAL is more to prioritize the update. In update task the data gets written in VBLOG table where as in this the data gets written to ABAP memory. It uses the current WP rather than Update WP.

I hope you got my point!

Reetesh

[kesavadas_thekkillath]

Hi,

First of all i will recommend you to read about [Synchronous and Asynchronous update|http://help.sap.com/saphelp_nw04/helpdata/en/e5/de86e735cd11d3acb00000e83539c3/content.htm]

Is there a reason why you suggested using BAPI_TRANSACTION_COMMIT?

Yes !! you can read the Wiki by Sandra [BAPI_TRANSACTION_COMMIT versus COMMIT WORK|http://wiki.sdn.sap.com/wiki/display/ABAP/BAPI_TRANSACTION_COMMITversusCOMMIT+WORK]

But in your case its not required because the function BUFFER_REFRESH_ALL and commit is called internally in the function TRANSACTION_END.

So I'm still puzzled as to why COMMIT WORK AND WAIT does not give correct results consistently whereas COMMIT followed by WAIT x SECONDS does work.

You comit work doesnt have any importance here because the transaction flow is already ended by the commit in bapi itself.

As its asynchronous WAIT UP TO 1 SECONDS will just give you the time to get it reflected in the DB. Its not that the other works and this doesnt work

In your code you need not provide a commit because the bapi internally commits the transaction before you do it . Please note that the commit inside the bapi is asynchronous in nature. Remove COMMIT WORK & WAIT UP TO 1 SECONDS from your code and always check your return table for success and failure. You need not do a select from EBAN to confirm its updated or not.

Please note that Commit work and wait(Synchronous)cannot be replaced with commit work and wait upto n seconds(Asynchronous) - Both are totally different ( Hope so this is what lead to your confusion )

Kesav

[former_member186052]

Hi,

When you use COMMIT WORK AND WAIT then the program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules Sync updating.

Within an update function module started using COMMIT WORK, the execution of statements that lead to a database commit is not permitted.

Instead when you use COMMIT WORK and then WAIT FOR X DURATION.

The commit work part is:

The program does not wait until the update work process has executed it, this is called async updating.

The wait statement part is:

The statement WAIT causes a change in the work process. When ever you use a WAIT, a database commit is issued.

And also when this type of WAIT is used the time should be more than 1 sec minimum.

Because during this waiting process program roll in and roll out occurs. So if it is less than 1 sec then load increases on system.

Regards,

-Sandeep

[former_member186052]

So this DATABASE COMMIT is the reason why you getting it when you use WAIT statement.

[rajesh_paruchuru]

I ran into an issue and wanted to get your opinions about what might be happening.
> 
> This is my original code that did not work correctly using COMMIT WORK AND WAIT. After the select statement, lv_count was zero even though there were PR items that had been created. I'm thinking that the database update was not complete, but why would that be?
> Brenda

A simple search in service market place returned the note 394058 and according to the note, the BAPI BAPI_REQUISITION_CREATE spares the burden of issuing a explicit commit in the application program as it triggers COMMIT on its own, if that is to be true, I suspect an application error might be the reason for the current behaviour, you may implement a double check by also querying the RETURN table of the BAPI to check for any application errors insteaad of just relying on 'NUMBER' exported...the note also says there are alternatives available to this BAPI as of release mySAPERP2005 you might be interested in those...

-Rajesh

[Former Member]

Hello Rajesh,

Thank you for your answer. In response to using the COMMIT statement, I originally did not have any type of COMMIT after the call to the bapi and I was getting lv_count = 0 each time. That's why I added the COMMIT AND WAIT. Then when I tested I found that sometimes lv_count was zero and sometimes it was the correct count.

I have also checked the RETURN table in debugging and found that it only contains one message stating that the PR was created. When I check table EBAN, I find that this is true.

So I'm still puzzled as to why COMMIT WORK AND WAIT does not give correct results consistently whereas COMMIT followed by WAIT x SECONDS does work.

Regards,

Brenda

Also, we're on ECC 6.0 so the note does not apply.

[rajesh_paruchuru]

> Also, we're on ECC 6.0 so the note does not apply.

Well, I can see that the note says that it is valid for all releases subsequent to 4.0B, we are on ECC 6.0 and in the source code of the BAPI I can see the macros(macro_start, macro_end) responsible for issuing a COMMIT WORK statement, it would be great if you can confirm that by placing a break point in the FM TRANSACTION_END where the actual COMMIT WORK is executed, if the COMMIT WORK statement were infact to be executed within the BAPI then that would mean that the update is asynchronous(COMMIT WORK WITH OUT WAIT) and you may have to WAIT in your application for the updates to get completed.

This would also mean that the COMMIT WORK AND WAIT statement within your application marks the end of subsequent LUW started after the original COMMIT statement issued within the BAPI and has no significance.

F1 help on SET UPDATE TASK LOCAL says that:

This statement has no effect on low-priority update function modules.

and I would be surprised if the update of EBAN would be carried out in a FM which is not registered as V1.

To conclude, I tend to believe the asynchrous COMMIT within the BAPI is the reason for the current behaviour.

Edit:

having said this I still believe that you can get rid of the WAIT statement by using SET UPDATE TASK LOCAL because the statement makes the subsequent update synchronous irrespective of the WAIT addition as described in the F1 help:

The local update function performs a synchronous update according to the COMMIT WORK statement, independent of the addition AND WAIT.

this means that the COMMIT currently executed within BAPI would behave as a COMMIT WORK AND WAIT statement

and EBAN bieng a critical update would definitely be updated as a priority update and you should be able to read the results back in your application.

-Rajesh.

Edited by: Rajesh Paruchuru on Nov 12, 2011 10:44 AM

[Former Member]

Hi Rajesh,

I did as you suggested and removed the COMIMIT and WAIT statements and added SET UPDATE TASK LOCAL. Unfortunately, I am still getting 0 items in my message although there were 5 items created in EBAN.

PR 10037578 was completed successfully with 0 items

Brenda

[rajesh_paruchuru]

Hi Rajesh,
> 
> I did as you suggested and removed the COMIMIT and WAIT statements and added SET UPDATE TASK LOCAL. Unfortunately, I am still getting 0 items in my message although there were 5 items created in EBAN.
> 
> 
PR 10037578 was completed successfully with 0 items
> 
> Brenda

were you also able to see the following message in the RETURN table

Purchase requisition number & created

are you calling the BAPI in a loop?

-Rajesh.

[Former Member]

Yes, I was able to see the message in RETURN and no, I am not calling the FM in a loop. My program calls it one time.

Brenda

[rajesh_paruchuru]

Yes, I was able to see the message in RETURN and no, I am not calling the FM in a loop. My program calls it one time.
> Brenda

If you were able to see the message 'Purchase requisition number & created' it means that the macro macro_end is getting executed within which the COMMIT WORK statement is encapsulated.

I have quickly developed a dirty program to test the behaviour of 'SET UPDATE TASK LOCAL' and it seems to work as expected.

Everytime I executed the below program with 'SET UPDATE TASK LOCAL', I see the value of lv_count as 1000, however if I execute the below program with out the statement 'SET UPDATE TASK LOCAL' the value of count varies everytime, typically around 10 - 15, however the database is successfully updated with all the 1000 entries, this makes me believe that the 'SET UPDATE TASK LOCAL' statement will infact make the subsequent COMMIT synchronous.

REPORT zytest.

DATA:
  ls_zytest    TYPE zytest,
  ls_db_zytest TYPE zytest,
  lv_numc04    TYPE numc4 VALUE 1001,
  lv_count     TYPE i,
  lv_index     TYPE i.

DO 1000 TIMES.
  lv_index = sy-index.
  CLEAR ls_zytest.
  lv_numc04 = lv_numc04  + 1.
  CONCATENATE 'KF00' lv_numc04 INTO ls_zytest-keyfield1.
  CONCATENATE 'KF00' lv_numc04 INTO ls_zytest-keyfield2.
  SET UPDATE TASK LOCAL.
  CALL FUNCTION 'ZYTEST_BAPI'
    EXPORTING
      is_zytest = ls_zytest.
  SELECT SINGLE * FROM zytest INTO ls_db_zytest WHERE keyfield1 = ls_zytest-keyfield1
                                                  AND keyfield2 = ls_zytest-keyfield2.
  IF sy-subrc IS INITIAL.
    WRITE:/ lv_index, ls_db_zytest-keyfield1,ls_db_zytest-keyfield2.
    lv_count = lv_count + 1.
  ENDIF.
ENDDO.

WRITE:/ lv_count.

FUNCTION zytest_bapi .
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     REFERENCE(IS_ZYTEST) TYPE  ZYTEST
*"----------------------------------------------------------------------
DATA: transaction_id LIKE arfctid.
  clear transaction_id.
  macro_start.
  CALL FUNCTION 'ZYTEST_UPDATE' IN UPDATE TASK
    EXPORTING
      is_zytest = is_zytest.
  macro_end.
ENDFUNCTION.

FUNCTION ZYTEST_UPDATE.
*"----------------------------------------------------------------------
*"*"Update Function Module:
*"
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(IS_ZYTEST) TYPE  ZYTEST
*"----------------------------------------------------------------------
INSERT zytest from is_zytest.
ENDFUNCTION.

definition of the database table 'ZYTEST'

MANDT	MANDT
KEYFIELD1	CHAR20
KEYFIELD2	CHAR20
NONKEYFIELD	CHAR50

-Rajesh

[rajesh_paruchuru]

Hi Rajesh,
> 
> I did as you suggested and removed the COMIMIT and WAIT statements and added SET UPDATE TASK LOCAL. Unfortunately, I am still getting 0 items in my message although there were 5 items created in EBAN.
> 
> 
PR 10037578 was completed successfully with 0 items
> 
> Brenda

can you also let us know the results of the SELECT statment( with out both the COMMIT and WAIIT statements and with the SET UPDATE TASK LOCAL), does it always fail?

-Rajesh.

[Former Member]

Hi Rajesh,

Thank you very much for your help. It was my fault that the statement SET UPDATE TASK LOCAL did not work. I put it after the bapi, not before. Now that I have placed it before the bapi, the program is giving correct results.

Thanks again,

Brenda

[rajesh_paruchuru]

Hi Rajesh,
> 
> Thank you very much for your help. It was my fault that the statement SET UPDATE TASK LOCAL did not work. I put it after the bapi, not before. Now that I have placed it before the bapi, the program is giving correct results.
> 
> Thanks again,
> Brenda

All is well that ends well , glad that I was able to help you.

-Rajesh.

[Former Member]

Brenda - if your question is answered, please login to SDN under the original ID, assign points and close the thread.

Rob

[Former Member]

Hi Rob,

Thanks for your prompting, but I cannot assign points or close the thread. It appears that my 2 IDs are intertwined. I can only sign in as my first ID even though I can see both. I have sent an email to sdn@sap.com asking for help.

Brenda

[Former Member]

Brenda - I see that you are using two different userids in this thread.

Please note that you will only be able to assign points and mark this as closed if you log on under the one you used to ask the question.

In the future, please use only one userid.

Rob

[Former Member]

Hi Rob,

I'm only aware of having 1 userid.

Brenda

[Former Member]

- a new one under which this thread was started and under which you are now responding and has more questions and points.

Rob

[Former Member]

I have no idea how that happened. I didn't create a new one. Can you combine the 2 into 1?

Brenda

[Former Member]

Can you combine the 2 into 1?

When you are done with this thread, use the new ID to assign points and mark the thread as closed (you won't be able to do it under this one). Then send an e-mail to sdn@sap.com and ask them to delete the new one.

Rob