Regarding Time Out error while uploading data using BAPI

[Former Member]

Hi,

I have developed Upload Program for creating STO's using BAPI_PO_CREATE1,after creating STO's ,for this STO's OBD numbers are created automatically and stored in LIPS table.Now i want to display STO ,OBD,Quantity in ALV report.

For this i will fetch OBD from LIPS table based on PO,here it takes more time and gives runtime error in Production.can anyone tell me ow to solve this?

Thanks

[former_member218298]

Hi Sai Ganesha,

You may have to limit your Select on LIPS with more parameters in the WHERE clause like using both Reference document number and Item in your SELECT.

Can you provide your SELECT on LIPS which is causing the runtime error so that the viewers will be able to help you better.

Regards,

Leenu

[former_member187748]

Hi Sai,

i will sujjest you to use inner join for the same, LIPS is a transparent table so use

inner join on LIPS and other transparent table you have used, this will limit your time out

problem, hope it will help you.

[Former Member]

Hi Sanjeev,

Here i am using one Transparent table and one internal table,We can't use innerjoin on internal tables...

[Former Member]

Hi Sai,

It is not problem of the select query! what is dump says. The secondary index is available in LIPS for preceding document.

I think so you are wrtten the select statement in the loop and end loop.

better to paste your code here.!

select vbeln posnr qty from LIPS where vgbel = sto po number.

Exactly how you are collecting!

Rg, Kiran

[Former Member]

Hi Sai,

This is wrong! why 15 seconds - just use 3 seconds or 2. since you are handling inside the loop to update for several STO's

WAIT UP TO 15 SECONDS.
   """"""""""""""""""""""""""""""""""""""
*  sort it_po by po.
   IF it_po IS NOT INITIAL.
     SELECT vbeln
            matnr
            vgbel
            lfimg
            FROM lips
            INTO TABLE it_lips
            FOR ALL ENTRIES IN it_po
            WHERE vgbel = it_po-po
            and erdat = sy-datum.  " avoid this from the select  (use the secondary index only )
   ENDIF.

if required DELETE IT_LIPS[] WHERE ERDAT NE SY-DATUM.

[Former Member]

Hi Kiran,,

If i put Wait upto 2 or 3 seconds within the loop.It will take..more time for each STO,So that i have put outside the loop.

[Former Member]

Hi Sai,

Just try the select and avoid the ERDAT from where clause.  If you will find the much difference!

check the ST05 ALSO.

[Former Member]

Actually i didn't put ERDAT field in Live program...For testing purpose i have included..

[Former Member]

Hi Sai,

The select statement is fine, Even  working fine to get the outbound deliveries for STO's.

Have you debug the program in PRD! what exactly the time consuming statement!

[Former Member]

No Kiran,I didn't run this program in Production....Actually DC people are running this in production..

[Former Member]

Hi Sai,

Just get the temporary debug access and trace the exact issue in the program

I think this is the better way to trace the error/correction, rather than assuming more things

Rg, Kiran

[Former Member]

Yah...Kiran,but if i will run this in production for testing purpose,it is creating STO's and OBD's..DC people are run this program in the early morning.

This is the runtime error.

[Former Member]

Is there any possibility to findout the program name based on Runtime errors in ST22?

[Former Member]

Yes, You can check the dumps and in which point it is happening!

[Former Member]

How to findout the report name using dumb error?

[Former Member]

Hi Check the ST22 selection!

you have the program name and user ID....

[Former Member]

Yes Kiran...I have found that...But still fetching data from LIPS table it is giving Time_Out error.How can i solve this issue?

[deependra_shekhawat3]

Hi Sai,

Why don't you use EKBE table, which confirms delivery creation against STO. You can check delivery by passing EKBE-VGABE = '8' and output BELNR is OTB. May be performance also could be boost up while passing EKBE-BELNR to LIPS-VBELN , as it is key field.

Thanks

Deependra

[arivazhagan_sivasamy]

Hi Sai Ganesha,

Are you trying save PO and get the report simultaneously?

If yes, it will take more time.. Because you are executing commit.

So, once you save the Po and comeout. Then run the report.

If No, please check whenever using for all entries option, internal table content.

Arivazhagan S

[Jelena_Perfiljeva]

Just wondering - why does everyone keep guessing and "throwing the darts" at the issue while if OP bothered to run ST05 (that has already been suggested by Kiran 10 posts above) or any other available performance trace tool it would probably give him/her an answer?

By the way, in case of the timeouts there is usually a performance problem and the exact place where it times out (which you'd see in the short dump) may have nothing to do with it. The program might spend lots of time in one place and then time out later in some other place (because the preceding code took too long). Inconceivable, I know...