End-To-End Root Cause Analysis

Performing End-to-End Root Cause Analysis Using SAP Solution Manager

Michael Klöffer, Marc Thier

Contents

1 Introduction to End-to-End Root

Cause Analysis .............................................. 3

1.1 SAP Standards for End-to-End Solution

Operations .................................................... 4

1.2 Root Cause Analysis Standard at a Glance ... 6

Challenge ................................................. 6

Goal .......................................................... 6

1.3 The Basic Concept of the Root Cause

Analysis Standard .......................................... 6

Process Flow ............................................ 7

Architecture ............................................. 8

2 Root Cause Analysis in SAP Solution

Manager ........................................................ 13

2.1 Supportability Overview ............................... 13

2.2 Navigation Concept ...................................... 14

2.3 Help Center Concept .................................... 14

2.4 Case Study: Usage of Root Cause Analysis

for an End User Performance Problem ......... 16

3 End-to-End Change Analysis ....................... 23

3.1 Procedure ...................................................... 23

3.2 Tool Overview ............................................... 23

3.3 End-to-End Change Analysis ........................ 24

Analysis procedure ................................... 24

Architecture ............................................. 26

3.4 Configuration and File Reporting ................. 27


3.5 Compare Multiple Instances ......................... 28


4 End-to-End Workload Analysis ................... 31

4.1 Procedure ...................................................... 31

4.2 Tool Overview ............................................... 31

4.3 End-to-End Workload Analysis ..................... 31


Architecture .............................................. 34

4.4 Wily Introscope ............................................. 34


4.5 Java Memory Analysis .................................... 37


4.6 Thread Dump Analysis ................................... 38


5 Operation System and Database Analysis ... 43

5.1 Procedure ...................................................... 43

5.2 Tool Overview ............................................... 43

5.3 SQL Command Console ................................ 43

5.4 OS Command Console .................................. 44

5.5 File System Browser ...................................... 45

5.6 LDAP Browser ................................................ 47

6 End-to-End Trace .......................................... 49

6.1 Procedure ...................................................... 49

6.2 Tool Overview ............................................... 49

6.3 End-to-End Trace Analysis ............................ 49

Analysis procedure .................................. 50

Running a Trace ........................................ 50

Analyzing a Trace ...................................... 52

Architecture .............................................. 57

6.4 Wily Transaction Trace .................................. 59

7 End-to-End Exception Analysis ................... 61

7.1 Procedure ...................................................... 61

7.2 Tool Overview ............................................... 62

7.3 End-to-End Exception Analysis ..................... 62

Analysis Procedure ................................... 62

Architecture .............................................. 64

www.sap-press.com 1

Contents

7.4 Log Viewer .................................................... 66


8 End-to-End Availability Analysis ................. 69

9 How to Implement the Root Cause

Analysis Standard ......................................... 71

9.1 Installation and Configuration of Root Cause

Analysis Scenario ........................................... 71

Installation ................................................ 71

Installation Check ..................................... 72

Configuration ........................................... 72

Configuration Check ................................ 73

9.2 People Certification ....................................... 73

E2E Solution Operations —

Overview E-Learning E2E50 ..................... 73

Technical Core Competence Courses ...... 73

Technical Expert Competence

Workshops ................................................ 74

Management Competence Courses ......... 74

End-to-End Solution Operations

Starter Package ......................................... 75

9.3 How to Measure the Success of the

Implementation ............................................. 75

A Glossary ......................................................... 77

Index .............................................................. 79

2 © Galileo Press 2008. All rights reserved.

6 End-to-End Trace

As mentioned above, in a solution landscape with several

different components based on different technologies, it

is very challenging to isolate the component, which is the

root cause for a single issue. End-to-End Trace has a

mechanism for isolating a single user interaction through

a complete landscape and providing trace information on

each of the involved components for only this interac-

tion, starting with the user interaction in the browser and

ending with the data being committed to the database.

To do this, at the client, a client-independent proxy

and a client-dependent plug-in are installed, which pro-

vides unique correlations for scenarios, clicks, and

requests to the traffic between client and server. Client-

side trace data is transferred from the client to the man-

aging system via HTTP upload.

Currently, Java and .NET components are covered by

Wily Introscope tracing capabilities.

6.1 Procedure

The analysis of a long running user request starts with an

End-to-End Trace Analysis to identify the part of the

request that takes the most time. This information is use-

ful when doing a more in-depth analysis of this compo-

nent. The End-to-End Trace Analysis provides all the

functionality required for such an analysis.

If the outcome of an analysis is that the problem is on

the client side, you can use BMC AppSight to do a client

analysis. For this reason, SAP provides recording profiles

for the BMC AppSight Black Box, which records all client

activity in order to enable SAP to analyze the problem.

In the case of a network-related problem, we recom-

mend performing a network analysis, which is not cov-

ered in this SAP PRESS Essentials guide.

To analyze a problem in Java-based components, the

Wily transaction traces can be used to identify which part

of a request in a Java environment caused the problem.

Furthermore, the known tools for analysis of a problem

with an ABAP-based component can be used.

6.2 Tool Overview

The tools available in this area are:

� End-to-End Trace Analysis

This tool collects component-specific trace summaries

for both functional and performance analysis in order

to identify the process steps and technical compo-

nents, which require detailed analysis.

� ABAP SQL Trace

Also called Transaction ST05, the ABAP SQL Trace is

used on ABAP systems to analyze problems when

working with the persistence layer. The aggregated

ABAP SQL Trace is displayed in the End-to-End Trace

Analysis; a detailed analysis can be done on the ABAP

system.

� Wily Transaction Trace

The Wily Transaction Trace is a convenient tool for

tracing problems in the J2EE infrastructure. It is an

application that provides traces for J2EE applications,

showing the component sequence over time in rela-

tion to the component calling sequence.

6.3 End-to-End Trace Analysis

The most common use case of the End-to-End Trace

Analysis is identifying long running user requests within a

complex system landscape. It has capabilities for analyz-

ing across the complete system landscape, so that the

www.sap-press.com 49

6 End-to-End Trace

component causing the problem can be isolated and the

root cause can be identified. Therefore, the response

times of each component involved in the request execu-

tion and the request path through the involved compo-

nents are provided for a detailed analysis.

During an End-to-End Trace Analysis, the support

employee must check the distribution of the response

time over client, network, and server. After that, this

employee should check for manipulations in the HTTP

header (e.g., done by a proxy or another active network

component). SAP recommends filtering out cached

requests, because they’re usually quite fast, can be han-

dled locally on the client’s browser, and don’t include

server actions. Another common problem can be

requests that transfer large amounts of data from the

server to the client.

Analysis procedure

The End-to-End Trace Analysis is divided into two parts.

First, a trace must run and be recorded; second, the

recorded trace is evaluated. Before starting a new trace,

the support employee should ensure that the problem to

be analyzed could be reproduced.

Running a Trace

To run a new trace, the browser requires a plug-in to

instrument requests that are leaving the browser on the

client side. In addition, the systems on the server side

must be enabled to react to these instrument requests by

switching on certain trace functionalities. Figure 6.1

shows the plug-in’s user interface.

Figure 6.1 SAP IE Plug-in User Interface

The current version of the plug-in is available for down-

load as an attachment to SAP Note 1041556. Alterna-

tively, the plug-in can be downloaded directly from the

End-to-End Trace Analysis application. The links are

located in the Options section of the analysis application

(see Figure 6.2).

SAP plans to enable end users to download the plug-

in themselves using a link provided through email with-

out requiring access to SAP Solution Manager.

Figure 6.2 End-to-End Trace Analysis — Options

The plug-in is available in two versions: for Windows

Installer or as a self-extracting archive. The following

explanation is based on the self-extracting archive ver-

sion.

After the download, the plug-in is available as an exe-

cutable file SAPIEPlugin.exe. This file must be copied to

the client, from which the trace will run. When saving the

file, a new directory should be created, the naming of

which is up to the user. Before starting the trace, the

server side must be enabled; the related function is

located in the End-to End Trace Analysis tool on the Trace

Enabling tab (see Figure 6.3).

Figure 6.3 End-to-End Trace Analysis — Enable Trace



This tab displays the systems contained in the selected

solution. To enable a system to run traces, mark the cor-

responding row in the table and click the Enable All but-

ton. In the State column, a green icon indicates that a sys-

tem has been enabled to run traces. On the Options tab,

you can determine for how long the trace enabling is

valid. By default, tracing is automatically disabled after 30

minutes. When all preparations are complete, the trace

can run. To do this, activate the plug-in on the client side

by running the executable file SAPIEPlugin.exe. This

opens an empty browser window with the deactivated

plug-in user interface.

If you enter the browser URL, you can navigate to the

point where the error occurred without having to write

trace data. Then activate the plug-in before performing

the action to be analyzed. To do this, enter a name for the

business transaction and a name for the transaction step.

Both names can be freely defined by the user and will

only be used to identify the trace in the analysis tool later.

In the next field, select the trace level. Depending on the

settings, different traces can be activated on the server

side.

The different trace levels are used for different analyt-

ical purposes:

� Trace Level None

With this trace level, no trace is written on the server

side. This is helpful if you want to trace only the end

user experience on the client side.

� Trace Level Low

With this trace level, only the HTTP logs are written.

This is only useful for HTTP analysis, because it pro-

vides front-end response times, server response times

(HTTP logs), and derived network times.

� Trace Level Medium

This trace level provides the most important informa-

tion and is used for a performance trace.

� Trace Level High

This trace level is used for tracing functional issues,

technical correctness, and data consistency. Depend-

ing on the chosen location, this level could signifi-

cantly impact the response time and therefore should

not be used in a productive environment.

For more information about the trace levels and what is

included, see Table 6.1.

To enable the automatic upload of data on the client

side, enter the host name of the SAP Solution Manager

installation and the HTTP port in the user interface. If

there is no HTTP connection between the client and the

SAP Solution Manager host, the trace data can be

uploaded manually into the analysis tool at a later point

in time. Once all the settings are made, you can activate

the plug-in by clicking the Start button. At this point, all

requests will be instrumented and measured by the plug-

in. During the runtime of the transaction, the plug-in dis-

plays the bytes sent and received, as well as the number

of requests and responses. Furthermore, the maximum

number of physical connections and the currently active

connections are displayed. After the transaction has con-

cluded and the overall response is displayed in the

browser, a screen similar to Figure 6.4 should appear.

J2EE ABAP

Trace level

HTTP Log

SQL Trace

Logging IS Trans-action Trace

HTTP Log

SQL Trace

ABAP Trace RFC Enque/ Buffer

Authorization

none

low x xx x

medium x x x x x Aggregated xx

high x x x x x x Non aggregated

xx xx xx

x = Summary displayed in End-to-End Root Cause Analysis, xx = not displayed in End-to-End Root Cause Analysis

Table 6.1 Trace Levels in ABAP and Java


6 End-to-End Trace

If required, you can now trace additional transaction

steps. To do this, click New Step and enter a descriptive

name for the next transaction step. To stop the trace,

choose the Stop Transaction button. The trace data is

then automatically transferred to the analysis tool in the

SAP Solution Manager. If the automatic transfer is not

successful, an error message appears and you can upload

the data manually. The relevant file is the BusinessTrans-

action.xml, which is located in the plug-in directory, spe-

cifically in the folder logs and subfolder <timestamp>_

<transactionname>. To leave the browser window and

the plug-in, click the Exit button. In the next step, you

will analyze the trace.

Analyzing a Trace

If the trace data on the client side was automatically

transferred, you can now see the descriptive name of the

transaction as a new entry at the top of the table in the

Trace Analysis tab of the End-to-End analysis tool. You

may have to use the Refresh button for the entry to be

visible.

If you have to manually upload the file, use the entry

field Upload BusinessTransaction.xml located in the

lower part of this screen. First, select the correct server

side trace data to upload to the analysis tool. Make sure

that the correct solution is selected. Now you can mark

the new trace in the table. A dialog window appears, ask-

ing whether the correct solution was selected. After the

dialog window is confirmed, the progress display for the

data collection becomes visible. If this step is successful,

a screen similar to Figure 6.5 should appear.

Figure 6.5 End-to-End Trace — Collect Trace

The column State should display a green icon. The mean-

ings of the different icons are as follows:

� Grey Icon: Traces have not been collected yet.

Figure 6.4 End-to-End Trace — Start Trace



� Yellow Arrow: Traces are currently collected (by

another user session).

� Green Icon: Traces have been collected and saved suc-

cessfully.

As the traces are deleted by default automatically after 60

days, you may want to consider locking a trace against

deletion using the checkbox in the last column. The dele-

tion is triggered by entering the application.

The lower section of the screen lists the recorded

transaction steps in a table (see Figure 6.6).

Figure 6.6 Transaction Steps

To start the analysis, mark a transaction step in the table

and click Display. The Summary tab is displayed (see Fig-

ure 6.7). Here you can find the summarized information

