2010 Dec 08 10:37 AM
Dear gurus
My this codes take to much time to execute.
How to resolve it ?.
*&---------------------------------------------------------------------*
*& Form call_bapi
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* -->P_GOODSMVT_HEADER text
* -->P_GOODSMVT_ITEM text
*----------------------------------------------------------------------*
FORM call_bapi USING p_goodsmvt_header LIKE goodsmvt_header
p_goodsmvt_item LIKE goodsmvt_item.
DATA: materialdocument TYPE bapi2017_gm_head_ret-mat_doc,
matdocumentyear TYPE bapi2017_gm_head_ret-doc_year,
wa_return LIKE LINE OF return,
goodsmvt_code LIKE bapi2017_gm_code.
goodsmvt_code-gm_code = '04'.
CALL FUNCTION 'BAPI_GOODSMVT_CREATE'
EXPORTING
goodsmvt_header = p_goodsmvt_header
goodsmvt_code = goodsmvt_code
testrun = 'X'
IMPORTING
materialdocument = materialdocument
matdocumentyear = matdocumentyear
TABLES
goodsmvt_item = p_goodsmvt_item
* GOODSMVT_SERIALNUMBER = GOODSMVT_SERIALNUMBER
return = return
* GOODSMVT_SERV_PART_DATA = GOODSMVT_SERV_PART_DATA
* EXTENSIONIN = EXTENSIONIN
.
READ TABLE return WITH KEY type = 'E' INTO wa_return.
IF sy-subrc IS INITIAL.
MESSAGE ID wa_return-id TYPE wa_return-type NUMBER wa_return-number
WITH wa_return-message_v1 wa_return-message_v2 wa_return-message_v3 wa_return-message_v4.
ELSE.
CALL FUNCTION 'BAPI_GOODSMVT_CREATE'
EXPORTING
goodsmvt_header = p_goodsmvt_header
goodsmvt_code = goodsmvt_code
IMPORTING
* GOODSMVT_HEADRET = GOODSMVT_HEADRET
materialdocument = materialdocument
matdocumentyear = matdocumentyear
TABLES
goodsmvt_item = p_goodsmvt_item
return = return
.
* COMMIT WORK.
call function 'BAPI_TRANSACTION_COMMIT'
exporting
wait = 'X'.
SORT itab_final ASCENDING BY vbeln posnr.
DATA wa_itab LIKE wa_itab_final.
LOOP AT itab_final INTO wa_itab_final.
UPDATE zpacking_list SET posted = 'X' WHERE vbeln = wa_itab_final-vbeln AND posnr = wa_itab_final-posnr
AND mblnr IN ( SELECT mblnr FROM mseg WHERE werks = wa_itab_final-plant AND charg = wa_itab_final-charg ).
ENDLOOP.
MESSAGE i001 WITH materialdocument matdocumentyear.
LEAVE PROGRAM.
ENDIF.
ENDFORM. " call_bapi
2010 Dec 08 10:41 AM
Hi,
I find there is nothing to be done regarding the BAPI calls.
But, I think you should rewrite your UPDATE statement (especially because of the "nested SELECT"). I would rather process all entries in internal table using large SELECT (if required with working internal tables) and update the whole Z-table in one-pass.
Best regards,
Guillaume
Hi,
I find there is nothing to be done regarding the BAPI calls.
But, I think you should rewrite your UPDATE statement (especially because of the "nested SELECT"). I would rather process all entries in internal table using large SELECT (if required with working internal tables) and update the whole Z-table in one-pass.
Best regards,
Guillaume
2010 Dec 08 10:41 AM
Why 2 times CALL FUNCTION 'BAPI_GOODSMVT_CREATE' ?
Once is enough.
2010 Dec 08 10:41 AM
Hi,
I find there is nothing to be done regarding the BAPI calls.
But, I think you should rewrite your UPDATE statement (especially because of the "nested SELECT"). I would rather process all entries in internal table using large SELECT (if required with working internal tables) and update the whole Z-table in one-pass.
Best regards,
Guillaume
2010 Dec 08 12:35 PM
Hi,
Point 1:
Please check the code. You are reading RETURN table with TYPE = 'E' and if sy-subrc is not initial (i.e; BAPI fails) again you are calling the BAPI with the same data.
Point 2:
In the loop you are updating the DB table which will impact the performance. Avoid update in loop.
Regards,
Jaya krishna K
2010 Dec 08 12:43 PM
>
> Hi,
>
> Point 1:
> Please check the code. You are reading RETURN table with TYPE = 'E' and if sy-subrc is not initial (i.e; BAPI fails) again you are calling the BAPI with the same data.
>
> Point 2:
> In the loop you are updating the DB table which will impact the performance. Avoid update in loop.
>
> Regards,
> Jaya krishna K
Regarding 1.: If it's not initial, then he didn't find a E message and thus it was ok.
Regarding 2: update inside a loop is not per definition wrong. It's the inner select on MSEG that's causing a sequential read
2010 Dec 08 12:44 PM
1) The first call with test flag is not actually required, perform the call without test, and use a BAPI_TRANSACTION_ROLLBACK when an error is raised.
2) Do you actually need the "IN ( select MBLNR from MSEG WHERE werks =
wa_itab_final-plant AND charg = wa_itab_final-charg )." clause, check for MSEG indexes and other code to perform. (use SE30, ST05) - only werks and charg can give huge result/cpu without MATNR field
Regards,
Raymond
| User | Count |
|---|---|
| 3 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |