Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

COMMIT WORK AND WAIT does not work

Former Member
0 Likes
3,270

Hello,

I know this question has been asked many times in various forums. But the fact remains that there is no definitive solution found for this problem which does not involve WAIT UP TO n SECONDS or SELECT until the DB commit has been completed.

We have an IDoc based inbound interface for creating Project Defintion and WBS Elements. Here is how the code looks like in the processing function module:


* Create Project Defintion
CALL FUNCTION 'BAPI_PROJECTDEF_CREATE'
  EXPORTING
    project_definition_stru = lwa_proj_bapi
  TABLES
    e_message_table         = lt_messages.

* If no errors
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
  EXPORTING
    wait = 'X'.

* Other code
.......

* Create WBS Element (BAPI could not be used because not all fields are allowed to be updated)
CALL TRANSACTION 'CJ11'

Now while creating the WBS Element, transaction CJ11 returns an error that 'Project does not exist'. This is not correct because the same Project was successfully created in the previous step.

It is clear that the problem is because of the delay in database commits.

This happens only with few IDoc's and not all of them. And of course, the problem does not occur if I induce WAIT UP TO n SECONDS after BAPI_TRANSACTION_COMMIT. But this is not the best practice.

The question is why BAPI_TRANSACTION_COMMIT does not wait even though we are forcing it to?

Thanks in advance

Sagar Acharya

10 REPLIES 10
Read only

Former Member
0 Likes
1,730

With problems like this it's usually best to inspect the source code. I'd say we're really lucky that we can do that, instead of relying on some possibly wrong/outdated documentation. At least in my ECC 6.0 system I found the answer to your question in roughly a minute. Thus I really encourage people to start taking advantage of having the source code available.

For sake of completeness, here's what I found:

<ol>

<li>Function module BAPI_PROJECTDEF_CREATE submits report R_BAPI_PROJECTDEF_CREATE (so starts new LUW, separate from the IDoc context due to the SUBMIT, thus I'd expect to find a commit somewhere)</li>

<li>The report calls function module 2001_PROJECTDEF_CREATE</li>

<li>Within the function we see a call of function CN2D_PROJDEF_CREATE_STRU to create the project</li>

<li>If this function call is successful, it executes the following coding:


call function 'CJDT_GET_NEW_NUMBERS'.
perform on_commit(saplcjwb).
commit work.

</li></ol>

So if you see the same in your system, then you know that your commit after the BAPI call is useless for waiting for the project creation as the commit happened already...

Cheers, harald

Read only

SuhaSaha
Product and Topic Expert
Product and Topic Expert
0 Likes
1,730

>

> So if you see the same in your system, then you know that your commit after the BAPI call is useless for waiting for the project creation as the commit happened already...

Hi Harald,

I was also back tracing the code. But i am baffled that although the COMMIT has happened earlier why is the data not updated in the DB ?

I am not sure if this has got something with a separate LUW being called ??

BR,

Suhas

Read only

0 Likes
1,730

Thanks for your response Harald.

But if you see my question 'the commit has not happened'.

Also the problem is not just with BAPI_PROJECTDEF_CREATE. It is also when WBS Element is created using CJ11. I did not earlier put it in my question as I did not want to dilute the question.

Here is the entire problem. The interface is actually about creating Project Defintion, WBS Element and Assets. So the actual code looks like:


* Step 1 - Create Project Defintion
CALL FUNCTION 'BAPI_PROJECTDEF_CREATE'
  EXPORTING
    project_definition_stru = lwa_proj_bapi
  TABLES
    e_message_table         = lt_messages.
 
* If no errors
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
  EXPORTING
    wait = 'X'.
 
* Other code
.......
 
* Step 2 - Create WBS Element (BAPI could not be used because not all fields are allowed to be updated)
CALL TRANSACTION 'CJ11' with 'S' update mode

* If no errors
COMMIT WORK AND WAIT

* Other code
.......

* Step 3 - Create Asset
CALL FUNCTION 'BAPI_FIXEDASSET_CREATE1'

Now while creating the Assets in step 3, sometimes the BAPI returns an error that 'WBS Element does not exist'. Again this is not correct because WBS Element was successfully created in Step 2.

Read only

0 Likes
1,730

Suhas wrote:

But i am baffled that although the COMMIT has happened earlier why is the data not updated in the DB ?

Well, it's just a [COMMIT WORK|http://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm] and not a [COMMIT WORK AND WAIT|http://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm#@@AND%20WAIT@@COMMIT%20WORK@@]. Let me quote the ABAP help:

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 after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).