on the collected trace and an overview of the most impor-

tant metrics that have been collected during the trace.

Figure 6.7 End-to-End Trace — Summary

The screen is divided into four sections:

� Client Trace Summary

This section contains all the values measured by the

SAP HTTP Plug-in.

� Time (accumulated)

In this section, the network time per HTTP request

between the browser and the first HTTP server compo-

nent is calculated as the difference of the browser

response time and the server time. The distribution of

the time intervals is displayed in a pie chart.

� HTTP Status Codes

This section (or table) contains all the returned status

codes for all requests. The distribution of the status

codes is displayed in a pie chart.

� Transaction Step details

In this section, all instances and server nodes that are

involved with direct HTTP communication are listed.

In addition to the statistics in the upper section, it is par-

ticularly interesting to see how the accumulated times are

divided. These numbers allow you to see at a glance

whether the performance problem is on the client, the

network, or the server.

The network time displayed in the pie chart is not

measured on network layer, but rather is calculated via

the difference between client response time and server

response time (see Figure 6.8). Therefore, the network

time must be seen as an approximation. The measure-

ment of the client response time takes place inside the

browser and starts when the first byte of an HTTP request

leaves the browser and ends when the last byte of an

HTTP response has arrived. Because of this type of mea-

surement, the client response time can be impacted in

several ways. In addition to network- and server-time, it

includes time that was spent by the browser, as well as

time spent by other processes running on the operating

system (e.g., virus scan, firewall).

Generally, the estimated network time reflects the

actual time when the User CPU Time ratio is very low, and

might be too high when the User CPU Time is very high.

In the example depicted in Figure 6.7, approximately

49 seconds are displayed as the time required on the

server side to execute the transaction step, which

amounts to 97 % of the total time required. This leads to

the assumption that the Root Cause Analysis should con-


6 End-to-End Trace

tinue on the server. Therefore, we will look at more

details about the request processing in the Messages

table tab (see Figure 6.9).

The Messages table shows that this single transaction

step consists of 46 separate requests. Each has its own

table entry with an ID, Time, Method, URL, and HTTP

Figure 6.8 End-to-End Trace Network Time Calculation

Browser Server

ServerResponseTime

BrowserResponseTime

NetworkDelay

NetworkDelay

Preprocessingand queueingtime

Rendering/loading ofsub-requests

Time

HTTP Plug-In writes repsone times and browser toBusinessTransaction.xml

HTTP Service write correlationID from header to http log file

HTTP Plug-In adds headerX-CorrelationID to each request

Figure 6.9 End-to-End Trace — Messages Table



Status. The additional columns display the following

details:

� ID

Identification number of HTTP request.

� Time

Timestamp taken from the client.

� Method

Used HTTP method.

� URL

Called URL. In the table, only the last part is displayed.

By selecting one line, the complete URL will be dis-

played above the table.

� Status

HTTP status code; for example, 2XX = Successful, 3XX

= Redirect, 4XX = Client Error, and 5XX = Server Error.

� cPT (Client Preprocessing Time)

It contains preprocessing and queuing time in the

browser.

� cRespT (Client Response Time)

It is measured on the client, starting when a request

leaves the browser until the response receives. Techni-

cally, it contains the time spent in the network and on

the server side.

� sRT (Server Response Time)

Time spent in the server that is taken from the HTTP

log.

� cRendt (Client Rendering Time)

Time required for rendering the page and loading

sub-requests.

� csBytes

Bytes sent from client to server.

� scBytes

Bytes sent from server to client.

Because the requests, which are processed from the

cache, aren’t important for the analysis, you can exclude

them from the display with the Hide Cached button (see

Figure 6.10).

In our example, there are now only five requests that

are processed on the server side. The request that

required the most time is highlighted in red in the column

sRT. This request has the ID 29 and was processed in

approximately 49 seconds on the server. To perform an

even more in-depth analysis, mark this request in the

table and the HTTP header view appears below the table

(see Figure 6.11).

The top left section displays the HTTP header of the

request (Client Request Header), as it was sent from the

client. Directly below this is how the server received the

header (Server Request Header). In the lower right sec-

tion, the header of the corresponding response (Server

Response Header) is shown as it was sent from the server

to the client. And above this, in the upper right, is how

the client received the response (Client Response

Figure 6.10 End-to-End Trace — Messages Table — Selected Request


6 End-to-End Trace

Header). The goal here is to determine whether there are

