You have an ABAP code or a Web Dynpro that you would like to understand all the system calls made by it. Debugging could take for ages and you could not use for a reporting purposes.
You can use the Runtime Analysis function on SICF transaction to trigger a backend trace. If you join the correct variant to it you can get the most of your trace, such as:
- Function Module Calls
- Performs from FM
- Classes and Methods (including its callstack)
- Database tables
- Internal tables
Proceed with the three steps below. Item 1 is the same for ABAP and Web Dynpro trace. The difference is on steps 2 and 3, to run and evaluate the trace:
1. Define the Optimum Variant
If you don't define a Variant for your trace, you can't have it as efficient as it could be.
So you should:
a. Enter transaction SE30.
b. Define a name and click on Create Variant.
c. This step applies only for Backend trace and does not apply for HTTP Web Dynpro or BSP. Personalize the Program (parts) tab. By enabling the Particular Units flag, you can start the trace only when you want it, meaning that you can navigate on a transaction and define the exact moment you want to start the trace by inputting on the command box: /ron and disabling it via /roff.
d. Personalize the Statements tab. I have outline the ones which produce the best trace results. Beware that the most items you mark the bigger the trace will be.
e. Personalize the Duration/type. Normally, it's a good idea to increase the trace size. The most important step here is to set Aggregation -> None. This will allow us to group the trace by calls as you see next.
f. Save the Variant.
2. Running the Trace
a. For Backend Report/Transaction/FM
To trace on the backend only, it's very easy. You start the process via transaction SE30 directly.
a. Go to transaction SE30.
b. Enter either the transaction code, report name or function module that you want to monitor, select the variant configured previously and click Execute. Bear in mind that if you have particular units configured as per item 1c, the trace is NOT running at this point.
c. When you are on the correct part of the program that you want to trace, type /RON. The trace starts from this point forward.
d. When you identified that you have obtained everything you wanted, you can finish the trace by typing /ROFF.
b. For ABAP Web Dynpro / BSP
Before you start the trace, in order for you to trace exactly the information that you are looking to analyze, go to the Web Dynpro/BSP application screen and let it ready so that you can trigger the trace. After that, please perform as below:
a. Go to transaction SICF.
b. Select the Web Dynpro service that you want to do the trace.
c. Mark the Web Dynpro and click on the up menu: Edit -> Runtime Analysis -> Activate.
d. Select the Variant and user to trace. Normally, the backend user is different from the frontend user so this should be set here along with the Variant customized on item 1.
e. Execute the Web Dynpro/BSP. By this time, traces are being collected on the backend.
f. Deactivate the trace.
3. Review the Trace
In this step, you already have all the data collected on the backend and you want to review it for your analysis. Proceed as below:
a. Go to transaction SE30.
b. Under "Performance Data File" section, click on Other File.
c. Select the user that you ran the trace on item 2.
d. Identify the trace you ran by the HTTP comment on the next screen
e. Click on Group Hit List. If you haven't selected the Aggregation -> None on 1d you wouldn't have all the button you have on this screen, nevertheless the groupings would not be created.
f. The resulting screen appears. All the calls made by the Web Dynpro are grouped together by: METHOD, FUNCTION, PERFORM, EVENTS, Open SQL. If you double click in any entry, you have additional results regarding the report/include/etc who called that.
I hope this contributes for all consultants' analysis.