@Sagar Acharya: Well, I thought you were looking for an explanation why sometimes the project isn't created (and you only had posted coding that showed details for step 1) - I'm trying hard, but my mind reading skills are rather limited yet...

So let's think about step 2 and 3: I assume that you made sure that your coding always references the correct WBS element. Again the commit (without wait) is done already via CJ11 (e.g. check form BUCHEN in SAPLCJWB). I'd expect though that the synchronous update mode should make this work. Since it doesn't, I'd try local update mode, which is what I'd choose in your case anyhow.

Apart from that my mind is pretty blank, except for the usual silly things to check. E.g. are you sure you're coding is correct, you are handling all return messages and log them for inspection later (e.g. application log), you are certain that the WBS was actually created by the same IDoc that throws the fit (and IDoc was not reprocessed), etc.

So maybe somebody else has better ideas...

Read only

0 Likes
1,730

Hi Harald,

Using local update mode 'L' for CALL TRANSACTION may help. I am trying that right now.

But will using 'SET UPDATE TASK LOCAL' help also in case of BAPI_PROJECTDEF_CREATE? Any thoughts?

And just for the records, I am pretty sure that the coding I have done handles all the exceptions And as I said earlier, this problem happens only sometimes and if I reprocess the same IDoc using BD87, the error is gone.

Regards

Sagar Acharya

Read only

0 Likes
1,730

But will using 'SET UPDATE TASK LOCAL' help also in case of BAPI_PROJECTDEF_CREATE? Any thoughts?

I believe it should. Note my careful phrasing though, as I'm still confused why your synchronous update with the call transaction doesn't work. Maybe I'm just too tired and missing something obvious here?! Let's hope somebody else joins in and enlightens us...

Read only

0 Likes
1,730

Hi Sagar Acharya,

I was looking at your issue: did you try to execute CJ11 as a local update task instead of synchronous. I'm curious to know the result (as I don't see why L would better work than S update mode, as both do update synchronously, the difference is just a matter of performance, using the DIA or UPD workprocess).

I'd prefer to think that there's an issue either in the SAP update work processes/locks (synchronization, etc.), or in the RDBMS (check SAP notes, or ask your database administrator if there are patches, or maybe ask SAP support if they are nice ).

Thank you!

sandra

Read only

Former Member
0 Likes
1,730

are you running that in bg...

you can use

WHILE sy-subrc is NOT INITIAL.

WAIT UP TO 1 SECONDS.

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'

EXPORTING

wait = 'X'.

ENDWHILE.

Edited by: Sachin Bidkar on Jun 10, 2010 9:09 AM

Read only

Subhankar
Active Contributor
0 Likes
1,730

Hi Sagar,

I also don't know the exact reason. I Also faced the same type of problem while creating material. Reason was when ever any material was created in background 3 to 4 workflows were triggered. For this one locking issue was happened.

For ypur case can you please check the same think in update task. Just call the three steps is in three update task or perform on commit.

Thanks

Subhankar

Read only

Former Member
0 Likes
1,730

probably the bapi is launching some routines in background...

you can put some sentences to make sure your proyect was created in a "DO" sentence....

for example an authorization object.


DO.

"authorization-object or select sentence 
....

IF sy-subrc EQ 0.  "your proyect was alrready created
  EXIT.
ELSE. "not yet created...wait.
  WAIT UP TO 2 SECONDS.
ENDIF.

ENDDO.
CALL TRANSACTION 'CJ11'.

sorry about my english

regards, sebastian