any differences between the sent and received data. The

differences may originate from network components,

such as proxy servers, along the transfer route, and may

be the reason for the error. In the example in Figure 6.11,

we can rule out any such manipulations as a cause for the

error. Below the HTTP section, you can review the Server

Analysis.

Figure 6.12 End-to-End Trace — Involved Systems

From the Summary tab (see Figure 6.12), you can see that

the approximately 49 seconds required for processing on

server side (from Figure 6.10 in column sRT) consist of

0.5 seconds in the J2EE-based system and 48.7 seconds

in the ABAP-based system. The Requests tree tab pro-

vides more details (see Figure 6.13).

Possible request types that can be displayed here include

the following:

� Incoming HTTP request

These values are taken from the HTTP logs.

� Incoming J2EE request

These values are taken from the Distributed Statistical

Records (DSRs).

� Outgoing J2EE request

These values are taken from the DSRs.

� Incoming ABAP summary

These values are taken from the ABAP statistical

records and correspond to an RFC/HTTP Server Desti-

nation record.

� Outgoing ABAP summary


records and correspond to an RFC/HTTP Client Desti-

nation record.

� Incoming ABAP request


records and correspond to an RFC/HTTP Server

record.

� Outgoing ABAP request


records and correspond to an RFC/HTTP client record.

Figure 6.11 Client Message Headers



In Figure 6.13, we can see that the request with ID 29

was received via HTTP from the J2EE system and then

processed by the Page Builder component. The process-

ing time was 242 ms (column Net for request with ID 29).

Then the request left the J2EE system and was processed

in the ABAP system. Here, four function modules were

executed, where the function module HRXSS_PER_INIT_

PERNR required approximately 47 seconds for process-

ing. Obviously, this function module is the cause of the

long runtime of the traced transaction. We can now

review the Distributed Statistic Records (DSR) and the Sin-

gle Statistic Records (SSR), see Figure 6.14.

Figure 6.14 End-to-End Trace — Statistical Records

Moreover, the table contains icons for a detailed analysis

of Java and ABAP. Figure 6.15 provides a legend for the

icons.

By clicking an icon, the corresponding data is displayed

in a new browser window. Figure 6.16 shows the ABAP

Trace Summary.

To display the complete ABAP trace, choose the Jump-

In icon in the table in the upper left section of the screen.

Based on the gross and net times, you can now make a

qualified statement on the cause of the long runtime of

the function module call.

The End-to-End Trace Analysis tool offers the added

feature of being able to graphically display the individual

requests. This allows you to see at a glance which request

is responsible for the long runtimes in the transaction

step. This graphical representation can be displayed in the

Messages graphics tab (see Figure 6.17).

Architecture

Tracing with a high trace level activated could have a neg-

ative impact on the system resources in the analyzed sys-

tem. It could increase the CPU usage as well as the stor-

age space in a database or file system. Therefore, it is

necessary that systems are protected against such situa-

tions. The system administrator can determine centrally

(in SAP Solution Manager) whether tracing in a managed

system is allowed (see Figure 6.18)

Figure 6.13 End-to-End Trace — Requests Tree


Index.NET framework 8

AABAP 8

ABAP Application Log 64

ABAP Dump 64

ABAP Extractor 9

ABAP Parameters 24

ABAP Runtime Error 61

ABAP SQL Trace 19, 49

ABAP System Log 64

ABAP Trace 31

ABAP Update Error 64

Accumulated Response Time 77

Application Error 61

Application Log 61

Application Management Team 4

apptracing 59

Average Response Time 77

BBackground Performance Metrics 77

BEx Queries 77

BEx Query Designer 77

BEx Web Templates 34, 77

BMC AppSight 49

BMC AppSight for SAP Client Diagnostics

19

Business Process and Interface Monitoring

5

Business Process Champions 4

Business Process Operations 4

Business Transaction 77

Business Transaction Step 77

CC(++) 8

Change Control Management 5

Change Group 26

ABAP 27

Change Request Management 5

Change Type 26

ABAP 27

Collect Configuration Data 27

Compare Multiple Instances 24, 28

procedure 28

ConfigStore 26

Configuration and File Reporting 23, 26,

27

procedure 28

Custom Development 4

Customer Organization 5

DDashboards 10

Data Integrity 5

Data Volume Management 5

Database Analysis 43

Database Monitor 31

