Show TOC

Procedure documentationException Analysis

 

In a solution landscape with several different components based on different technologies (such as the ABAP stack and the J2EE stack of an SAP Web Application Server), the analysis of exceptions becomes more and more complex. Every component writes to different logs and different tools are required to access these logs.

Various tools can be used for exception analysis in ABAP and J2EE environments. Although the same terms exist in both environments, like dump and application log, they do not always have the same meaning.

For example, in ABAP, an exception in a program can cause a dump. This dump causes the program to end but it does not have any impact on other programs running in the ABAP system. In Java, an “out of memory” error for a J2EE server node can cause a dump. After this dump, the server process restarts, which has an impact on all other users and programs running on this server node.

If a problem occurs in a business process that is distributed over several components, you may need to navigate from one tool to the next to determine in which component an exception occurred. With the exception analysis application in the SAP Solution Manager you have one single point of access where you can start the analysis.

The end-to-end exception analysis acts as a starting point for analyzing functional problems within a solution landscape. After identifying the exception that caused an incident, you can navigate to the expert analysis tool for this kind of exception. The end-to-end exception analysis also enables the support employee to correlate the different exception types, like ABAP dumps, J2EE dumps and the different application log files. Support then can use this correlated information to find the exception that was the root cause of the incident.

After identifying the relevant component and exception, component-specific analysis tools are used for in-depth component analysis. For example, the Log Viewer is used for analyzing the Java environment, while transaction ST22 is used for analyzing ABAP runtime errors.

Procedure

The end-to-end exception analysis tool can be used for two different use cases.

The first use case is an exception trend analysis, which covers the system behavior over a longer period of time. This analysis can clarify whether, for example, a single component in the solution creates a particularly high number of errors. Alternatively, the exception trend analysis can also determine whether the solution has a higher rate of errors after a change has been made to one of its components (for example, patches, support packages, or changes to configuration).

The second use case applies when the exact point in time of the incident is known, and the analysis is required to identify the specific component in which the error occurred. Here we recommend looking at not only the exact point in time of the exception and also a few minutes before and after this time.

To start an exception analysis, go to the area Root Cause Analysis:

  1. In the top level navigation, choose End to End Analysis.

  2. In the Detailed Selection area, choose the system(s) for which you want to make the exception analysis.

  3. In the header area of the Detailed Selection list, click the pushbutton Exception Analysis to start the analysis.

The Overview tab is displayed. On the right side of the graphic, the key performance indicators (KPIs) of the various components are displayed in the selected time frame.

Based on this graphic, you can determine which components and error types are involved. To define which error types from which components should be displayed, go to Start of the navigation path Diagram Properties Next navigation step Graph type End of the navigation path.

Two diagram types are available in the Diagram Properties:

  • The History diagram displays the number of errors in the individual components over a period of time. It shows whether or not the error behavior in the solution changed at a given point in time.

  • The Time Profile diagram displays the errors over a 24–hour period. It can be used to determine if errors occur more frequently at a certain time of day.

To perform an in-depth analysis of the individual components, you can refer to the component-specific tabs. Depending on the component, there are various views available. For example, for a pure ABAP stack there are views for ABAP SysLog Errors, ABAP Dumps, ABAP Update Errors and IDoc Errors. For a CRM server there are additional CRM-specific views.

You can always navigate within the different views for in-depth analysis in the same way.

Example Example

In the view ABAP SysLog Errors, the exceptions in the ABAP system log are displayed in a table. These exceptions are grouped according to Error Text, Severity, Problem Class and Application Component, and sorted according to the Number of errors.

End of the example.

However, the table does not display all of the possible fields; the fields that are not displayed can be viewed in a drill-down. To drill down to the other fields, click the right mouse button.

Fields highlighted in green indicate the jump-in functionality. By clicking on a jump-in field, a new window opens containing additional analyses. In our example with the ABAP SysLog Errors view, the jump-in leads directly to an ITS GUI in the ABAP System Log transaction (SM21) and the exception is displayed. In other views, the jump-in leads to other additional analysis applications, such as the Log Viewer or thread dump analysis.

Ideally, exception analysis narrows down the cause of a problem to a component and an exception. To perform the detailed analysis of an exception, component-specific tools remain indispensable.

Result

You have viewed data from which you can perform further analyses.