Issue with BAPI & Commit

[Former Member]

Dear All,

I have been working with an assignment and facing a strange issue.

I have used the 'BAPI_SALESORDER_CHANGE' to modify sales order and then I call 'BAPI_TRANSACTION_COMMIT' with wait = X. So, this bapi modifies the sales order schedule lines and also in turn updates the info structure linked to it (In our case, say it is S800)

Immediately after this I have a select statement on S800 to fetch the records.

On debug, if I break at select statement, I get correct records from S800 but If i break one step after select it gives me different records.

I think there is some delay in updation of infostructure, hence, If i use wait statement before select for 1 sec, it works fine, but cause performance issues.

for over 15000 order items, it will wait for around 8 hours, hence, i would like to know is there any way I can avoid wait and also read the infostructure for correct records.

<< Moderator message - Everyone's problem is important. Please do not ask for help quickly. >>

Edited by: Rob Burbank on Feb 24, 2011 9:45 PM

[vinod_vemuru2]

Hi,

I feel that the design can be improved better. You are updating the order and immediately trying to read the same data. Why is this so? Is the info structure updated automatically or through your program only? If it is from your program, you already have the data.

So in this case you dont need to read the database again.

Even if you give WAIT = X, there would be some delay in the actual database updation. There is no control on this.

You took an example of 15000 records may take 8 hours with 1 second wait time. Does this mean your select is in loop? If so, definitely you have to rethink on the design.

One option could be, you can schedule this as batch job instead of online execution.

Thanks,

Vinod.

[madhu_vadlamani]

HI Chandan ,

As vinod told Commit means you are asking system to wait some time to update database.Just run the back ground job.

Regards,

Madhu.

[Former Member]

Try using 'wait up to 5 seconds'. this time is sufficient to update the database.

Regards,

Daz.

[Former Member]

Thanks for your replies,

We are actually using the Bapi within a loop which is required because we are doing two things ...

As the functional have provided us inputs, to unconfirm undelivered lqty, we use BAPI_SALESORDER_CHANGE to first set the order quantity to delivered qty to remove the undelivered qty and then reset back the order qty to original using the same BAPI with ATP check off.

THis has to be processed for each order. I know, that certain infostructures get updated asynchronusly when these bapi is called.

My problem is when I read the same infostructure table S800 after the BAPI call during debug mode when I stop exactly at the select statement is shows correct updated values as in table S800 but if I break at the next line of select and read the infostrucutre in internal table it shows original status before bapi call whereas if I see table it was already updated. This clearly shows there is a delay and the statement after BAPI call is read much before....

The Design given to us is quite complex and currently its difficult to change... My question is how to solve above issue and how could I read correct records. If I introduce wait Upto 1 sec it works but since we do it for 15000 order items, it proves quite costly as we have to do this processing per order item separatley.

Kindly suggest please...

I tried running the bAPI is a separate session using RFC and then used the RFC_CONNECTION_CLOSE to initialze all connections and commit but still it doesnt work. I get wrong status of records.

Please suggest.

Best Regards,

[Clemenss]

Hi Chandanrs,

with COMMIT WORK (or BAPI_TRANSACTION_COMMIT) with WAIT addition, processing is continued after all high-priority ("VB1") update function modules are executed in the order of their registration and in a shared database LUW.

That means that the info structures are probably updated in low-priority ("VB2") update.

I never faced this situation but I think that the info structure should still be locked. Try to find the corresponding lock object, in a (test) run, locks may be visible shortly in SM12 lock overview.

If possible, after commit work, try to call the enqueue function with the same arguments as it is done within the BAPI processing. You should get a foreign lock error until the end of the second level update process.

while lv_locked is initial.
  call function 'ENQUEUE...
  IF sy-subrc = 0.
    lv_locked = 'X'.
  endif.
endwhile.
  call function 'DEQUEUE...
  clear lv_locked.

This lets your program wait until the info structure update is complete. Sorry I do not really know which lock object is used here. Anyway, I still do not know why you have to read the S900 directly after update.

You may also process all orders to the to set the order quantity to delivered qty, COMMIT every 1000 or so orders, put the original quantity to internal table. Then do the same for restoring.

BAPI processes run a great deal faster if you do not COMMIT after every single document. But you can't take too many because than you risk a lock table overflow.

Hope it is some help anyway.

Regards,

Clemens