DB Parameters 24

Dialog Performance Metrics 77

Distributed Statistical Records 57

EE2E Solution Operations Curriculum 73

Employee Self-Services (ESS) 16

End Users 4

End-to-End Availability Analysis 69

End-to-End Change Analysis 13, 23, 24

architecture 26

procedure 24

End-to-End Configuration Analysis Detail

Viewer 25

End-to-End Detail Viewer 25

End-to-End Exception Analysis 13, 61, 62

architecture 64

procedure 62

End-to-End Solution Operations Starter

Package 75

End-to-End Trace 18, 19, 49

architecture 57

End-to-End Trace Analysis 13, 49

procedure 50

End-to-End Workload Analysis 13, 31

architecture 34

procedure 32

Enhanced Change and Transport System

(CTS+) 23

eSOA Readiness 5

Exception Handling 5

Extractor Framework (EFWK) 8, 77

architecture 10

FFile System Browser 43, 45

Flight Recorder 66

Flight Recorder Dump 77

Full Thread Dump 77

GGranularity 77

HHealth checks 11

Help Center Concept 14

IIDoc Error 64

Incident Management 5, 7

InfoCube 77

Introscope Enterprise Manager 35

Introscope WebView 35

Introscope Workstation 35

IT Infrastructure Organization 4

JJ2EE Engine 26

J2EE Errors 65

Java 8

Java Application Availability 69

Java Memory Analysis 31, 37

procedure 37

Java Parameters 24

Java System Availability 69

Job Scheduling Management 5

Jump-in 77

KKey Performance Indicators (KPIs) 4

Key Users 4

LLandscape Model 78

LDAP Browser 43, 47

Log Viewer 62, 64, 66

procedure 66


Index

MMBean 59

MDX Queries 34, 78

Minimum Documentation 5

OOLAP Reporting 77

Operating System Monitor 31

Operation System Analysis 43

OS Command Console 43, 44

OS parameters 24

PPeople Certification 73

Portal Access 69

PPMS-ID 9

Program Management Office 4

Program Termination 61

RR/3 Workload Monitor 31

Remote Supportability 5

Response Times 32

Root Cause Analysis 3, 5, 6, 7

architecture 8

basic concept 6

challenge 6

configuration 72

configuration check 73

goal 6

implementing 71

in SAP Solution Manager 13

installation 71

installation check 72

key areas 13

navigation 14

SSAP CRM 64, 74

SAP ECC 6, 17

SAP ECC Server 24

SAP NetWeaver Business Intelligence 8,

14, 64, 74, 77

time zones 11

SAP NetWeaver Development Infrastruc-

ture 23

SAP NetWeaver Exchange Infrastructure

23, 74

SAP NetWeaver Portal 6, 15, 17, 23, 24,

26, 34, 74

SAP Solution Manager

Root Cause Analysis 13

scenarios 3

Service Desk 7, 17

SAP Solution Manager Scheduler 27

SAP Solution Manager Starter Pack 73

SAP Solution Support Enablement Pa-

ckage 19

SAP Technical Operations 4

SAPIEPlugin 50, 51

SAP-Passport 59

Scatter 32

Server Termination 61

Service Desk 17

Service Level Agreements (SLAs) 4

Service Level Reporting 11

Single Statistical Records 57

SQL Command Console 43

ST-(A)PI 71

Standards for End-to-End Solution Opera-

tions 3, 4

Support Packages 24

System Administration 5

System Error 61

System Log 61, 64

System Monitoring 6, 11

TThread Dump Analysis 31, 38, 64

procedure 38

Time Profile 32

Trace

analyze 52

running 50

Trace levels 51

Transaction

SLG1 61

SM21 61, 64

SM50 38

SMSY 9, 23, 72

SPRO 72

ST03N 31

ST04 19, 31

ST05 31, 49

ST06 31

ST22 61

Transaction ID 59

Transactional Consistency 5

Transport requests 24

TREX 24, 34

UUnicode 71

Upgrade 5

VView 78

WWily Dashboards 36

Wily Introscope 10, 31, 34, 49

for Portal 15

procedure 35

Wily Introscope Enterprise Manager 9, 71

Wily Investigator 37

Wily Metrics 36

Wily Traffic Lights 36

Wily Transaction Trace 49, 59

Workload Analysis

portfolio view 18

time profile 17

XX-CorrelationID 59


Documents

End-To-End Root Cause Analysis