How to solve this problem - Urgent

[aaruljothi]

Hi All,

I have a BDC program that will call transaction "MB1B" using CALL TRANSACTION to post a material document for a reservation. Then immediately after that the program calls another transaction "LT12" which will confirm the TR.

The problem is when the material document is posted (MB1B) the number is reflected in MKPF/MSEG. The same MSEG has the LGNUM-Warehouse Number / Warehouse Complex, TBNUM-Transfer Requirement Number which is generated when a material document is created. I use these field values to get the TO(transfer out) from LTBP and LTAP. But the records are not found in these tables.

I have identified that the numbers are not generated in such a way that the read on those tables LTBP and LTAP is immediate.

If i put a break point before the selects on LTBP and LTAP and make the sytem to wait for some time it works properly. But i can't predict the wait time.

How can i solve this problem?. I have aslo tried posting the material document using BAPI_GOODSMVMT_CREATE.

Thakx in advance,

arul jothi

[Former Member]

Hi Arul,

First write explicit commit statement.

And also try using WAIT in a loop.Like wait for 2 sec

and again go and check the tables if not found then

again wait. Because we dont know the system load and

sometimes it will commit and sometimes it will take

sometime to update tables.

Hope this will help you.

Thanks & Regards,

Siri.

[Former Member]

Hi Arul,

1. This has to do with UPDATE MODULE.

2. Transactions like MIGO update a lot of tables, IN BUNCH.

3 They do not update it immediately. Rather,updation

takes place thru a FM which updates the bunch

of table in a separate work process. Hence,

it takes some time.

4. Try making COMMIT WORK

just after the BDC to ensure that the updation

happens immediately.

HOPE IT HELPS.

Regards,

Amit M.

[former_member181962]

Hi Arul,

Another alternative for Srlatha's approach would be,

using the BAPI_GOODSMVMT_CREATE with the explicit commit FM

BAPI_TRANSACTION_COMMIT.

and then call the LT12 transaction.

Regards,

Ravi

[Former Member]

Arul,

Make sure in the CALL TRansaction , u have

<b> update 'L'. </b>

After Call Transaction, please have:

<b>if sy-subrc = 0.

COMMIT WORK.

endif.</b>

Thanks

Kam

[aaruljothi]

Hi,

on Srilatha's reply - Thanks. What u said is corrcet but the problem is if ur system load is high u cannot make your program to wait for a long time (300 secs in foreground). I tried with this option but again i face the same problem.

The update mode 'L' id local update. Can anyone tell me what that does and how it solves my problem.

[former_member181962]

HI Arul, Here is the help document on Local Updates.

In a local update, the update program is run by the same work process that processed the request. The dialog user has to wait for the update to finish before entering further data. This kind of update is useful when you want to reduce the amount of access to the database. The disadvantage of local updates is their parallel nature. The updates can be processed by many different work processes, unlike asynchronous or synchronous update, where the update is serialized due to the fact that there are fewer update work processes (and maybe only one).

You switch to local update using the ABAP statement SET UPDATE TASK LOCAL. This statement sets a "local update switch". When it is set, the system interprets CALL FUNCTION IN UPDATE TASK as a request for local update. The update is processed in the same work process as the dialog step containing the COMMIT WORK. The transaction waits for the update to finish before continuing.

As an example, suppose you have a program that uses asynchronous update that you normally run in dialog mode. However, this time you want to run it in the background. Since the system response time is irrelevant when you are running the program in the background, and you only want the program to continue processing when the update has actually finished, you can set the SET UPDATE TASK LOCAL switch in the program. You can then use a system variable to check at runtime whether the program is currently running in the background.

By default, the local update switch is not set, and it is reset after each COMMIT WORK or ROLLBACK WORK. You therefore need to include a SET UPDATE TASK LOCAL statement at the beginning of each SAP LUW.

If you reset data within the local update, the ROLLBACK WORK statement applies to both the dialog and the update part of the transaction, since no new SAP LUW is started for the update.

Regards,

Ravi

[Former Member]

Hi Arul,

Did you try with C14Z_WAIT_ON_COMMIT.

If it did not work, here is one of the possible solution for your problem.

Do

Select from on LTBP and LTAP

If sy-subrc <> 0.

Call function 'C14Z_WAIT_ON_COMMIT'

else.

exit.

enddo.

You must do this when you are sure that posting of material document is successful or else your program just waits in infinite loop.

Cheers

Raghava

[aaruljothi]

Hi ragava,

That is also not working. it is taking lot of time which is not needed. the call transaction statment is like this

call transaction MB1B mode 'A' update 'S'.

call transaction LT12 mode 'A' update 'S'.

thank 4 ur reply,

arul jothi

[Former Member]

Hi,

For the same type of problem what we have done is, after first call transaction statement write,

DO xxxx Times

Select xx yy from table AAAA

if sy-subrc = 0.

EXIT.

endif.

ENDDO.

Hope this will solve your problem. can you tell me why you r not using BAPI.

Rajavardhana Reddy

[Former Member]

Hi,

I feel it is better use function module 'BAPI_GOODSMVT_CREATE', this is required explicit COMMIT statement (i.e. call to BAPI_TRANSACTION_COMMIT). Bythat time you reaches the select statement table should have the Material document number. Hope it solves your problem

Cheers

Rajavardhana Reddy