ST05: Trace Directory
In this blog post of my series Use ST05 to Analyze the Communication of the ABAP Work Process with External Resources, I explain how you can store traces of your applications’ communication events as long as required. Beside giving you more time for in-depth analyses, stored traces pave the way to completely new types of investigations. Examples are:
- Check the temporal evolution of the applications’ use of external resources (before-after comparisons).
- Investigate the impact of user input or data volume on the applications’ performance or scalability.
- Compare the applications’ behavior between systems.
- Share traces with co-workers who do not have access to the system where the application was executed.
Some of your traces may be more important for you than other traces. But for
ST05, they are all the same and subject to the file system storage mechanism that cycles through the configured number of trace files. Due to this round-robin retention approach, even your most important trace is eventually lost—and this can happen before you have completed your analysis of this trace. For a more complete explanation of the process, please refer to my blog post ST05: Technical Background of Trace Recording and Analysis. It covers the trace recording in great detail, and gives a comprehensive description of the underlying mechanism. The trace directory integrated into
ST05 provides a solution by persisting traces into the database.
Save a Trace into the Trace Directory
Either way, a popup prompts you to give a Short Description of Trace (Fig. 1, inset) so that later you can reliably find your trace in the trace directory.
When you continue from this popup, the display formats of the trace records (as created on the fly by
ST05 from the raw data in the trace files on the application server instance’s file system) are stored in the database. Any restrictions you may have defined for the trace records in the Filter Conditions for Trace Records or in the ALV’s filter are respected: Only those trace records that match your selection criteria are stored in the database.
Traces that you save into the trace directory are given an Expiry Date, which by default is 120 days in the future. After this date they will be deleted automatically from the database. This mechanism prevents excessive growth of the underlying database table’s size due to old and most likely outdated, therefore useless, traces.
Display the Trace Directory
To navigate to the trace directory, click button Display Trace Directory on
ST05‘s start screen. This takes you to the Directory of Performance Traces (Fig. 2). In its two areas at the top, you can select from predefined filter conditions, or provide your own terms for the stored traces that you want to work with. The bottom panel shows the list of matching traces in an ALV grid control. By default, you see the traces you have created on the current day.
|Client||Client where directory entry was created.|
|User||User who saved trace.|
|Instance Name||Application server where trace was created.
(Always empty for traces stored in database.)
|Start Date||Start date of trace period.|
|Start Time||Start time of trace period.|
|Expiry Date||Date after which trace will be deleted from directory.
(Only used for traces stored in database.)
|Description||Description of trace.|
In the Trace Selection area, the default option My Traces restricts the list of traces to those trace directory entries that you have created. Optionally, you may decide to see traces of any user, or you select traces based on their owner (User), their Description, or their Expiry Date (Deleted Before). The selection criteria for User and Description support patterns with the wildcard characters
+ (single character) or
* (any character string). The Description is case sensitive. When you mark the checkbox All Clients, traces saved from every client in the system will be shown. Please note that the User is the one who has created the trace directory entry. This may be different from the user who has recorded the trace, or from the user whose activities were recorded. A similar remark applies to the Client field.
In the Time Period panel, you filter traces by their Start Date. The default is the current day (Today). Other restrictions are for traces from the current week (This Week) or by a Time Period. The option No Limit covers all traces, independent of their Start Date.
The conditions from the two panels are combined by logical
Work with Saved Traces
Trace records contain the name of the user who triggered the associated statement. This may conflict with local data privacy legislation. To remedy such collisions, you can anonymize persisted traces: Mark the relevant stored traces and select Anonymize Trace Records from the context menu (right-click the row header). In the ensuing popup, specify the user name to be anonymized. It will be replaced by a string of 12 alphanumeric characters. If you specify
* all user names will be deleted. No other wildcards are supported.
To prepare for the comparison,
ST05 summarizes, separately within each trace, the values for Total Number of Executions, Number of Records, Execution Duration, HANA CPU Time, and Redundant Identical Statements of all matching records. The default summarization criterion is the object affected by the statements, independent of the type or the structure of the statements. For finer granularity, distinct operations (
DELETE, ENQUEUE, DEQUEUE, …) can be resolved, or (for greatest detail) the operations and the statements. After this preparation, the summary records of the two traces are matched (by the combination of object, operation, or statement, corresponding to your chosen level of resolution), and their values are compared. The default comparison (Fig. 4) uses the values’ differences (absolute numbers). Optionally,
ST05 can express this as the percentages relative to the values of the first trace. Other alternatives show the ratios of the second trace’s values divided by those of the first trace, or the relative contributions to the corresponding total values of each trace.
The first column of each summary record in the comparison table encodes the record’s occurrence:
T1_: only in the first trace
T_2: only in the second trace
T12: in both traces
The trace directory integrated into
ST05 serves two main purposes:
- It prevents important traces from being overwritten by subsequently recorded traces.
This gives you more time for comprehensive analyses, e.g., to find optimization approaches.
- Two previously stored traces can be compared with each other.
With such a comparison you can investigate your application’s scaling behavior (related to its communication with external resources) to verify that its execution time or resource consumption grows at worst proportional to the amount of processed data.
Alternatively, with a trace comparison you may be able to demonstrate that your optimization project has been successful.
Traces exported to your front-end computer’s file system and then imported into another SAP system enable the comparison of your application’s behavior across systems. Such a comparison may reveal the impacts of differences in system configuration, process customizing, or available data volume on your application’s performance.