BDC PERFORMANCE!!!

[Former Member]

Hi! Kindly check the codes why is it that performance is very very slow. Hope you can give me some advice on how i can improve the performance this program.

REPORT zheg_hrpae001_mass_execution .

TABLES: pernr, "Use Table PERNR to Retrieve the personnel

bdcdata. "BDC Table

----

---

• INFOTYPES DECLARATION *

----

---

• In this section you can declare all infotypes that you are going to *

• use in your program. *

----

---

INFOTYPES: 0000, "Actions

0315. "Time Sheet Default

----

---

• TYPES/TYPE POOL DECLARATION *

----

---

• In this section you can declare all types and type pools that you *

• are going to use in your program. *

----

---

TYPES: BEGIN OF t_errorall,

msgid LIKE bdcmsgcoll-msgid,

msgnr LIKE bdcmsgcoll-msgnr,

msgv1 LIKE bdcmsgcoll-msgv1,

fldname LIKE bdcmsgcoll-fldname,

recno(50),

END OF t_errorall.

----

---

• DATA/VARIABLE DECLARATION *

----

---

• In this section you can define internal tables,variables and etc. *

----

---

DATA: i_errorall TYPE t_errorall OCCURS 0 WITH HEADER LINE,

w_errorall TYPE t_errorall,

v_recordname(50).

DATA: i_bdcdata LIKE bdcdata OCCURS 0 WITH HEADER LINE.

DATA: i_error2 TYPE bdcmsgcoll OCCURS 0,

w_error2 TYPE bdcmsgcoll.

DATA: v_begda TYPE dats, "Beginning date

v_date1(10) TYPE c, "Converted Begin date

v_read TYPE i, "Counter for identifying total records

v_process TYPE i, "Counter for identifying no error record

v_error TYPE i. "Counter for identifying total errors

----

---

• CONSTANTS DECLARATION *

----

---

• Constants are named data objects that you create statically using *

• a declarative statement. They allow you to store data under a *

• particular name within the memory area of a program. *

• The value of a constant cannot be changed during the execution of *

• the program. *

----

---

CONSTANTS: c_a(1) TYPE c VALUE 'A', "A Value

c_n(1) TYPE c VALUE 'N', "Background

c_date(4) TYPE c VALUE 'DYMD', "Date format

c_msgtyp(1) TYPE c VALUE 'E', "MSgtype E

c_endda TYPE dats VALUE '99991231', "End Date

***Start of Modification SIR-16196 by FEDERISOV 03/11/2005

c_active LIKE p0000-stat2 VALUE '3', "Active Employees

c_inactve LIKE p0000-stat2 VALUE '1', "Inactive Employees

***End of Modification by FEDERISOV 03/11/2005

c_x TYPE c VALUE 'X', "X Indicator

c_zero TYPE n VALUE '0'. "Zero value

TYPES: BEGIN OF t_0315,

pernr LIKE p0315-pernr,

endda LIKE p0000-endda,

stat2 LIKE p0000-stat2,

END OF t_0315.

DATA: i_0315 TYPE STANDARD TABLE OF t_0315,

w_0315 TYPE t_0315.

----

---

• START-OF-SELECTION *

----

---

• This event occurs after the selection screen has been processed and*

• before data is read using the logical database. *

----

---

START-OF-SELECTION.

GET pernr.

• PROVIDE pernr FROM p0315

• endda stat2 FROM p0000 BETWEEN pn-begda AND pn-endda

• WHERE p0000-endda = c_endda

• AND ( p0000-stat2 = c_active

**Start of Modification SIR-16196 by FEDERISOV 03/11/2005

• OR p0000-stat2 = c_inactve ).

**End of Modification by FEDERISOV 03/11/2005

PROVIDE pernr endda FROM p0315 BETWEEN pn-begda AND pn-endda

WHERE p0315-endda = c_endda.

• AND ( p0000-stat2 = c_active

***Start of Modification SIR-16196 by FEDERISOV 03/11/2005

• OR p0000-stat2 = c_inactve ).

CHECK p0000-stat2 eq c_active or p0000-stat2 eq c_inactve.

• IF p0000-endda = c_endda

• and ( p0000-stat2 = c_active or p0000-stat2 = c_inactve ) *

IF p0315_valid = 'X'.

• and p0315-pernr = p0000-pernr.

*

• PERFORM f_determine_date. "Determine the effective date

• PERFORM f_convert_date. "Convert the effective date

