Tracing HTTP Requests and Other Requests with the ABAP Runtime Analysis

You can use the ABAP Runtime Analysis to trace program executions in your system:

• That result from external calls into your system. You can trace, for example, HTTP or Web services requests, web dynpro requests, or RFC function calls that are processed in your system.

• When you do not know when or by which user a program or transaction will be started.

You can trace these kinds of activities with the user-trace feature of the ABAP Runtime Analysis. The user trace lets you start a trace automatically when conditions that you specify are met.

Here is the procedure for using the 'user trace' to trace program execution. We use the example of an HTTP request processed in your system.

Analyzing an HTTP Request That Is Processed in Your System

Assume that you need to analyze the program flow (or the performance) of an HTTP request that is handled by your system. Here is the procedure for analyzing the program flow of the request.

1. Start the ABAP Runtime Analysis by entering transaction SAT or choosing  System  Utilities  Runtime Analysis  Execute. 

2. Specify a variant that has Aggregation set to None.

   The resulting 'ABAP trace' measurement records trace events individually, so that you can search for particular ABAP statements.

   Be sure that the option Explicit Switching On and Off of Measurement is not marked on tab Duration and Type in the active variant.

3. Schedule a measurement. Click Schedule in the For User/Service frame on the SAT Measure tab.

   The Runtime Analysis shows you the Overview of Scheduled Measurements.

4. Click to specify the start conditions for a measurement.

   On the schedule dialog box, make the following specifications:

   • Leave User blank - the Runtime Analysis traces a call from any user, if it meets your other specifications.

   • Specify the client in which the call will be processed.

     Client 000 is used for anonymous HTTP requests. If no logon information is specified in a service definition (for example, in transaction SICF, the ICF Service Manager), then the logon occurs on the system default client.

     You can specify a client other than the one on which you are logged on. But you must specify a client, or the Runtime Analysis will fail to write a trace.

   • Set Server Name to <ALL> to trace the request no matter on which application server of the system it is processed.

     The Runtime Analysis schedules a measurement for each application server in your system. When the measurement has been done on one server, you can delete the scheduled measurements that you do not need.

   • Set Process Typ e to HTTP and Object Type to URL

     The Possible Entries help on these fields shows you the wide range of activities that you can measure. Not all of the possible combinations are sensible. For example, Process Type RFC and Object Type URL will never produce a trace.

   • In Object Name, type in the URN (path and service name) of the service. You can find the URN of a service in transaction SICF or in the Web Services Manager.

     For example, you could enter /sap/bc/ccms/monitoring/grmg_app.

   Leave the other fields unchanged.

5. Click on the dialog box to schedule the measurement.

   The measurement is added to the Overview with Status In Process.

6. Check whether the scheduled measurement has been done. Refresh the Overview of Scheduled Measurements.

   If the measurement has been made, then:

   • The Status of the measurement at the application server where the request was processed now shows Executed.

   • The Started column shows the number of traces that have been made.

     If Started continues to show the value 0, then no trace has been made. Ensure that you specified the correct client for processing, that the URN is correct, and that you were able to log on to the system successfully.

7. Display the measurement. Leave the Overview of Scheduled Measurements and display the new measurement from the Evaluate tab of the main SAT screen.

   If you traced a request in another client, then you must log on to that client to display the trace.

8. Stay on Desktop 1 if you are interested in the performance of the request handler.

   The Profile tool shows you the total runtime of the request handler in the top Runtime Measurement line.

   The Hit List tool on Desktop 1 shows you the most intensive aggregated users of runtime sorted according to their net runtime.

   The Hit List shows you top users from both the HTTP infrastructure, over which you have no control, and your application, over which you do have control.

   Return to the Profile tool and choose to display the trace events sorted by development package.

   Mark the package in which your application resides and choose and then Display Subarea in Hit List Tool to tell the Hit List to display only the entries that pertain to your application's package. Now you can evaluate the performance of your application code, in isolation from entries that pertain to the HTTP infrastructure.

9. Switch to Desktop 2 if you want to analyze the program flow of the request handler.

   Start with the Processing Blocks tool. This shows you a clean and clear view of the call stack of the request handler.

   Open the processing blocks hierarchy until you find the processing in your own application logic. You can do any of the following to analyze the execution of your code

   • Choose to search for processing blocks in your application code that consume conspicuous amounts of memory or processing time.

     You can use this function to scan the code in your request handler that might deserve optimization or refactoring.

   • Choose to tell the Processing Blocks tool and also the Call Hierarchy- also on Desktop 2- to display only the trace events that pertain to your code.

     In the filtered Call Hierarchy, you can analyze the processing in your application in detail. A double-click on any entry takes you to the corresponding location in the source code.

   • Double-click these entries to jump to the corresponding locations in source code. You can examine your code in detail and set breakpoints or watchpoints to help you analyze the code in the debugger.