How to deal with performance issues on back-end side

Identify the "bottleneck FM call" in the ECTR Console Logfile

Go to the ECTR log directory via the Windows System Tray:

In the log directory there is a file called "Console<date-time>.log". Here you can find the action you performed including the RFC function module which may had a long run-time.

Open the ECTR Console Log file and find the RFC function module call with poor performance:

In our example it is the FM "/DSCSAG/OBJ_GET_MULTIDETAIL2".

Prepare ECTR to measure this RFC function module with SAT

Prepare your test data, that you can immediate start the test.
Open the preference UI

Enter the name of the FM in the value for the Key "FM name for SAP analyzing" and press OK.

Execute the SAT measurement with ECTR

Now execute your use case (e.g. create a new document with ECTR).
Clear the value for the FM and press OK. - Do not forget to do this step!

Analyze the measurement with SAT
Open the transaction "SAT" in SAP GUI
Click on Evaluate and refresh the screen
Double click the entry

Now you have to ask an ABAP developer from your SAP basis to analyze this trace result before you open an SAP Incident.

For experienced user it makes sense to change the default settings and switch of the aggregation (None). Then you can see the bottleneck in detail. With switching Aggregation off, the analysis contains additional Tabs (Processing Blocks, Call Hierachy) that may be useful.

Example for an analysis of the SAT results

Do this analyse together with an ABAP developer of your company.

At first it makes sense to take a look in the tab "Times" and sort the table there for the field "Gross".

Here for example you can see, that the call of the RFC FM /DSCSAG/FOL_OPENDETAILS41 takes 32 seconds, but the call of the customer specific BAdI implementation "Z_DSCSAG_PLM" inside costs 29 seconds. With a double click you can jump inside the BAdI code.

Despite the fact that is not a performant idea to read classification details with the BAPI_DOCUMENT_GETDETAIL2 it is a pitfall to call the BAPI_DOCUMENT_GETDETAIL2 without setting the default values for e.g. GETACTIVEFILES not to space if the result is not needed.

Analyse your specific ECTR BAdI implementations

The apilog of ECTR provides valuable information for the analysis of performance problems.

#19 /DSCSAG/FOL3_OPEN
...
    TABLE: ET_RUNTIME (/DSCSAG/S_RUNTIME) , 5 row(s)
           | ACTION   | RUNTIME | ACTION_NAME           | TS_BEGIN | TS_END         | 
...
           | DSC_BADI | 492141  | FOL_OPENDETAILS_AFTER | 0        | 20190315064448 | 
...
TABLE: OUT_CUSTOMER_DATA (/DSCSAG/NAME_VALUE_DOKOB) , 126 row(s)
...

In this example 0,492 seconds are used in the customer specific BAdI call. Often an nonperformance implementation of the feature (How to add customer specific data fields to ECTR objects) causes this issue. The usage of the "fat" BAPI_DOCUMENT_GETDETAIL2 to read the classification in a loop does slow down performance of ECTR.

Scheduling Report /DSCSAG/OBSERVER_CLEAR

Schedule the Report /DSCSAG/OBSERVER_CLEAR as described in Installation_Guide section "Final Steps" and in detail in the configuration guide. This is mandatory to improve the general performance of ECTR.

Page tree