• PERFORM f_upload. "This will update the infotype 0315

w_0315-pernr = p0315-pernr.

APPEND w_0315 TO i_0315.

CLEAR w_0315.

ENDIF.

ENDPROVIDE.

----

---

• END OF PROCESSING *

----

---

• End of program processing. *

----

---

END-OF-SELECTION.

LOOP AT i_0315 INTO w_0315.

PERFORM f_determine_date. "Determine the effective date

PERFORM f_convert_date. "Convert the effective date

PERFORM f_upload. "This will update the infotype 0315

ENDLOOP.

PERFORM f_report. "Print / Audit Report

----

---

• FORM f_determine_date.

----

---

• Use to supply the effective date supplied in the selection screen

----

---

FORM f_determine_date.

IF pnptimr1 = c_x.

v_date1 = sy-datum.

ELSEIF pnptimr6 = c_x.

v_date1 = pnpbegda.

ENDIF.

ENDFORM.

----

---

• FORM f_convert_date.

----

---

• Use to covert the date in the standard format

----

---

FORM f_convert_date.

CALL FUNCTION '/SAPDMC/LSM_DATE_CONVERT'

EXPORTING

date_in = v_date1 "Date In

date_format_in = c_date

to_output_format = c_x

IMPORTING

date_out = v_date1 "Converted Date

EXCEPTIONS

illegal_date = 1

illegal_date_format = 2

no_user_date_format = 3

OTHERS = 4.

IF sy-subrc <> 0.

ENDIF.

ENDFORM.

----

---

• FORM f_upload.

----

---

• This will update the existing record in infotype 0315

----

---

FORM f_upload.

CLEAR i_bdcdata.

REFRESH i_bdcdata.

• PERFORM f_dynpro:

• USING 'X' 'SAPMP50A' '1000',

• USING ' ' 'BDC_CURSOR' 'RP50G-PERNR',

• USING ' ' 'RP50G-PERNR' w_0315-pernr,

• USING ' ' 'BDC_CURSOR' 'RP50G-CHOIC',

• USING ' ' 'RP50G-CHOIC' '0315',

• USING ' ' 'RP50G-TIMR6' 'X',

• USING ' ' 'BDC_OKCODE' '/00'.

PERFORM f_dynpro:

USING 'X' 'SAPMP50A' '1000',

USING ' ' 'BDC_CURSOR' 'RP50G-PERNR',

USING ' ' 'RP50G-PERNR' w_0315-pernr,

USING ' ' 'BDC_CURSOR' 'RP50G-CHOIC',

USING ' ' 'RP50G-CHOIC' 'Time Sheet Defaults',

USING ' ' 'RP50G-TIMR6' 'X',

USING ' ' 'BDC_OKCODE' '=INS'.

PERFORM f_dynpro:

USING 'X' 'MP031500' '2000',

USING ' ' 'BDC_CURSOR' p0315-begda,

USING ' ' 'P0315-BEGDA' v_date1,

USING ' ' 'P0315-KOSTL' p0315-kostl,

USING ' ' 'BDC_SUBSCR' 'ZP031500',

USING ' ' 'BDC_OKCODE' '=UPD'.

*Runs transaction on background

CALL TRANSACTION 'PA30' USING i_bdcdata

MODE c_n UPDATE c_a

MESSAGES INTO i_error2.

IF sy-subrc <> 0.

PERFORM f_bdc_error.

ADD 1 TO v_error.

ELSE.

ADD 1 TO v_process.

ENDIF.

ENDFORM.

----

---

• Form f_dynpro

----

---

• Subroutine used to populate the BDC table.

----

---

FORM f_dynpro USING fp_dynbegin

fp_name

fp_value.

IF fp_dynbegin EQ 'X'.

CLEAR bdcdata.

bdcdata-program = fp_name.

bdcdata-dynpro = fp_value.

bdcdata-dynbegin = fp_dynbegin.

APPEND bdcdata TO i_bdcdata.

ELSE.

CLEAR bdcdata.

bdcdata-fnam = fp_name.

bdcdata-fval = fp_value.

APPEND bdcdata TO i_bdcdata.

ENDIF.

ENDFORM. " F_DYNPRO

----

---

• Form f_bdc_error

----

---

• Check BDC Error when processing

----

---

FORM f_bdc_error.

CLEAR w_error2.

READ TABLE i_error2 INTO w_error2 WITH KEY msgtyp = c_msgtyp.

IF sy-subrc EQ 0.

MOVE: w_error2-msgnr TO w_errorall-msgnr.

• w_error2-msgv1 TO w_errorall-msgv1,

• w_error2-fldname TO w_errorall-fldname.

************************************************************************

*Capture errors in BDC background processing

************************************************************************

CALL FUNCTION 'MESSAGE_TEXT_BUILD'

EXPORTING

msgid = w_error2-msgid

msgnr = w_error2-msgnr

msgv1 = w_error2-msgv1

msgv2 = w_error2-msgv2

msgv3 = w_error2-msgv3

msgv4 = w_error2-msgv4

IMPORTING

message_text_output = w_errorall-fldname.

CLEAR v_recordname.

CONCATENATE text-001

w_0315-pernr

INTO v_recordname SEPARATED BY space.

MOVE: v_recordname TO w_errorall-recno.

APPEND w_errorall TO i_errorall.

CLEAR i_errorall.

ENDIF.

ENDFORM. " f_bdc_error

----

---

• Form F_OREPORT

----

---

• Writes the summary report of the program that will provide the

• number of records process, number errors and the location of errors

• in the BDC.

----

---

FORM f_report.

v_read = v_process + v_error.

*Output Report

WRITE: text-006.

ULINE.

WRITE:/ ,

/5 text-007,

36 v_read,

/5 text-008,

36 v_process,

/5 text-009,

36 v_error.

NEW-PAGE.

WRITE: /5 text-003,

20 text-010,

60 text-004.

ULINE.

CLEAR w_errorall.

LOOP AT i_errorall INTO w_errorall.

WRITE: /5 w_errorall-msgnr,

20 w_errorall-fldname,

60 w_errorall-recno.

CLEAR w_errorall.

ENDLOOP.

ENDFORM.

[christian_wohlfahrt]

Hi Federiso!

Make a runtime analysis (SE30) to identify the slow parts!

Only when the slow statements are identified, search for alternatives makes sense (otherwise you would spend a lot of time for changes without seeing difference in total runtime).

Regards,

Christian

[Former Member]

I already check the runtime of this program and it pass the performance. I saw the slow part of the program that was the BDC part because it updates all the records in inftotype 0315. How can i still improve the codes. It uses Logical Database PNP. Thanx!!!

[Former Member]

Hi,

Maybe instead of using call transaction you could insert the transactions onto the SM35 BDC queue. You could then batch the transactions (into groups of 10 for example) and submit RSBDCSUB for each batch. This would means that you process the BDCs in parrallel rather than the sequential approach you have now.

It could go something like:

FORM F_UPLOAD

  IF w_session_open IS INITIAL.
    CALL FUNCTION 'BDC_OPEN'.
    CLEAR: w_record_number.
    w_session_open = 'X'.
  ENDIF.

  <insert BDC logic here>.

  CALL FUNCTION 'BDC_INSERT'.
  w_record_number = w_record_number + 1.

  IF w_record_number >= 10.
    CALL FUNCTION 'BDC_CLOSE'.
    SUBMIT RSBDCSUB (passing unique BDC session name) AND RETURN.
    CLEAR: w_session_open
  ENDIF.
ENDFORM.

As RSBDCSUB creates a background job to process the BDC session, your program would continue whilst the BDC session was being processed.

As the sessions are being handled in SM35 you would also get a much nicer record of the errors, and it would allow you to replay them and correct interactively (rather than just having an error report).

Of course, this is just a quick sketch of a possible solution, but you could adapt the technique to suit the specifics of your implementation.

Hope that helps.

Cheers,

Brad

[Former Member]

Hi,

Forgot to mention. As RSBDCSUB will create a seperate background job for each batch of 10 transactions, these batches will also process in parrallel (if you have free batch work processes on your application server(s)).

Thus, you will get parrallel processing between your program and the BDC sessions, and further parrallel processing between the BDC sessions themselves. You should see a dramatic increase in the overall performance.

Care should be taken, however, so as not to flood your system with batch jobs and lock out critical processing.

Cheers,

Brad

Message was edited by: Brad Williams

[Former Member]

Hi Van,

The performance could be due to the index LIF on infotype 315. The system rebuilds the index after every insert via your BDC. Delete the index LIF by navigating to transaction SE11->Database Utility->Indexes and clicking on "Delete database index". After running your BDC , go back to SE11 and click on "Create database Index" and then click on "Activate and adjust database".

Prakash Singh