8.1 soaperformancemanagement

Date: 04-2009

Version 8.1

Date: 04-2009

CA Wily Introscope®

SOA Performance Management

Implementation Guide

6000 Shoreline Court, Suite 300South San Francisco, CA 94080

Copyright © 2009, CA. All rights reserved.

Wily Technology, the Wily Technology Logo, Introscope, and All Systems Green are registered trademarks of CA.

Blame, Blame Game, ChangeDetector, Get Wily, Introscope BRT Adapter, Introscope ChangeDetector, Introscope Environment Performance Agent, Introscope ErrorDetector, Introscope LeakHunter, Introscope PowerPack, Introscope SNMP Adapter, Introscope SQL Agent, Introscope Transaction Tracer, SmartStor, Web Services Manager, Whole Application, Wily Customer Experience Manager, Wily Manager for CA SiteMinder, and Wily Portal Manager are trademarks of CA. Java is a trademark of Sun Microsystems in the U.S. and other countries. All other names are the property of their respective holders.

For help with Introscope or any other product from CA Wily Technology, contact Wily Technical Support at 1-888-GET-WILY ext. 1 or [email protected].

If you are the registered support contact for your company, you can access the support Web site directly at www.ca.com/wily/support.

We value your feedback

Please take this short online survey to help us improve the information we provide you. Link to the survey at: http://tinyurl.com/6j6ugb

If you have other comments or suggestions about Wily documentation, please send us an email at [email protected].

US Toll Free 888 GET WILY ext. 1US +1 630 505 6966Fax +1 650 534 9340Europe +44 (0)870 351 6752Asia-Pacific +81 3 6868 2300Japan Toll Free 0120 974 580Latin America +55 11 5503 6167

www.ca.com/apm

mailto:[email protected]

http://tinyurl.com/6j6ugb

http://www.ca.com/wily/support

mailto:[email protected]

http://www.ca.com/apm

Contents iii

CONTENTS

Table of Contents

Chapter 1 Introducing CA Wily Introscope SOA Performance Management 11

About SOA and web services . . . . . . . . . . . . . . . 12

How Introscope SPM helps you manage SOA-based applications . . 13

About what Introscope SPM monitors . . . . . . . . . . . . 16

How Introscope SPM monitors SOA-based applications . . . . . . 17

Introscope SPM components . . . . . . . . . . . . . . . 18

Introscope SPM components for monitoring OSB . . . . . . . 21Introscope SPM components for monitoring WPS and WESB . . . 21

Capabilities of Introscope SPM by component . . . . . . . . . 21

Additional Introscope documentation . . . . . . . . . . . 23

Chapter 2 Installing and configuring Introscope SPM . . . . . . . . 25

Introscope SPM installation overview . . . . . . . . . . . . 26

Hardware and software requirements . . . . . . . . . . . 26

Introscope SPM Agent extension requirements . . . . . . . . 27Installation machine and directory names with documentation conventions . . . . . . . . . . . . . . . . . . . . 27

Introscope SPM install prerequisites . . . . . . . . . . . . 29

Installation prerequisite checklists . . . . . . . . . . . . 29

Summary of Introscope SPM installation steps . . . . . . . . 31

Downloading and extracting the installation archives . . . . . . 32

About Agent extensions . . . . . . . . . . . . . . . . . 34

Categories of Agent extensions . . . . . . . . . . . . . 34

Extracting Windows, Unix, and z/OS Java Agent extensions . . . . 35

Configuring Introscope SPM Java Agent extensions . . . . . . . 38

Uninstalling Introscope SPM Java Agent extensions . . . . . . . 39

Extracting and configuring Introscope SPM .NET Agent extensions . . 40

Configuring Introscope SPM .NET Agent extensions . . . . . . 42

Uninstalling Introscope SPM .NET Agent extensions . . . . . . . 47

iv Contents


Extracting Introscope SPM EM extensions . . . . . . . . . . 50

Configuring Introscope SPM EM extensions . . . . . . . . . . 53

Uninstalling Introscope SPM EM extensions . . . . . . . . . . 53

Configuring virtual agents for Introscope SPM . . . . . . . . . 54

Verifying your deployment . . . . . . . . . . . . . . . . 55

Agent and EM extension debugging options . . . . . . . . . . 56

Upgrading Web Services Manager to Introscope SPM . . . . . . 56

Uninstalling Introscope SPM . . . . . . . . . . . . . . . 59

Installing and configuring Introscope SPM OSB Agent and EM extensions 60

Downloading and extracting the Introscope SPM OSB installation archive . . . . . . . . . . . . . . . . . . . . . . 60

Extracting Introscope SPM OSB Agent extensions . . . . . . . 63Configuring Introscope SPM OSB Agent extensions . . . . . . 64

Uninstalling Introscope SPM OSB Agent extensions . . . . . . 65

Extracting Introscope SPM OSB EM extensions . . . . . . . . 66

Uninstalling Introscope SPM OSB EM extensions . . . . . . . 68Verifying your Introscope SPM OSB deployment . . . . . . . 68

Installing and configuring Introscope SPM WPS/WESB Agent and EM extensions . . . . . . . . . . . . . . . . . . . . . 69

Downloading and extracting the Introscope SPM WPS/WESB installation archive . . . . . . . . . . . . . . . . . . 70Extracting Introscope SPM WPS/WESB Agent extensions . . . . 72

Configuring Introscope SPM WPS Agent extensions . . . . . . 75Uninstalling Introscope SPM WPS Agent extensions . . . . . . 78

Configuring Introscope SPM WESB Agent extensions . . . . . . 79Uninstalling Introscope SPM WESB Agent extensions . . . . . . 81

Extracting Introscope SPM WPS EM extensions . . . . . . . . 82Uninstalling Introscope SPM WPS EM extensions . . . . . . . 84

Extracting and configuring Introscope SPM WESB EM extensions. . 85Uninstalling Introscope SPM WESB EM extensions . . . . . . . 87

Extracting and configuring WPS and WESB EM extensions on the same Enterprise Manager or MOM . . . . . . . . . . . . . . 88

Verifying your Introscope SPM WPS deployment . . . . . . . 89

Verifying your Introscope SPM WESB deployment . . . . . . . 90

Contents v


Chapter 3 Monitoring web services . . . . . . . . . . . . . . . . 93

Viewing web services data in Introscope SPM . . . . . . . . . 94

Starting the Introscope Workstation. . . . . . . . . . . . 95

SOA Performance Management dashboards . . . . . . . . . . 95

Introscope SPM Performance Overview dashboard . . . . . . . 96

Introscope SPM Client Health dashboard . . . . . . . . . . 99

Introscope SPM Server Health dashboard . . . . . . . . . . 100

Introscope SPM Most Critical Operations dashboard . . . . . . 101

Introscope SPM Most Dependent Operations dashboard . . . . . 102

Introscope SPM Busiest Operations dashboard . . . . . . . . 104

SOA Performance Management tabs . . . . . . . . . . . . 105

Using the Overview tabs . . . . . . . . . . . . . . . . 105

Using the Dependencies tabs . . . . . . . . . . . . . . 110About the Dependencies tab . . . . . . . . . . . . . . 114Using the Deviations tab . . . . . . . . . . . . . . . . 118Using the Most Critical tab . . . . . . . . . . . . . . . 124Using the Most Dependent tab. . . . . . . . . . . . . . 125

Using the Errors tab . . . . . . . . . . . . . . . . . 126

Viewing web service metrics in the Investigator . . . . . . . . 128

About Introscope SPM metrics . . . . . . . . . . . . . . 128

About error and SOAP fault metrics . . . . . . . . . . . . 129

Viewing agent web service metrics . . . . . . . . . . . . . 132

About the web service name node . . . . . . . . . . . . 134

About the operation name node . . . . . . . . . . . . . 135

Interpreting alert states . . . . . . . . . . . . . . . . 138Viewing Introscope SPM metric groupings and alerts. . . . . . . 138

Checking the health of your web services . . . . . . . . . . 140

Chapter 4 Using SOA Dependency Map to triage web service problems 145

Getting to know the SOA Dependency Map . . . . . . . . . . 146

SOA Dependency Map Concepts . . . . . . . . . . . . . 147What can I accomplish using SOA Dependency Map? . . . . . . 150

SOA Dependency Map components . . . . . . . . . . . . . 151

How Investigator tree nodes relate to SOA Dependency Map nodes. 155How Introscope SPM creates the SOA Dependency Map . . . . . 156

About how the SOA Dependency Map is saved . . . . . . . . 157

About SOA Dependency Map node aging and removal . . . . . 159

vi Contents


Setting up the SOA Dependency Map . . . . . . . . . . . . 159

Setting Introscope SPM metrics to display on the SOA Dependency Map . . . . . . . . . . . . . . . . . . . . . . . 159

Choosing a SOA Dependency Map content type . . . . . . . . 161

Choosing a SOA Dependency Map view . . . . . . . . . . . 166

Using SOA Dependency Map views and content types to solve your problems . . . . . . . . . . . . . . . . . . . . . 167

Navigating the SOA Dependency Map . . . . . . . . . . . . 169

Unrolling dependencies levels . . . . . . . . . . . . . . 169

Rolling up to hide dependencies . . . . . . . . . . . . . 169

Showing all operations for a service . . . . . . . . . . . . 170

Showing all services for an agent. . . . . . . . . . . . . 170

Jumping from a SOA Dependency Map node to the associated Investigator tree node . . . . . . . . . . . . . . . . 171Panning, zooming, and fitting the SOA Dependency Map . . . . 171

MOM SOA Dependency Map. . . . . . . . . . . . . . . 172

Reloading SOA Dependency Map upon discovery of new services and operations . . . . . . . . . . . . . . . . . . . 174

Using the SOA Dependency Map for triage . . . . . . . . . . 176

Outputting SOA Dependency Map images for sharing . . . . . . 177

Disconnected agents are grayed out. . . . . . . . . . . . 179

How renaming an agent updates the SOA Dependency Map . . . 179

Starting a Transaction Trace session from SOA Dependency Map . 180

SOA Dependency Map FAQs . . . . . . . . . . . . . . . 180

About Introscope SPM logical equivalence . . . . . . . . . . 184

Chapter 5 Using Transaction Tracing to triage web service problems . 185

About Introscope SPM cross-process transaction tracing . . . . . 186

Using cross-process transaction tracing to solve difficult problems . 188

Following an Introscope SPM transaction . . . . . . . . . . 190

Filtering Introscope SPM Transaction Traces . . . . . . . . . 196

Introscope SPM filters. . . . . . . . . . . . . . . . . 198

Viewing correlated events using Transaction Tracer . . . . . . . 201

Viewing web service data with Transaction Tracer. . . . . . . . 203

Viewing web service faults in ErrorDetector . . . . . . . . . . 204

Chapter 6 Monitoring Oracle Service Bus (OSB) . . . . . . . . . . 209

Using Introscope SPM to monitor OSB . . . . . . . . . . . . 210

Contents vii


Viewing OSB metrics . . . . . . . . . . . . . . . . . . 211

About OSB metrics . . . . . . . . . . . . . . . . . . 213Viewing OSB tabs and metrics . . . . . . . . . . . . . . 213

Viewing Business Services metrics . . . . . . . . . . . . 215Viewing Pipelines metrics . . . . . . . . . . . . . . . 216

Viewing Proxy Services metrics . . . . . . . . . . . . . 217

Viewing Transports metrics . . . . . . . . . . . . . . . 220

Viewing UDDI metrics. . . . . . . . . . . . . . . . . 227Viewing XQueries metrics . . . . . . . . . . . . . . . 229

Viewing OSB dashboards . . . . . . . . . . . . . . . . 230

OSB Home Dashboard . . . . . . . . . . . . . . . . 231

OSB Proxy Services - Overview dashboard . . . . . . . . . 232OSB Proxy Services - Details dashboard . . . . . . . . . . 233OSB Business Services - Overview dashboard . . . . . . . . 234OSB Pipelines - Overview dashboard . . . . . . . . . . . 235OSB Transports I - Overview dashboard . . . . . . . . . . 236OSB Transports II - Overview dashboard . . . . . . . . . . 237OSB Transports Endpoints - Overview dashboard . . . . . . . 238OSB XQuery - Overview dashboard . . . . . . . . . . . . 239OSB UDDI - Overview dashboard. . . . . . . . . . . . . 240

Viewing and creating OSB metric groupings . . . . . . . . . . 241

Viewing and creating OSB alerts . . . . . . . . . . . . . . 242

About OSB cross-process transaction tracing . . . . . . . . . 244

Following an OSB transaction . . . . . . . . . . . . . . 245

Viewing an OSB Transaction Trace . . . . . . . . . . . . 248

Viewing correlated events using Transaction Tracer . . . . . . 249

Chapter 7 Monitoring WebSphere Process Server (WPS) . . . . . . 251

Using Introscope SPM to monitor WPS and WESB . . . . . . . . 252

About WPS and WESB component metrics . . . . . . . . . . 253

WPS and WESB shared components . . . . . . . . . . . . 254

WPS-specific components . . . . . . . . . . . . . . . 255

About WPS and WESB metrics . . . . . . . . . . . . . . 256

Viewing WPS tabs and metrics . . . . . . . . . . . . . . 257

Viewing Business Processes metrics . . . . . . . . . . . . 259Viewing Business State Machines metrics . . . . . . . . . . 262Viewing Business Rules metrics . . . . . . . . . . . . . 263Viewing Human Tasks metrics . . . . . . . . . . . . . . 264

viii Contents


Viewing Interface Maps metrics . . . . . . . . . . . . . 265Viewing Selectors metrics . . . . . . . . . . . . . . . 266WPS Faults . . . . . . . . . . . . . . . . . . . . 268

Viewing WESB tabs and metrics . . . . . . . . . . . . . . 269

Viewing WPS and WESB shared component metrics . . . . . . . 271

Viewing Relationships metrics . . . . . . . . . . . . . . 271

Viewing Java Components metrics . . . . . . . . . . . . 272Viewing Business Objects Maps metrics . . . . . . . . . . 274Viewing Adapters metrics . . . . . . . . . . . . . . . 276Viewing Data Bindings metrics. . . . . . . . . . . . . . 277

Viewing Mediation Flow and Primitives metrics . . . . . . . . 279Viewing WPS and WESB Dashboards . . . . . . . . . . . . 283

Viewing WPS dashboards . . . . . . . . . . . . . . . . 284

WPS Overview dashboard . . . . . . . . . . . . . . . 284

WPS Business Processes & State Machines (Service Components I) dashboard . . . . . . . . . . . . . . . . . . . . . 285WPS Business Rules & Human Tasks (Service Components II) dashboard . . . . . . . . . . . . . . . . . . . . . 286WPS Interface Maps, BO Maps, & Relationships dashboard . . . . 287WPS Selectors & Java Components dashboard . . . . . . . . 288WPS Data Bindings dashboard . . . . . . . . . . . . . . 289WPS Adapters dashboard . . . . . . . . . . . . . . . 290WESB Mediation Flows dashboard . . . . . . . . . . . . 291WESB Mediation Primitives dashboard . . . . . . . . . . . 293

Viewing WESB dashboards . . . . . . . . . . . . . . . . 294

WESB Overview dashboard . . . . . . . . . . . . . . . 294

WESB Mediation Flows dashboard . . . . . . . . . . . . 295WESB Mediation Primitives dashboard . . . . . . . . . . . 297WESB Adapters dashboard . . . . . . . . . . . . . . . 298WESB BO Maps & Relationships dashboard . . . . . . . . . 299WESB Data Bindings dashboard . . . . . . . . . . . . . 300WESB Java Components dashboard . . . . . . . . . . . . 301

Viewing and creating WPS and WESB metric groupings . . . . . . 302

Viewing and creating WPS and WESB alerts . . . . . . . . . . 304

About WPS cross-process transaction tracing . . . . . . . . . 308

Following a WPS transaction . . . . . . . . . . . . . . 309Viewing correlated events using Transaction Trace . . . . . . 316

Contents ix


Appendix A Required configuration after Introscope .NET Agent install or up-grade 317

Reconfiguring after installing or upgrading the Introscope .NET Agent ver-sion . . . . . . . . . . . . . . . . . . . . . . . . 318

Appendix B Introscope SPM Agent extension configuration properties . 319

Introscope SPM Agent extension configuration . . . . . . . . . 320

Introscope SPM Agent extension configuration properties . . . . . 321

Appendix C Introscope SPM EM extension configuration properties . . . 325

Introscope SPM EM extension configuration . . . . . . . . . . 326

Introscope SPM EM extension properties . . . . . . . . . . 327

Appendix D Introscope SPM Workstation configuration properties . . . 339

Introscope SPM Workstation configuration . . . . . . . . . . 340

IntroscopeWorkstation.properties file properties . . . . . . . 342

Index . . . . . . . . . . . . . . . . . . . . . . . . . . 347

x Contents


Introducing CA Wily Introscope SOA Performance Management 11

CHAPTER 1

Introducing CA Wily Introscope SOA Performance Management

This chapter includes these topics:

About SOA and web services . . . . . . . . . . . . . . . 12

How Introscope SPM helps you manage SOA-based applications . . . . 13

About what Introscope SPM monitors . . . . . . . . . . . . 16

How Introscope SPM monitors SOA-based applications . . . . . . . 17

Introscope SPM components . . . . . . . . . . . . . . . 18

See Monitoring WebSphere Process Server (WPS) on page 251. . . . . 21

Introscope SPM components for monitoring OSB . . . . . . . . . 21

Introscope SPM components for monitoring WPS and WESB . . . . . 21

Additional Introscope documentation . . . . . . . . . . . . 23

12 Introducing CA Wily Introscope SOA Performance Management


About SOA and web servicesClassic client-server architectures supported direct communications between clients and servers. When outages occurred, it was easy to pinpoint a failure because the possible sources were limited to only three or four systems.

Later architectures used standardized application servers as an infrastructure component, and the web application server became a central point of coordination across multiple client-server systems. This architecture greatly complicated application management because an application failure could originate almost anywhere within the IT infrastructure.

Service-Oriented Architecture (SOA) introduces a new layer of coordination across the enterprise. In its most basic form, SOA is simply an application architecture that takes loosely coupled services available on the Web and connects them to form an application for a given business process. These services, called web services, have become a standard means of interoperating and communicating between software applications that are extensible, meaning running on a variety of platforms or frameworks. Web services can range from simple requests to complex business processes.

SOA allows for faster and more cost-effective application development, based on the assumption that once a particular service is defined, it can be reused by a number of business processes rather than re-inventing that service for every business process with a similar need. Faster application development means that organizations can be more agile and introduce new business-process functionality in response to market or product dynamics.

For example, introducing a new business rule no longer requires rebuilds of the environment and all the dependent applications—it simply requires configuring one or two components. De-coupling business logic from deployed applications and making logic rules editable at runtime enables enterprise IT architects to provide a highly dynamic environment.

How Introscope SPM helps you manage SOA-based applications 13


Here are the components of a sample SOA implementation.

CA Wily’s approach to monitoring provides a uniform, coherent view of a SOA application. The real-time transaction tracking across heterogeneous environments such as J2EE and .NET gives your IT personnel a set of tools they can use to monitor application performance, triage incidents, and diagnose problems—without the need to access or modify application source code.

How Introscope SPM helps you manage SOA-based applications

While SOA applications tend to simplify the implementation of a business process, the underlying delivery infrastructure moves in the opposite direction. The infrastructures that are used to deliver SOA services are typically very complex and have a lot of heterogeneity. Therefore, your organization needs to carefully manage these infrastructures. CA Wily addresses the application performance management aspect of your complex and mission-critical SOA environment.



CA Wily Introscope SOA Performance Management (Introscope SPM) provides comprehensive real-time and historical views into web services, web applications, the SOA infrastructures such as an Enterprise Service Bus (ESB) and Business Process Management System (BPMS), and the back-end systems to which they connect. This allows your IT personnel to monitor critical services around the clock, detect problems proactively, and perform root-cause analysis when issues arise. This figure shows the highest-level Introscope SPM product monitoring capabilities. As with Introscope, Introscope SPM provides a single solution across J2EE and .NET.

When a problem surfaces in these complex environments, often it is hard to know where to start looking for the source. CA Wily uses the term triage to mean how you identify the nature of a problem, then where you need to go for resolution. With continuous monitoring of web service transactions, Introscope SPM can detect potential failures as they are developing. In many cases, this proactive approach helps you identify and correct a failing component before it actually affects your customers or end users. If the first indication of a problem is a phone call from a user, its already too late and the problem situation is likely to go from bad to worse.

Drill down on the end user experience.

Drill down on SOA infrastructure availability and performance.

Drill down on back-end availability and performance.

How Introscope SPM helps you manage SOA-based applications 15


If your organization has already implemented SOA, your environment probably consists of cross-platform SOA, because business and IT have consolidated in many firms. Introscope SPM has the visibility to monitor and manage your entire infrastructure, including transactions that span multiple operating platforms such as J2EE and .NET. Introscope SPM allows you to use one tool to provide the same level of information about the transactions that cross these platforms, as well as use the same vocabulary to discuss with your IT colleagues what you are seeing.

Introscope SPM delivers the detailed information that your organization’s architects and developers need to quickly isolate and resolve problems: views of individual transactions in which web services are involved, the number and nature of web service faults, and component interactions. In this simple buy transaction example, a number of web services (ws) are used to transmit requests and responses between external and internal applications, application servers, and back-end systems.



When an incident occurs—for example, the response time for a particular web service slows due to thread pool starvation—an alert can notify the appropriate stakeholders of the problem before a service level agreement (SLA) is violated or an end-user is affected. To gather information about the nature of the problem, your Application Support manager can view detailed error data in the context of individual transactions, view the slowest web services to isolate the worst offenders, and view socket bandwidth metrics to get crucial information about message throughput.

An incident is not always due to failure of the physical hardware components. A transaction, which consists of one or more web service invocations along with other pieces of logic, can fail. An individual web service invocation can fail for a number of reasons including:

the request message does not reach the intended destination (undelivered request message)

the application logic fails, causing the web service not to send a response (faulty application logic)

the response message is not delivered (undelivered response message).

» Note All three of these failures can occur in a synchronous, request-response web service. In an asynchronous one-way web service, the undelivered response message cause does not directly occur.

In a transaction failure, operations personnel can use Introscope SPM to monitor and audit end-to-end business transactions, create alerts, and report on incomplete processes.

Once a problem has been flagged and identified, web services architects or developers can use Introscope SPM to diagnose the root cause and drill into web service errors.

See Viewing web service metrics in the Investigator on page 114 for more information about viewing web services data.

About what Introscope SPM monitorsSOA provides the latest generation of composite applications, and is often a new technology layered on top of your existing infrastructure. However your SOA environment may be also be a hybrid extension of existing technology using a variety of transports and payload types. While SOA architecture provides services flexibility and reuse, it can also have many moving parts, especially if your organization has grown rapidly, resulting in more applications than you can reasonably track.

How Introscope SPM monitors SOA-based applications 17


Introscope SPM provides broad and deep SOA performance management capabilities, including monitoring and reporting metrics about what’s been deployed in your SOA environment including the:

web services

non-standard services that do not use the SOAP protocol including

XML over HTTP (also known as REST-based services)

JMS over HTTP

SOA infrastructure, especially the ESB and BPMS.

How Introscope SPM monitors SOA-based applications

All monitoring performed by Introscope is carried out by the Introscope agent. Monitored data is recorded and sent to an Enterprise Manager. Introscope SPM adds an extension to the Introscope agent, and a separate extension to the Enterprise Manager.

Introscope SPM works with Introscope to monitor Java and .NET web services for application servers. The Introscope SPM Agent extension measures information about an application that’s using web services and sends the web services data to the Enterprise Manager. The Enterprise Manager provides compiled data to the Workstation for viewing in dashboards and the Investigator tree.

Introscope SPM organizes web service client and server data separately, with client and server metrics displayed in separate nodes of the Introscope Investigator tree:

The client is the component that makes requests to a web service. For example, any Java class that makes a service request to get a stock quote can be considered a web service client.

The server is the component that implements a web services function. For example, a Stock Quote web service is a server—it provides the price for the stock-quote client.

A client and server of a web service usually reside in separate processes—that is, in Java Virtual Machines (JVMs) or Microsoft’s Common Language Runtime components (CLRs). An Introscope agent reports data per JVM or CLR, so client and server data for a web service are reported by two or more agents.

To see metrics for both client and server agents aggregated together, configure a Virtual Agent. See Configuring virtual agents for Introscope SPM on page 54.

An enterprise application can contain both client and server components.



By using Introscope SPM and Introscope together you can:

Isolate problems to the web service, application, or back-end, while detecting and reporting on web service faults and errors

Build a web service audit trail by verifying web service invocation receipt and completion

Understand the dependencies between web services so that you can assess the impact of a problem

Track web service invocations across different SOAP stacks

Create application groups of web services, and know whether a group is exceeding response time, transaction volume, and/or error thresholds

Understand the context of an error or emitted SOAP fault.

About SOA dependencies types

When a web services transaction takes place, some web services can be dependent on other web services. There are two types of SOA dependencies between web services:

between server-side and client-side

In this case, the dependencies occur within a single application-server and are determined from data supplied by a single agent.

between client-side and server-side web services.

In this case, the dependencies occur between two application servers and are determined from data supplied by two different agents.

In Introscope SPM, as SOA dependencies are discovered, they are added to the SOA Dependency Map. See Getting to know the SOA Dependency Map on page 146.

Introscope SPM componentsIntroscope SPM sits on top of the Introscope platform to enable monitoring and management of web services in SOA applications. Introscope SPM includes four main components:

Introscope SPM Agent extension - (extends the Introscope agent)

The Introscope SPM Agent extension, installed on top of the Introscope agent, is a software component that sits in-stream of the web service invocations. In operation, each agent listens for web service transactions.

Introscope SPM components 19


Introscope SPM EM extension - (extends the Introscope Enterprise Manager)

The Introscope SPM EM extension is a component used to provide the Introscope SPM-specific Introscope management module, web services-related metrics, dashboards, and tabs.

Introscope SPM management modules, which provide Introscope SPM-specific Introscope dashboards and tabs.

A management module contains Introscope monitoring configuration information. Management modules are listed for each domain, and contain elements, which are objects that contain and organize data with monitoring logic such as actions and dashboards. For more information about management modules, see the Introscope Configuration and Administration Guide.

SOA Dependency Map, which provides a graphical way for you to view and understand the interdependent agents, services, and operations in your SOA environment.

The SOA Dependency Map displays real-time dependencies and metrics for your web services agents, services, and operations that are automatically generated from performance metrics and analysis of metrics, errors, and events.



This figure illustrates how Introscope SPM monitors web services in web applications deployed on J2EE or .NET servers.

Introscope Workstation

Web Service Metrics and Alerts

Introscope SPM Administrator

Thin Client Interface

Capabilities of Introscope SPM by component 21


Introscope SPM components for monitoring OSB

Introscope SPM includes Agent and EM extensions for monitoring your Oracle Service Bus (OSB) environment. You can view OSB-specific dashboards, tabs, and metrics to assess and triage your OSB application performance management issues.

See Monitoring Oracle Service Bus (OSB) on page 209.

Introscope SPM components for monitoring WPS and WESB

WebSphere Process Server (WPS) includes Websphere Enterprise Service Bus (WESB) as well as some additional components. WESB manages the flow of messages in WPS and handles any data transformation or routing required between services and clients with the help of mediation flows and primitives.

IBM also provides Websphere Enterprise Service Bus as a standalone product.

Introscope SPM includes Agent extensions and EM extensions for monitoring both these environments. You can choose to install Introscope SPM components that monitor WPS or WESB standalone. You can view WPS- or WESB-specific dashboards, tabs, and metrics to assess and triage your application performance management issues. When Introscope SPM monitors WPS, Introscope displays health data for both WPS and WESB. When Introscope SPM monitors WESB only, Introscope displays health data about WESB only, not about WPS-specific components.

See Monitoring WebSphere Process Server (WPS) on page 251.

Capabilities of Introscope SPM by componentIntroscope monitors performance and availability of web applications, and provides comprehensive metrics through the Introscope Investigator and dashboards.

When you add Introscope SPM to Introscope, you get the full capabilities of Introscope in addition to functionality specific to web services.



This table describes these capabilities and the associated Introscope SPM component.

Product Component Capability

Application Overview tab You can use the Application Overview tab to view metrics at the front-end or the back-end of your application, as well as monitor the health of an overall web application.

See Using the Overview tabs on page 105 and the Introscope Workstation User Guide for more information about Application Overview.

Introscope metrics for web services

These web services metrics are provided in separate client and server nodes in the Introscope Investigator tree: Average Response Time Concurrent Invocations Errors Per Interval Responses Per Interval SOAP Faults Per Interval Stall Count

Out-of-the-box SOA Performance Management dashboards

Introscope SPM comes with custom Introscope dashboards and alerts to monitor web services-specific data. You can also customize the dashboards to fit the needs of your environment.

Dashboards show information divided by clients and servers, with data viewers for these statistics: Top 10 slowest web services Top 10 slowest web service operations Summary alerts for all web services (per client and server) Average operation response times for clients Average operation response times for servers Web service faults (SOAP Faults/Errors) Web service response statistics (responses per interval) Average web service response times for clients Average web service response times for servers

Capabilities of Introscope SPM by component 23


Additional Introscope documentation

See these documents for detailed information about Introscope:

Introscope Configuration and Administration Guide

Introscope ErrorDetector Guide

Introscope Installation and Upgrade Guide

Introscope Java Agent Guide

Introscope .NET Agent Guide

Introscope Overview Guide

Introscope Sizing and Performance Guide

Introscope Workstation User Guide

Introscope PowerPack for IBM® WebSphere® Application Server Distributed User Guide

Product Component Capability

Agent extension Based on your operating system and platform, when implementing Introscope SPM you install and configure this software component that sits in-stream of the web service transactions. In operation, each agent listens for web service transactions.

EM extension You extract this software component that provides Introscope SPM-specific Introscope dashboards and tabs.

Transaction Tracer Introscope SPM is integrated with the Introscope Transaction Tracer. Using Transaction Tracer, you can monitor web service transactions both within a web application and across SOAP stacks, see a web service within an entity’s trace, and run Transaction Traces against a web service URL.

SOA Dependency Map tab Introscope SPM provides the SOA Dependency Map as a graphical way for you to view and understand the interdependent agents, services, and operations in your SOA environment.

SOA Dependency Map displays real-time dependencies and metrics for your web services agents, services, and operations that are automatically generated from performance metrics and analysis of metrics, errors and events.

Agent and EM extensions for OSB

You extract these software components that provide Introscope SPM OSB-specific Introscope dashboards and tabs.

Agent and EM extensions for WPS and standalone WESB

You extract these software components that provide Introscope SPM WPS or WESB-specific Introscope dashboards and tabs.

Installing and configuring Introscope SPM 25

CHAPTER 2

Installing and configuring Introscope SPM


Introscope SPM installation overview . . . . . . . . . . . . 26

Introscope SPM install prerequisites . . . . . . . . . . . . . 29

Summary of Introscope SPM installation steps . . . . . . . . . 31

Downloading and extracting the installation archives . . . . . . . 32

Downloading and extracting the installation archives . . . . . . . 32

Extracting Windows, Unix, and z/OS Java Agent extensions . . . . . 35

Extracting and configuring Introscope SPM .NET Agent extensions . . . 40

Extracting Introscope SPM EM extensions . . . . . . . . . . . 50

Configuring Introscope SPM EM extensions . . . . . . . . . . . 53

Uninstalling Introscope SPM EM extensions. . . . . . . . . . . 53

Configuring virtual agents for Introscope SPM. . . . . . . . . . 54

Verifying your deployment . . . . . . . . . . . . . . . . 55

Uninstalling Introscope SPM . . . . . . . . . . . . . . . 59

Installing and configuring Introscope SPM OSB Agent and EM extensions . 60

Installing and configuring Introscope SPM WPS/WESB Agent and EM extensions69

26 Installing and configuring Introscope SPM


Introscope SPM installation overviewThis chapter provides steps for downloading and then installing Introscope SPM product components from the CA Wily Software download site. Based on the product that you purchased, you will receive authorization codes that permit you to download specific Introscope and Introscope SPM components. The component installation archive files either contain an installer that should be extracted and then executed, or a set of files that should be extracted after which manual deployment steps should be carried out as documented in the relevant sections below.

The various available Introscope SPM installation archives that you can choose from on the CA Wily Software Download Site include:

Windows Java

Unix (AIX, Linux, Solaris)

z/OS

Windows .NET

See Downloading and extracting the installation archives on page 32.

A link to the CA Wily Software Download Site is provided to you in a software delivery email.

Hardware and software requirements

Introscope Agent and Enterprise Manager requirements

These are the minimum version requirements for Introscope components used in Introscope SPM:

Introscope Component Minimum Version Supported

Java Agent 8.1.0.0

.NET Agent 8.1.0.0

Enterprise Manager 8.1.0.0

The Enterprise Manager version must be later than or equal to the Agent version.

ErrorDetector 8.1

Introscope SPM installation overview 27


Introscope SPM Agent extension requirements

The minimum requirements needed for the Introscope SPM Agent extension processor, RAM, and available disk space are the same as the minimum system requirements for Introscope. See these guides for the Introscope requirements:

Processor, RAM, Available Disk Space - see the Introscope Installation and Upgrade Guide, Introscope Configuration and Administration Guide, and the Introscope Sizing and Performance Guide.

JVM and JRE version - see the Introscope Java Agent Guide for the minimum JVM and JRE version required for installing the Introscope Agent.

» Note The operating system requirements for the agents also depend on the supported SOAP engines.

Installation machine and directory names with documentation conventions

This guide uses these conventions for names of installation directories, path separators, and environment variables:F

This name convention... refers to...

<Agent_Home> The directory where the Introscope Agent is installed. This is typically a directory called wily.

<EM_Home> The directory where the Introscope Enterprise Manager is installed.

<ProductName_Home>

<ApplicationType_Home>

The installation directory of a third party product or type of application. For example, <SAP_Home> is the installation directory of SAP NetWeaver.



Path separators: /

Environment variables: $

The path separator or environment variable notation used on your platform. The UNIX versions are used in this guide as examples, but you should use the style appropriate to the platform.

FileName<version><operating system or other identifier>.FileType

Introscope or Introscope SPM file name that includes a version-specific identifier.

Here are some examples.

You might read in this guide:

IntroscopeSOAPerformanceManagement<version>windows.zip

and see this file on the CA Wily Software Download site:

IntroscopeSOAPerformanceManagementV8.1.0.0windows.zip


com.wily.introscope.soa.tracefilters.common_<version>.jar

and see this file on your machine:

com.wily.introscope.soa.tracefilters.common_8.1.0.0.jar


com.wily.powerpacks.osb.emext.calculator_<version>.jar

and see this file on your machine:

com.wily.powerpacks.osb.emext.calculator_8.1.0.jar

This name convention... refers to...

Introscope SPM install prerequisites 29


Introscope SPM install prerequisitesBefore you install Introscope SPM, make sure that you have covered all the points in these checklists.

Installation prerequisite checklists

Introscope SPM hardware and software prerequisites checklist:

Check that for all Java Agent extensions you plan to install, that CA Wily Introscope Agent 8.1.0.0 or later is installed and configured correctly. Also check that the Introscope Agent is communicating with the Enterprise Manager on which you plan to install the Introscope SPM EM extension. See Additional Introscope documentation on page 23.

If you’re installing the .NET Agent extension (ASP.NET), check that you have installed the Introscope .NET Agent version 8.1.0.0 or later.

If you’re installing the .NET Agent extension (WCF), check that you have installed the Introscope .NET Agent version 8.1.0.0 or later.

The Agent and EM extensions are installed by whichever account is used to administer the application servers and Enterprise Manager, respectively.

If you’re installing the Introscope SPM OSB Agent extension, check that you have installed the Introscope SPM Java or .NET Agent extension version 8.1.0.0 or later.

If you’re installing the Introscope SPM WPS or WESB Agent extension, check that you have installed the Introscope SPM Java or .NET Agent extension version 8.1.0.0 or later.

Check that CA Wily Introscope ErrorDetector 8.1 or later is installed and configured correctly.

Using ErrorDetector with Introscope SPM allows you to view detailed web services fault data. If you’re monitoring an OSB or WPS environment using Introscope SPM, ErrorDetector allows you to view detailed OSB components or WPS tier components faults, respectively. For more information about ErrorDetector, see the Introscope ErrorDetector Guide.



Have this information ready:

Identify the machine on which your existing Introscope Enterprise Manager is installed.

» Note If you have a clustered environment, identify the machine where each Collector and the MOM are installed.

Identify these directory locations in your Introscope environment:

Application server home directory—Home directory of your application server.

<Agent_Home> Agent home directory—Installation directory of the Introscope Agent for the application server to be monitored.

<EM_Home>—Installation directory for Introscope on your Enterprise Manager machine.

The directory where the IntroscopeAgent.profile file is located, on each agent where you plan to install Introscope SPM.

» Note The IntroscopeAgent.profile file is typically in the top-level directory of the Agent installation.

Know the components you plan to install on each computer: Introscope SPM Agent extension and Introscope SPM EM extension.

» Note If you’re not sure about how to determine the components you need or where they are to be located, contact CA Wily Technical Support.

Know the proxy host name and proxy server port (only if you have to provide this information to access the CA download site). If your proxy server requires authentication, you must have a valid user name and password for the proxy server.

Machine Name Component Want to install?

Introscope SPM Agent extension

Introscope SPM EM extension

Introscope SPM OSB Agent extension

Introscope SPM OSB EM extension

Introscope SPM WPS/WESB Agent extension

Introscope SPM WPS/WESB EM extension

Summary of Introscope SPM installation steps 31


Summary of Introscope SPM installation steps Installing Introscope SPM includes these high-level steps:

Step 1 Download the Introscope SPM installation archive for your environment. See Downloading and extracting the installation archives on page 32.

Step 2 Extract the Introscope SPM Agent extensions. For a Java environment, see Extracting Windows, Unix, and z/OS Java Agent extensions on page 35.For a .NET environment, see Extracting Introscope SPM EM extensions on page 50.

» Important If you’re upgrading from Web Services Manager 7.2, you must back up the Web Services Manager 7.2 webservices.pbd file to another directory before extracting the Introscope SPM Agent extensions.

Step 3 Configure the Introscope SPM Agent extensions. For both Java and .NET environments, see Extracting and configuring Introscope SPM .NET Agent extensions on page 40.

Step 4 Extract the Introscope SPM EM extensions. See Extracting Introscope SPM EM extensions on page 50.

Step 5 Optional: To monitor an OSB environment, download, extract, and configure the Introscope SPM OSB Agent extensions and EM extension. See Installing and configuring Introscope SPM OSB Agent and EM extensions on page 60.

Step 6 Optional: To monitor a WPS or WESB environment, download, extract, and configure the Introscope SPM WPS/WESB Agent extensions and EM extension. See Installing and configuring Introscope SPM WPS/WESB Agent and EM extensions on page 69.

If you’re upgrading from Web Services Manager 7.2

See Upgrading Web Services Manager to Introscope SPM on page 56.

If you’re installing in an Introscope cluster

If you’re installing Introscope SPM in a clustered environment, extract the EM extensions on both the MOM and the Collectors. However, deploy the Management Module only on the MOM. See Extracting Introscope SPM EM extensions on page 50 for additional information.



Downloading and extracting the installation archives

The Introscope SPM installation archive contains two files: the Introscope SPM Agent extension and EM extension. After you download and extract the installation archive, you’ll extract the Agent extensions, then the EM extensions.

To download and extract the installation archive:

1 If needed, log in with the Operating System Administrator account.

2 Download from the Software Download Site the Introscope SPM installation archive.

a Choose the installation archive appropriate for your environment from this table.

b Download the installation archive to a temp directory.

3 Extract the installation archive into the temp directory.

» Note If you’re extracting in a Unix or z/OS environment, use the appropriate

command in this table.

Operating System Installation Archive File Name

Windows Java IntroscopeSOAPerformanceManagementV<version>windows.zip

Unix (AIX, Linux, Solaris) IntroscopeSOAPerformanceManagementV<version>unix.tar

z/OS IntroscopeSOAPerformanceManagementV<version>zOS.tar

Windows .NET IntroscopeSOAPerformanceManagementV<version>DotNet.zip

Operating System Installation Archive Extract Command

Unix (AIX, Linux, Solaris) tar -xvf IntroscopeSOAPerformanceManagementV<version>unix.tar

z/OS tar -xvfo IntroscopeSOAPerformanceManagementV<version>zOS.tar

Downloading and extracting the installation archives 33


The Introscope SPM installation archive contains Introscope SPM Agent extension and Introscope SPM EM extension files. The files you see depend on your

operating system, as shown in this table:

4 Download from the Software Download Site the Introscope SPM documentation.

Choose the documentation archive appropriate for your environment from this table.

Operating System Files that extract from the installation archive

Description

Windows Java IntroscopeSOAPerformanceManagementV<version>Agent.windows.zip

IntroscopeSOAPerformanceManagement<version>EM.windows.zip

Introscope SPM Java Agent extension

EM extension

Unix (AIX, Linux, Solaris) IntroscopeSOAPerformanceManagementV<version>Agent.unix.tar

IntroscopeSOAPerformanceManagementV<version>EM.unix.tar


EM extension

z/OS IntroscopeSOAPerformanceManagementV<version>Agent.zOS.tar

IntroscopeSOAPerformanceManagementV<version>EM.zOS.tar


EM extension

Windows .NET IntroscopeSOAPerformanceManagementV<version>Agent.windows.zip

IntroscopeSOAPerformanceManagementV<version>Agent.windows.wcf.zip

IntroscopeSOAPerformanceManagementV<version>EM.windows.zip

Introscope SPM Agent extension (ASP.NET) for .NET Agent

Introscope SPM Agent extension (WCF) for .NET Agent

EM extension

Operating System Documentation Archive File Name

Windows Java IntroscopeSOAPerformanceManagementV<version>Docs.windows.zip

Unix (AIX, Linux, Solaris) IntroscopeSOAPerformanceManagementV<version>Docs.unix.tar

z/OS IntroscopeSOAPerformanceManagementV<version>Docs.zOS.tar

Windows .NET IntroscopeSOAPerformanceManagementV<version>Docs.windows.zip



5 Extract the documentation files.

» Note If you’re extracting documentation in a Unix or z/OS environment, use

the appropriate command in this table.

The installation and documentation archives are downloaded and extracted.

About Agent extensionsThe Introscope SPM Agent extension, installed on top of the Introscope Agent, is a software component that sits in-stream of the web service invocations. In operation, each agent listens for web service invocations. Based on your environment, you will install either a Java or .NET Introscope SPM Agent extension. If you’re installing an Introscope SPM Java Agent extension, the specific Agent extension you install is based on your operating system and application server. CA Wily provides Introscope SPM Agent extensions for various SOAP engines on Windows, AIX, Linux, Solaris, and z/OS.

Categories of Agent extensions

You must install and configure an Introscope SPM Agent extension for each distinct Java- and .NET-based SOAP engine hosting web services that you want to monitor. An Introscope SPM Agent extension must be installed on each SOAP engine implementation.

Native SOAP engine agent extensions

SOAP engines typically run in an application server (with the exception of Axis, which often runs in a web server). Native SOAP engine agent extensions are supported for these platforms:

Axis

WebLogic

WebSphere

SAP NetWeaver

.NET

Install Archive Package

Documentation Archive Extract Command

Unix (AIX, Linux, Solaris) tar -xvf IntroscopeSOAPerformanceManagementV<version>Docs.unix.tar

z/OS tar -xvfo IntroscopeSOAPerformanceManagementV<version>Docs.zOS.tar

Extracting Windows, Unix, and z/OS Java Agent extensions 35


Based on your operating system, proceed to the appropriate installation topic.

Extracting Windows, Unix, and z/OS Java Agent extensions

After you extract the Introscope SPM Agent extensions, you’ll perform some configuration tasks.

Prerequisites

You must have installed and configured the appropriate version of CA Wily Introscope Agent. See the Introscope Java Agent Guide.

Extract the Introscope SPM Agent extensions that you want to install and configure on a computer that satisfies all system requirements (see Introscope SPM Agent extension requirements on page 27).

» Tip Before extracting Java Agent extensions, it’s a best practice to copy IntroscopeAgent.profile to a backup directory.

Operating System Go to this topic next

Windows Java Extracting Windows, Unix, and z/OS Java Agent extensions on page 35

Unix (AIX, Linux, Solaris) Extracting Windows, Unix, and z/OS Java Agent extensions on page 35

z/OS Extracting Windows, Unix, and z/OS Java Agent extensions on page 35

Windows .NET Extracting and configuring Introscope SPM .NET Agent extensions on page 40



To extract Introscope SPM Java Agent extensions:

Before extracting Introscope SPM Agent extensions, you must first install and extract the installation archive. See Downloading and extracting the installation archives on page 32.

1 If you’re upgrading from Web Services Manager 7.2, back up the Web Services Manager 7.2 Java agent webservices.pbd file.

Web Services Manager 7.2 Java agent includes a webservices.pbd file. The Introscope SPM Agent extension also contains webservices.pbd file that overrides the Web Services Manager 7.2 Java agent webservices.pbd file during the extraction process.

If you want to uninstall the Introscope SPM Agent extension, you will need to replace the Introscope SPM Agent extension webservices.pbd file with the Web Services Manager 7.2 Java agent webservices.pbd file. For more information, see Uninstalling Introscope SPM .NET Agent extensions on page 47 and Upgrading Web Services Manager to Introscope SPM on page 56.

» Note CA Wily also recommends backing up the Web Services Manager 7.2 <Agent_Home>) directory in case you want to revert back to your Web Services Manager 7.2 application environment.

a Find the Web Services Manager 7.2 Java webservices.pbd file in the <Agent_Home> directory.

b Save in a secure location a copy of the Web Services Manager 7.2 Java webservices.pbd file.

2 Choose from this table the Introscope SPM Agent extension archive appropriate for your environment.

3 In the temp directory into which the installation archive was installed and extracted (see Downloading and extracting the installation archives on page 32), locate the appropriate Introscope SPM Agent extension archive chosen in step 2.

4 Extract the Introscope SPM Agent extension archive to <Agent_Home>, which contains the agent configuration and is typically called wily.

Operating System Introscope SPM Agent Extension Archive

Windows Java IntroscopeSOAPerformanceManagementV<version>Agent.windows.zip


IntroscopeSOAPerformanceManagementV<version>Agent.unix.tar

z/OS IntroscopeSOAPerformanceManagementV<version>Agent.zOS.tar

Extracting Windows, Unix, and z/OS Java Agent extensions 37


If you’re extracting Introscope SPM Agent extensions in a Unix or z/OS

environment, use the appropriate command in this table.

The Introscope SPM Agent extension archive contains these files:

The Introscope SPM Agent Java extension is extracted.

You now need to configure the Introscope SPM Java Agent extension.

Operating System Agent Extension Archive Extract Command

Unix (AIX, Linux, Solaris) tar -xvf IntroscopeSOAPerformanceManagementV<version>Agent.unix.tar

z/OS tar -xvfo IntroscopeSOAPerformanceManagementV<version>Agent.zOS.tar

File Description

webservices.pbd The ProbeBuilder Directives file containing the tracers required to enable your application to collect web services metrics.

WebServicesAgent.jar Extension to the Introscope Agent required by Introscope SPM.

WebServicesAgent.jar automatically extracts to the <Agent_Home>/ext directory.

BoundaryOnlyTrace.jar Extension to the Introscope Agent required by Introscope SPM.

BoundaryOnlyTrace.jar automatically extracts to the <Agent_Home>/ext directory.



Configuring Introscope SPM Java Agent extensionsPerform these steps to configure each Introscope SPM Java Agent extension.

» Note The Java Agent extension configuration instructions in this chapter assume that the Introscope Agent is configured for JVM AutoProbe. See the Introscope Java Agent Guide for details.

Prerequisites

» Note see Installation machine and directory names with documentation conventions on page 27 to understand the variables used in this guide for different installation directories.

Be sure you’ve carried out these prerequisites before you configure the Introscope SPM Java Agent extensions:

While configuring a Introscope SPM Agent extension, the monitored application should not be running. Stop the server before starting the configuration.

For Axis Agent extensions, the machine must have the Axis SOAP engine, version 1.2, 1.3, or 1.4 installed.

For WebLogic Agent extensions, the machine must have version 8.1, 9.x, or 10.0 of the WebLogic Application Server installed.

For WebSphere Agent extensions, the machine must have version 7.0, 6.0, or 6.1 of the WebSphere Application Server (WAS) installed.

For SAP NetWeaver Agent extensions, the machine must have SAP NetWeaver Web AS 6.40 or SAP NetWeaver Web AS 7.0 installed.

To configure Introscope SPM Java Agent extensions:

1 Modify the agent configuration properties.

a Open the IntroscopeAgent.profile file in <Agent_Home>.

b Add the webservices.pbd value to the introscope.autoprobe.directivesFile property in the IntroscopeAgent.profile file.

For exampleintroscope.autoprobe.directivesFile=defaulttypical.pbl,webservices.pbd

2 If required, update the default Introscope SPM Agent extensions properties settings in the IntroscopeAgent.profile file.

For more in-depth descriptions of the IntroscopeAgent.profile, see Introscope SPM Agent extension configuration properties on page 321.

Uninstalling Introscope SPM Java Agent extensions 39


3 Restart the application server into which the Introscope SPM Agent Java extension is installed.

This restarts the Agent and loads the Introscope SPM Agent extension.

4 Verify your deployment by invoking any Java web service and verifying that web service node exists in the Investigator tree.

See Verifying your deployment on page 55. If you do not see .NET web service data, see Troubleshooting the Introscope SPM .NET Agent extension installation on page 45.

» Note You will not see any metrics associated with WebLogic test client transactions. WebLogic uses a type of synthetic transaction to automatically generate web pages to test web services. In this case, test clients that run against services hosted by WebLogic cannot be detected by the Introscope SPM Agent extension.

5 If you want to configure multiple physical agents into a single Virtual Agent, see Configuring virtual agents for Introscope SPM on page 54.

The Introscope SPM Java Agent extension is installed and configured. Now extract the EM extension. See Extracting Introscope SPM EM extensions on page 50.

Uninstalling Introscope SPM Java Agent extensionsTo uninstall Introscope SPM Java Agent extensions:

1 Stop the application server.

2 Unmodify the agent configuration properties.


b Remove the webservices.pbd value from introscope.autoprobe.directivesFile property.

3 Delete the WebServicesAgent.jar file from the <Agent_Home>/ext directory

4 Delete the BoundaryOnlyTrace.jar file from the <Agent_Home>/ext directory.

5 Delete webservices.pbd from the <Agent_Home> directory.

6 Start the application server.

The Introscope SPM Java Agent extension is uninstalled.



Extracting and configuring Introscope SPM .NET Agent extensions

Installing the Introscope SPM .NET Agent extensions includes these high-level steps:

Step 1 Download the Introscope SPM agent installation archive for your environment. See Downloading and extracting the installation archives on page 32.

Step 2 Extract and configure the Introscope SPM .NET Agent extension. See Extracting and configuring Introscope SPM .NET Agent extensions on page 40.

Step 3 If you want to make use of Windows Communication Foundation (WCF), extract and configure the Introscope SPM .NET Agent extension. For instructions, see Wily Knowledge Base (KB) article 2123, Installing and configuring Introscope SOA Performance Management 8.1 .NET Agent extensions for WCF.

The Introscope SPM .NET installation archive contains three files:

After you download and extract the installation archive and the Introscope SPM .NET Agent extensions, you’ll perform some configuration tasks.

Prerequisites

You must have an installed and configured the Introscope .NET Agent version 8.1or later. See the Introscope .NET Agent Guide.

File Description

IntroscopeSOAPerformanceManagementV<version>Agent.windowsDotNet.zip

Introscope SPM Agent extension (ASP.NET) for .NET Agent

IntroscopeSOAPerformanceManagementV<version>Agent.windows.wcf.zip

Introscope SPM Agent extension (WCF) for .NET Agent If you want to make use of Windows

Communication Foundation (WCF), after you install and configure the Introscope SPM .NET Agent extension, see Wily Knowledge Base (KB) article 2123 Installing and configuring Introscope SOA Performance Management 8.1 .NET Agent extensions for WCF.

IntroscopeSOAPerformanceManagementV<version>EM.windows.zip

EM extension

https://support.wilytech.com/cgi-bin/wilytech.cfg/php/enduser/std_adp.php?p_faqid=2123




Extracting and configuring Introscope SPM .NET Agent extensions 41


» Important Anytime you install a new or upgraded (later than 8.1.0.0) version of the Introscope .NET Agent, you must make some configuration changes. See Reconfiguring after installing or upgrading the Introscope .NET Agent version on page 318.

If you want to monitor .NET cross-process transactions, you must have configured the .NET Agent for cross-process tracing. The configuration is available in the Sample.exe.config file in the <Agent_Home> directory. For more information, see the Introscope .NET Agent Guide.

To extract the Introscope SPM .NET Agent extension (ASP.NET):


2 If you’re upgrading from Web Services Manager 7.2, back up the Web Services Manager 7.2 .NET agent webservices.pbd file.

The Web Services Manager 7.2 .NET agent includes a webservices.pbd file. The Introscope SPM Agent extension also contains webservices.pbd file that overrides the Web Services Manager 7.2 NET agent webservices.pbd file during the extraction process.

If you want to uninstall the Introscope SPM NET Agent extension, you will need to replace the Introscope SPM NET Agent extension webservices.pbd file with the Web Services Manager 7.2 NET agent webservices.pbd file. For more information, see Uninstalling Introscope SPM .NET Agent extensions on page 47 and Upgrading Web Services Manager to Introscope SPM on page 56.

» Note CA Wily also recommends backing up the Web Services Manager 7.2 <Agent_Home> directory in case you want to revert back to your Web Services Manager 7.2 application environment.

a Find the Introscope .NET agent webservices.pbd file in the <Agent_Home> directory.

b Save in a secure location a copy of the Introscope .NET agent webservices.pbd file.

3 Download the Introscope SPM installation archive file IntroscopeSOAPerformanceManagementV<version>DotNet.zip from the Software Download Site.

4 Use WinZip to extract all files in the IntroscopeSOAPerformanceManagementV<version>Agent.windowsDotNet.

zip installation archive file to <Agent_Home>, which contains the agent configuration and is typically called wily.



The installation archive contains these files:

The Introscope SPM .NET Agent extension is extracted.

Configuring Introscope SPM .NET Agent extensions

You must configure the Introscope SPM .NET Agent extension before you verify that you can see .NET web services transactions in Introscope. Configuring the Introscope SPM .NET Agent extension requires several procedures:

Step 1 Modifying the IntroscopeAgent.profile file. See To modify the Introscope SPM .NET Agent configuration properties:, below.

Step 2 Registering the WebServices.Observer.dll file. See To register the WebServices.Observer.dll file: on page 43.

Step 3 Modifying .NET Framework configuration files. See To modify the .NET Framework configuration: on page 44.

Step 4 Restarting the application server and verifying your deployment. See To restart the application server and verify your deployment: on page 45.

File Description

webservices.pbd The ProbeBuilder Directives file containing the tracers required to enable your application to collect web services metrics.

During the extraction process, the webservices.pbd file is copied to the <Agent_Home> directory.

wily.WebServicesAgent.ext.dll Contains the Introscope SPM agent extension classes.

During the extraction process, the wily.WebServicesAgent.ext.dll file is copied to the <Agent_Home>\ext directory.

WebServices.Observer.dll Contains the classes related to identifying web services.

During the extraction process, the WebServices.Observer.dll file is copied to the <Agent_Home>\bin directory.

wilyHttpCorrelationTracers.ext.dll Contains classes required by Introscope SPM.

During the extraction process, the wilyHttpCorrelationTracers.ext.dll file is copied to the <Agent_Home>\ext directory.

wilyBoundaryOnlyTrace.ext.dll Contains classes required by Introscope SPM.

During the extraction process, the wilyBoundaryOnlyTrace.ext.dll file is copied to the <Agent_Home>\ext directory.



To modify the Introscope SPM .NET Agent configuration properties:

1 Modify the Introscope SPM agent configuration properties.


b Open the IntroscopeAgent.profile file in <Agent_Home>.

c Add the webservices.pbd value to the introscope.autoprobe.directivesFile property in the IntroscopeAgent.profile file.

For exampleintroscope.autoprobe.directivesFile=defaulttypical.pbl,webservices.pbd

2 If required, update the default Introscope SPM Agent extensions properties settings in the IntroscopeAgent.profile file. For more in-depth descriptions of the in IntroscopeAgent.profile, see Introscope SPM Agent extension configuration properties on page 321.

To register the WebServices.Observer.dll file:

Use the wilyregtool to register the WebServices.Observer.dll file.

» Note The wilyregtool can be used to register the Wily Web Services Agent assembly, WebServices.Observer.dll, to the Global Assembly Cache (GAC). It can also be used to unregister the assembly from the GAC.

1 Open a command prompt.

2 Go to the (Parent Directory of <Agent_Home>)\UninstallerData\dotnet.

This is typically where the wilyregtool is located, and the full path typically looks like this:

C:\Program Files\CA

Wily\Introscope<version>\UninstallerData\dotnet

For example,

C:\Program Files\CA

Wily\Introscope8.1.0.0\UninstallerData\dotnet

3 Use this wilyregtool command to register the WebServices.Observer.dll.

wilyregtool “C:\Program Files\CA Wily\Introscope<version>\wily\bin\WebServices.Observer.dll”

For example,

wilyregtool “C:\Program Files\CA Wily\Introscope8.1.0.0\wily\bin\WebServices.Observer.dll”



To modify the .NET Framework configuration:

To configure the .NET Framework for Introscope SPM, you must modify the .NET Framework configuration. For more information about .NET Framework configuration, see http://msdn.microsoft.com/en-us/library/1xtk877y(VS.71).aspx.

1 Locate the machine.config file, which is typically located in the C:\WINDOWS\Microsoft.NET\Framework\vx.x\CONFIG directory, where vx.x is the .NET version.

For example, the directory for .NET 1.1 might be v1.1.4322 and the directory for .NET 2.0 might be v2.0.50727.

2 Make a backup of the machine.config file and store the backup file in a secure location.

3 Add code to the machine.config file.

» Note If you want to monitor .NET cross-process transactions, you need to have configured the .NET Agent. See Prerequisites on page 38.

a Open the machine.config file and search for <webServices>.

You should find <webServices> under <system.web>. If you do not, type <webServices> under <system.web>. It should look like this:

<system.web>

<webServices>b Search for <soapExtensionTypes>.

You should find <soapExtensionTypes> under <webServices>. If you do not, type <soapExtensionTypes> under <webServices>. It should look like this:

<webServices>

<soapExtensionTypes>

c Add this code below <soapExtensionTypes>.

<add type="com.wily.powerpack.webservices.extension.ObserverSoapExtension, WebServices.Observer, Version=<version>, Culture=neutral, PublicKeyToken=99330fac7173009e" group="0" priority="3" />

</soapExtensionTypes></webServices>

For example,

<add type="com.wily.powerpack.webservices.extension.ObserverSoapExtension, WebServices.Observer, Version=8.1.0.0, Culture=neutral, PublicKeyToken=99330fac7173009e" group="0" priority="3" />


http://msdn.microsoft.com/en-us/library/1xtk877y(VS.71).aspx

http://msdn.microsoft.com/en-us/library/1xtk877y(VS.71).aspx



When you are done, the machine.config file looks like this:

<webServices><soapExtensionTypes>



d Save the machine.config file.

To restart the application server and verify your deployment:

1 Restart the IIS application server, which restarts the agent and loads the Introscope SPM .NET Agent extension.

2 Verify your deployment by invoking any .NET web service and verifying that web service node exists in the Investigator tree.

See Verifying your deployment on page 55. If you do not see .NET web service data, see Troubleshooting the Introscope SPM .NET Agent extension installation, below.

The Introscope SPM .NET Agent extension is installed and configured. Now extract the EM extension. See Extracting Introscope SPM EM extensions on page 50.

Troubleshooting the Introscope SPM .NET Agent extension installation

Check the items below if you’re not able to see .NET Agent web services data or related Transaction Traces in Investigator.

1 Check that all the files are in the correct directories as shown in the table below.

If one or more files is not in the correct directory, re-extract the Introscope SPM .NET Agent extension IntroscopeSOAPerformanceManagementV<version>DotNet.zip archive file into a temp directory and copy any missing files to the required directory.

File Name Directory Location

WebServices.Observer.dll <Agent_Home>\bin

wily.WebServicesAgent.ext.dll <Agent_Home>\ext

webservices.pbd <Agent_Home>

wilyHttpCorrelationTracers.ext.dll <Agent_Home>\ext

wilyBoundaryOnlyTrace.ext.dll <Agent_Home>\ext



2 Verify that the WebServices.Observer.dll file is in the Global Assembly Cache (GAC).

If the WebServices.Observer.dll file is not in the GAC, use the wilyregtool to register the WebServices.Observer.dll file. See Use the wilyregtool to register the WebServices.Observer.dll file. on page 43.

3 Verify that there is an entry for webservices.pbd in the <Agent_Home>\default-full.pbl file.

If there is no entry for webservices.pbd in the <Agent_Home>\default-full.pbl file, modify <Agent_Home>/default-full.pbl to add a reference to webservices.pbd.

4 Verify that the code below is present in the machine.config file.

» Note The machine.config file is typically located in the C:\WINDOWS\Microsoft.NET\Framework\vx.x\CONFIG directory, where vx.x is the .NET version. For example, the directory for .NET 1.1 might be v1.1.4322 and the directory for .NET 2.0 might be v2.0.50727.

» Note If your system is running ASP.NET 1.1 web services or the ASP.NET 1.1 client, check the ASP.NET 1.1 machine.config file. Similarly, if your system is running .NET 2.0, check the .NET 2.0 machine.config file.


<add type="com.wily.powerpack.webservices.extension.ObserverSoapExtension, WebServices.Observer, Version=<version>, Culture=neutral, PublicKeyToken=99330fac7173009e" group="0" priority="3" />


For example,




If the code above is not in the machine.config file, add the code. See Add code to the machine.config file. on page 44.

» Note If you want to monitor .NET cross-process transactions, you must have configured the .NET Agent for cross-process tracing. The configuration is available in the Sample.exe.config file in the <Agent_Home> directory. For more information, see the Introscope .NET Agent Guide.

Uninstalling Introscope SPM .NET Agent extensions 47


5 If you upgraded to a version later than 8.1.0.0 of the Introscope .NET Agent, you must make some configuration changes. See Reconfiguring after installing or upgrading the Introscope .NET Agent version on page 318.

6 Invoke any .NET web service and verify that web service node in the Investigator tree.

Uninstalling Introscope SPM .NET Agent extensionsTo uninstall the Introscope SPM .NET Agent extension:

1 Stop the IIS application server.

2 Remove code from the machine.config file.

a Locate and open the machine.config file.

» Note The machine.config file is typically located in the C:\WINDOWS\Microsoft.NET\Framework\vx.x\CONFIG directory, where vx.x is the .NET version. For example, the directory for .NET 1.1 might be v1.1.4322 and the directory for .NET 2.0 might be v2.0.50727.

b Search for <soapExtensionTypes>.

c Delete this code below <soapExtensionTypes>.

<add type="com.wily.powerpack.webservices.extension.ObserverSoapExtension, WebServices.Observer, Version=<version>, Culture=neutral,

PublicKeyToken=99330fac7173009e" group="0" priority="3" />

For example,

<add type="com.wily.powerpack.webservices.extension.ObserverSoapExtension, WebServices.Observer, Version=8.1.0.0, Culture=neutral,

PublicKeyToken=99330fac7173009e" group="0" priority="3" />

When you are done, it looks like this:

<webServices><soapExtensionTypes></soapExtensionTypes>

</webServices>

3 Use the wilyregtool to unregister the WebServices.Observer.dll file.

a Open a command prompt.

b Go to the (Parent Directory of <Agent_Home>)\UninstallerData\dotnet.

This is typically where the wilyregtool is located, and the full path typically looks like this:

C:\Program Files\CA

Wily\Introscope<version>\UninstallerData\dotnet

For example,



C:\Program Files\CA

Wily\Introscope8.1.0.0\UninstallerData\dotnet

c Use this wilyregtool command to unregister the WebServices.Observer.dll.

» Note In this command, use only two digits of the Introscope version.

wilyregtool -u “C:\Program Files\CA

Wily\Introscope<version>\wily\bin\WebServices.Observer.dll”

For example,

wilyregtool -u “C:\Program Files\CA Wily\Introscope8.1\wily\bin\WebServices.Observer.dll”

4 Delete the files listed in the table below.

5 Replace the Introscope .NET agent webservices.pbd file.

a Find the Introscope .NET agent webservices.pbd file copied and backed up during the .NET Agent extension installation. See If you’re upgrading from Web Services Manager 7.2, back up the Web Services Manager 7.2 .NET agent webservices.pbd file. on page 41.

b Copy the Introscope .NET agent webservices.pbd file to the <Agent_Home> directory.

6 If you upgraded the Introscope Agent version and configured the .NET Agent extension, remove changes to the aspnet.config file.

a Find the aspnet.config application server configuration file used by the IIS application server.

In Windows, choose Start > Run to open the Run dialog box.

In the Run dialog box Open field, type Microsoft.NET, then press OK.

Go to the Framework\vx.x.xxxx directory, where vx.x.xxxx is the .NET version.


b Search for the aspnet.config file.

File Name Delete from this Directory

WebServices.Observer.dll <Agent_Home>\bin

wily.WebServicesAgent.ext.dll <Agent_Home>\ext

webservices.pbd <Agent_Home>

wilyHttpCorrelationTracers.ext.dll <Agent_Home>\ext

wilyBoundaryOnlyTrace.ext.dll <Agent_Home>\ext

Uninstalling Introscope SPM .NET Agent extensions 49


c Modify the .NET Agent configuration in the aspnet.config file by removing the lines shown in bold below, where <upgradedAgentVersion> is the current Introscope .NET Agent version that you are using:

<dependentAssembly><assemblyIdentity name="wily.Agent"

publicKeyToken="2B41FDFB6CD662A5" /><bindingRedirect oldVersion="8.1.0.0"

newVersion="<upgradedAgentVersion>" /><codeBase version="<upgradedAgentVersion>" href="file:///

C:\\Program Files\\CA Wily\\Introscope8.1.0.0\\wily\\bin\\wily.Agent.dll"/>

</dependentAssembly>

7 Start the IIS application server.

The Introscope SPM .NET Agent extension is uninstalled.



Extracting Introscope SPM EM extensionsWhen you extract the Introscope SPM EM extensions, you are installing the Introscope SPM management module. This provides the Introscope dashboards specific to Introscope SPM.

» Important If you’re installing Introscope SPM in a clustered environment, extract the EM extensions on both the MOM and the Collectors. However, deploy the Management Module only on the MOM.

To extract Introscope SPM EM extensions:

1 Stop the Enterprise Manager on which you will install the Introscope SPM EM extension.

2 Choose from this table the Introscope SPM EM extension archive appropriate for your environment.

3 In the temp directory into which the installation archive was installed and extracted (see Downloading and extracting the installation archives on page 32), locate the appropriate Introscope SPM EM extension archive chosen in step 2.

4 Extract all files in the Introscope SPM EM extension archive file to the <EM_Home> directory.

» Note If you’re extracting Introscope SPM EM extensions in a Unix or z/OS

environment, use the appropriate command in this table.

Operating System EM Extension Archive

Windows Java IntroscopeSOAPerformanceManagementV<version>EM.windows.zip


IntroscopeSOAPerformanceManagementV<version>EM.unix.tar

z/OS IntroscopeSOAPerformanceManagementV<version>EM.zOS.tar

Windows .NET IntroscopeSOAPerformanceManagementV<version>EM.windows.zip

Operating System EM Extension Extract Command

Unix (AIX, Linux, Solaris) tar -xvf IntroscopeSOAPerformanceManagementV<version>EM.unix.tar

z/OS tar -xvfo IntroscopeSOAPerformanceManagementV<version>EM.zOS.tar

Extracting Introscope SPM EM extensions 51


The Introscope SPM EM extension archive contains these files:

File Description

SPM_ManagementModule.jar Introscope SPM management module for viewing web services data in the Introscope Investigator. Contains pre-configured dashboards and alerts for viewing web services metrics.

SPM_ManagementModule.jar automatically extracts to the <EM_Home>/deploy directory. When the Enterprise Manager is started, SPM_ManagementModule.jar is automatically moved to the <EM_Home>/config/modules directory.

ws.overview.tv.xml Extension to the Introscope Workstation. Enables the Workstation to request web services data from the Enterprise Manager. Provides the Introscope SPM Overview tab in Introscope Investigator.

ws.overview.tv.xml automatically extracts to the <EM_Home>/ext/xmltv directory.

ws.wsdependency.tv.xml Extension to the Introscope Workstation. Enables the Workstation to request web services data from the Enterprise Manager. Provides the Introscope SPM Dependencies tab in Introscope Investigator.

ws.wsdependency.tv.xml automatically extracts to the <EM_Home>/ext/xmltv directory.

ws.wsdeviation.tv.xml Extension to the Introscope Workstation. Enables the Workstation to request web services data from the Enterprise Manager. Provides the Introscope SPM Deviations tab in Introscope Investigator.

ws.wsdeviation.tv.xml automatically extracts to the <EM_Home>/ext/xmltv directory.

com.wily.introscope.soa.tracefilters.common_<version>.jar

Supports Introscope SPM Transaction Tracing capabilities.

com.wily.introscope.soa.tracefilters.common_<version>.jar automatically extracts to two locations:

<EM_Home>/product/enterprisemanager/plugins directory

<EM_Home>/ws-plugins directory

com.wily.introscope.soa.tracefilters.em_<version>.jar


com.wily.introscope.soa.tracefilters.em_<version>.jar automatically extracts to the <EM_Home>/product/enterprisemanager/plugins directory.



5 You now need to configure the Introscope SPM EM extension. See Configuring Introscope SPM EM extensions on page 53 for details.

The Introscope SPM EM extension is extracted.

com.wily.introscope.soa.dependencymap.common_<version>.jar

Supports Introscope SPM SOA Dependency Map capabilities.

com.wily.introscope.soa.dependencymap.common_<version>.jar automatically extracts to two locations:

<EM_Home>/product/enterprisemanager/plugins directory.

<EM_Home>/ws-plugins directory

com.wily.introscope.soa.dependencymap_<version>.jar


com.wily.introscope.soa.dependencymap_<version>.jar automatically extracts to the <EM_Home>/product/enterprisemanager/plugins directory.

com.wily.introscope.soa.deviationmetrics_<version>.jar

Supports Introscope SPM deviation metrics capabilities.

com.wily.introscope.soa.deviationmetrics_<version>.jar automatically extracts to the <EM_Home>/product/enterprisemanager/plugins directory.

com.wily.introscope.soa.dependencymap.ui_<version>.jar


com.wily.introscope.soa.dependencymap.ui_<version>.jar automatically extracts to the <EM_Home>/ws-plugins directory.

com.wily.introscope.soa.dependencymetrics.typeviewer_<version>.jar

Supports Introscope SPM dependency metrics capabilities for displaying in the SOA Performance - Most Critical Operations and SOA Performance - Most Dependent Operations dashboards as well as in the Most Critical and Most Dependent tabs.

com.wily.introscope.soa.dependencymetrics.typeviewer_<version>.jar automatically extracts to the <EM_Home>/ws-plugins directory.

com.wily.introscope.soa.tracefilters.workstation_<version>.jar


com.wily.introscope.soa.tracefilters.workstation_<version>.jar automatically extracts to the <EM_Home>/ws-plugins directory.

com.wily.introscope.ui.tomsawyer_<version>.jar

Supports Introscope SPM UI capabilities.

com.wily.introscope.ui.tomsawyer_<version>.jar automatically extracts to the <EM_Home>/ws-plugins directory.

File Description

Configuring Introscope SPM EM extensions 53


Configuring Introscope SPM EM extensionsPerform these steps to configure each Introscope SPM EM extension in either a Java or .NET environment.

1 If needed, modify the IntroscopeEnterpriseManager.properties file.

a Open the IntroscopeEnterpriseManager.properties file in the <EM_Home>/config directory.

b Configure any Introscope SPM EM extension properties as appropriate.

For descriptions of the Introscope SPM EM extension properties, see Introscope SPM EM extension configuration on page 326.

2 Save and close the IntroscopeEnterpriseManager.properties file.

3 Start the Enterprise Manager.

4 Verify your installation. See Verifying your deployment on page 55.

The Introscope SPM EM extension is installed.

Uninstalling Introscope SPM EM extensions» Note If you installed and configured the Introscope SPM EM extension in a

clustered environment, uninstall the EM extensions on both the MOM and the Collectors, and undeploy the Management Module on the MOM.

To uninstall the Introscope SPM EM extension:

1 Stop the Enterprise Manager.

2 Delete <EM_Home>/config/modules/SPM_ManagementModule.jar.

3 Delete <EM_Home>/ext/xmltv/ws.overview.tv.xml.

4 Delete <EM_Home>/ext/xmltv/ws.wsdependency.tv.xml.

5 Delete <EM_Home>/ext/xmltv/ws.wsdeviation.tv.xml.

6 Delete <EM_Home>/product/enterprisemanager/plugins/com.wily.introscope.soa.tracefilters.common_<version>.jar.

7 Delete <EM_Home>/product/enterprisemanager/plugins/

com.wily.introscope.soa.tracefilters.em_<version>.jar.

8 Delete <EM_Home>/product/enterprisemanager/plugins/com.wily.introscope.soa.dependencymap.common_<version>.jar.

9 Delete <EM_Home>/product/enterprisemanager/plugins/com.wily.introscope.soa.dependencymap_<version>.jar.

10 Delete <EM_Home>/product/enterprisemanager/plugins/com.wily.introscope.soa.deviationmetrics_<version>.jar.



11 Delete <EM_Home>/ws-plugins/com.wily.introscope.soa.tracefilters.common_<version>.jar.

12 Delete <EM_Home>/ws-plugins/com.wily.introscope.soa.dependencymap.common_<version>.jar.

13 Delete <EM_Home>/ws-plugins/com.wily.introscope.soa.dependencymap.ui_<version>.jar.

14 Delete <EM_Home>/ws-plugins/com.wily.introscope.soa.dependencymetrics.typeviewer_<version>.j

ar

15 Delete <EM_Home>/ws-plugins/com.wily.introscope.soa.tracefilters.workstation_<version>.jar.

16 Delete <EM_Home>/ws-plugins/com.wily.introscope.ui.tomsawyer_<version>.jar.


The Introscope SPM EM extension is uninstalled.

Configuring virtual agents for Introscope SPMYou can configure multiple physical agents into a single Virtual Agent. A Virtual Agent enables an aggregated, logical view of the metrics reported by multiple agents.

You define virtual agents in the agentclusters.xml file, which is located in the <IntroscopeHome>/config directory of the Enterprise Manager to which the Agents report. See the Introscope Java Agent Guide for more information about virtual agents and performing this configuration.

The example below shows agentclusters.xml modified to define a Virtual Agent named WebServicesVirtualAgent in the Introscope SuperDomain. Note that in this example, the Virtual Agent is configured to collect and aggregate only server metrics, and not any client metrics, across all the agents that are not custom.

<agent-cluster name="WebServicesVirtualAgent" domain="SuperDomain" >

<agent-specifier>(.*)\|[^Custom.*](.*)\|(.*)</agent-specifier><metric-specifier>WebServices\|Server\|(.*):Average Response Time

$ms$</metric-specifier><metric-specifier>WebServices\|Server\|(.*):Concurrent Invocations</

metric-specifier><metric-specifier>WebServices\|Server\|(.*):Errors Per Interval</metric-

specifier><metric-specifier>WebServices\|Server\|(.*):Responses Per Interval</

metric-specifier>

Verifying your deployment 55


<metric-specifier>WebServices\|Server\|(.*):Stall Count</metric-specifier>

<metric-specifier>WebServices\|Server\|(.*):SOAP Faults Per Interval</metric-specifier>

<metric-specifier>WebServices\|Server\|(.*)\|(.*):Average Response Time $ms$</metric-specifier>

<metric-specifier>WebServices\|Server\|(.*)\|(.*):Concurrent Invocations</metric-specifier>

<metric-specifier>WebServices\|Server\|(.*)\|(.*):Errors Per Interval</metric-specifier>

<metric-specifier>WebServices\|Server\|(.*)\|(.*):Responses Per Interval</metric-specifier>

<metric-specifier>WebServices\|Server\|(.*)\|(.*):Stall Count</metric-specifier>

<metric-specifier>WebServices\|Server\|(.*)\|(.*):SOAP Faults Per Interval</metric-specifier>

</agent-cluster>

See To view web service metrics aggregated across all agents: on page 135 for a figure showing the resulting WebServicesVirtualAgent node and metrics displayed in Introscope Investigator.

Verifying your deploymentTo verify that your Introscope SPM Agent and EM extension implementations are successful:

1 Execute one or more SOAP invocations against any of the monitored services.

2 Verify that you can see these in Investigator:

a The WebServices > Client node under an agent into which a Introscope SPM Agent extension was installed.

b The WebServices > Server node under an Agent into which a Introscope SPM Agent extension was installed.

» Note If you’re not able to see .NET Agent web services data or related Transaction Traces in Investigator, see Troubleshooting the Introscope SPM .NET Agent extension installation on page 45.

» Note You will not see any metrics associated with WebLogic test client transactions. WebLogic uses a type of synthetic transaction to automatically generate web pages to test web services. In this case, test clients that run against services hosted by WebLogic cannot be detected by the Introscope SPM Agent extension.

c Click an agent node, and then click the Overview tab.

This verifies that the Enterprise Manager ws.overview.tv.xml fileloaded properly.



3 In the Workstation Management Module Editor, verify the SOA Performance Management <version> node.

a Choose Workstation > New Management Module Editor.

b Under the SuperDomain, see the SOA Performance Management <version> node.

This verifies that the SPM_ManagementModule.jar file loaded properly.

4 If the agent is installed and configured properly, then you can see a message in the Introscope Agent log file stating the Introscope SPMversion that started.

For example, Started SPM Release <version> (Build xxxxxx) where xxxxxx is the build number.

Or you can check for nodes under Custom Metric Agent (Virtual). The node names are derived from the Web Service namespace. For help seeing the Client or Server nodes, see SOA Performance Management tabs on page 105.

Agent and EM extension debugging optionsAgent and EM extensions log diagnostic information to Introscope Agent or Enterprise Manager logs, respectively, as appropriate. For information about configuring Java Agent logging, see the Introscope Java Agent Guide. For information about configuring .NET Agent logging, see the Introscope .NET Agent Guide. For information about configuring Enterprise Manager logging, see the Introscope Configuration and Administration Guide.

Upgrading Web Services Manager to Introscope SPMUpgrading from Web Services Manager version 7.2 to Introscope SPM 8.1 is done using the Introscope SPM 8.1 installation archive that contains two files: the Introscope SPM Agent extension and the EM extension. After you download and extract the installation archives, you'll perform some configuration steps.

Prerequisites

You must have backed up the Web Services Manager 7.2 webservices.pbd file. CA Wily also recommends backing up the Web Services Manager 7.2 <Agent_Home> directory.

You must have upgraded your system and Introscope components including Introscope Agents and Enterprise Manager to meet the minimum version requirements for Introscope SPM 8.1. See Hardware and software requirements on page 26 and the Introscope Installation and Upgrade Guide.

You must have upgraded ErrorDetector to version 8.1 or later. See Hardware and software requirements on page 26.

Upgrading Web Services Manager to Introscope SPM 57


To upgrade from Web Services Manager 7.2 to Introscope SPM 8.1:

1 Upgrade the EM extension.

Upgrading the EM extension upgrades the Web Services Manager management module to the Introscope SPM 8.1 module, which provides the Introscope SPM 8.1 dashboards, nodes, and tabs.

» Note When the Enterprise Manager is started, the SPM_ManagementModule.jar is automatically moved from the <EM_Home>/deploy directory to the <EM_Home>/config/modules directory.

a Log in to the Introscope Workstation and open the Introscope SPM 8.1 management module.

b Examine the Introscope SPM 8.1 management module, and manually transfer anything appropriate from your Web Services Manager 7.2 management module to the Introscope SPM 8.1 management module.

* If you have any customizations in the Web Services Manager 7.2 management module, manually copy them to or make the appropriate changes in the Introscope SPM 8.1 management module.

* If you have any custom management modules with references to Web Services Manager 7.2 management module elements, delete the references or change the references to refer to Introscope SPM 8.1 management module elements.

c Once you have transferred everything you want from the Web Services Manager 7.2 management modules to the Introscope SPM 8.1 management module, undeploy the Web Services Manager 7.2 management module.

* Stop the Enterprise Manager.* Delete the Web Services Manager 7.2 WebServicesManagementModule.jar file from the <EM_Home>/config/modules directory.* Restart the Enterprise Manager.

2 (Optional) Configure webservices.pbd to retain the Web Services Manager 7.0 or 7.0.1 Investigator tree web service node naming convention.

In the Web Services Manager 7.2 Investigator tree, web service nodes are named using the web service namespace. For example:

http_//ClearingHouse.demobank.ca.com

In the Web Services Manager 7.0 and 7.0.1 Investigator tree, web service nodes are named using the web service endpoint. For example:



http_localhost_8383_demobank_services_ClearingHouseService

Follow these steps if you want to retain the Web Services Manager 7.0 or 7.0.1 node name style in your Investigator tree.

a Open the webservices.pbd file in the <Agent_Home> directory.

b Search for and replace all instances of {namespace} with {servicename}.

c Save the webservices.pbd file.

d Open the IntroscopeAgent.profile file in the <Agent_Home> directory.

e Add the com.wily.introscope.agent.soa.metricNameFormatting property.

f Set the com.wily.introscope.agent.soa.metricNameFormatting property to /:.

For examplecom.wily.introscope.agent.soa.metricNameFormatting=/:

g Save the IntroscopeAgent.profile file.

h Restart the application server of the monitored application.

Introscope SPM metric names display in the Investigator tree and SOA Dependency Map using service name rather than namespace.

3 (Optional) Configure the ws.overview.tv.xml file to change the Namespaces label in the Introscope SPM 8.1 Client and Server node Overview tab Viewer pane. For information about the Client and Server Overview tabs, see Using the Overview tabs on page 105. To see a figure showing the Namespaces label, see step 3 on page 107.

a Complete step 2 on page 57.

b Open the ws.overview.tv.xml file in the <EM_Home>/ext/xmltv/ directory.

c Search for and replace all instances of Namespaces with Services.

d Save the ws.overview.tv.xml file.

e Restart the Enterprise Manager.

The Services label displays in the Introscope SPM 8.1 Client and Server node Overview tab Viewer pane.

4 Verify your deployment. See Verifying your deployment on page 55.

The Introscope SPM upgrade is completed.

Uninstalling Introscope SPM 59


Uninstalling Introscope SPMFollow these steps to uninstall Introscope SPM by uninstalling the Introscope SPM Agent extensions and EM extension.

To uninstall Introscope SPM:

1 Uninstall all the Introscope SPM Agent extensions that have been installed and configured.

2 Uninstall the Introscope SPM EM extension. See Uninstalling Introscope SPM EM

extensions on page 53.

» Note If you installed and configured the Introscope SPM EM extension in a clustered environment, uninstall the EM extensions on both the MOM and the Collectors, and undeploy the Management Module on the MOM.

Introscope SPM is uninstalled.

To uninstall this Agent extension

See these instructions

Axis Configuring Introscope SPM Java Agent extensions on page 38

WebLogic Configuring Introscope SPM Java Agent extensions on page 38

WebSphere Configuring Introscope SPM Java Agent extensions on page 38

SAP Configuring Introscope SPM Java Agent extensions on page 38

.NET Configuring Introscope SPM .NET Agent extensions on page 42



Installing and configuring Introscope SPM OSB Agent and EM extensions

This topic describes how you can extract, install, and configure the Introscope SPM OSB Agent and EM extensions needed for Introscope SPM to monitor your OSB environment.

Before you begin the installation process, ensure that you have met the required prerequisites.

Introscope SPM OSB extensions install prerequisites checklist:

Check that for all Java Agent extensions you plan to install, that CA Wily Introscope Agent 8.1.0.0 or later is installed and configured correctly for ALSB 2.6 or OSB 3.0.

Check that the Introscope Agent is communicating with the Enterprise Manager on which you plan to install the Introscope SPM OSB EM extension

Check that your environment meets the requirements stated in Hardware and software requirements on page 26.

» WARNING Do not install the OSB.pbd and OSBAgent.jar files into a WebLogic 8.1 agent. OSB does not support WebLogic 8.1. If you’re using the same Introscope agent to monitor multiple WebLogic agents any of which are version 8.1, your WebLogic 8.1 instance may experience severe problems.

Downloading and extracting the Introscope SPM OSB installation archive

The Introscope SPM OSB installation archive contains two files: the Introscope SPM OSB Agent extension and the EM extension. After you download and extract the installation archive, you’ll download and extract the documentation archive. Then you’ll extract the Agent extensions, then the EM extensions.

To download and extract the installation archives:


2 Download from the Software Download Site the Introscope SPM OSB installation archive.






» Note If you’re extracting in a Unix environment, use the appropriate command

in this table.

The Introscope SPM OSB installation archive contains Agent extension and EM extension files. The files you see depend on your operating system, as shown in

this table:

The installation archives are downloaded and extracted.

4 Download from the Software Download Site the Introscope SPM OSB documentation.

OS Installation Archive File Name

Windows IntroscopeSOAExtensionforOracleServiceBusV<version>windows.zip


IntroscopeSOAExtensionforOracleServiceBusV<version>unix.tar

OS Installation Archive Extract Command


tar -xvf IntroscopeSOAExtensionforOracleServiceBusV<version>unix.tar

OS Files that extract from the installation archive Description

Windows IntroscopeSOAExtensionforOracleServiceBusV<version>Agent.windows.zip

IntroscopeSOAExtensionforOracleServiceBusV<version>EM.windows.zip

Introscope SPM OSB Java Agent extension

EM extension


IntroscopeSOAExtensionforOracleServiceBusV<version>Agent.unix.tar

IntroscopeSOAExtensionforOracleServiceBusV<version>EM.unix.tar

Introscope SPM OSB Unix Agent extension

EM extension




5 Extract the documentation file.

» Note If you’re extracting documentation in a Unix environment, use the

appropriate command in this table.

The Introscope SPM OSB documentation archive contains a ReadMe file, as shown

in this table:


Now you will extract and configure the Introscope SPM OSB Agent extensions.


Windows IntroscopeSOAExtensionforOracleServiceBusV<version>Docs.windows.zip

Unix (AIX, Linux, Solaris) IntroscopeSOAExtensionforOracleServiceBusV<version>Docs.unix.tar




tar -xvf IntroscopeSOAExtensionforOracleServiceBusV<version>Docs.unix.tar

OS Files that extract from the documentation archive Description

Windows IntroscopeSOAExtensionforOracleServiceBusV<version>_ReadMe.txt

Documentation


IntroscopeSOAExtensionforOracleServiceBusV<version>_ReadMe.txt

Documentation



Extracting Introscope SPM OSB Agent extensions

After you extract the Introscope SPM OSB Agent extensions, you’ll perform some configuration tasks.

Prerequisites


You must have installed and configured the appropriate version of Introscope SPM Agent extensions.

Stop the monitored ALSB 2.6 or OSB 3.0 application.

Extract the Introscope SPM OSB Agent extensions that you want to configure on a computer that satisfies all system requirements (see Introscope SPM Agent extension requirements on page 27).


» WARNING Do not install the OSB.pbd and OSBAgent.jar files into a WebLogic 8.1 agent. OSB does not support WebLogic 8.1. If you’re using the same Introscope agent to monitor multiple WebLogic agents any of which are version 8.1, your WebLogic 8.1 instance may experience severe problems.

To extract Agent extensions:

Before extracting Introscope SPM OSB Agent extensions, you must first download and extract the installation archive. See Downloading and extracting the Introscope SPM OSB installation archive on page 60.

1 Choose from this table the Introscope SPM OSB Agent extension archive appropriate for your environment.

2 In the temp directory into which the installation archive was downloaded and extracted (see Extracting Introscope SPM OSB Agent extensions on page 63), locate the appropriate Agent extension archive chosen in step 2.

Operating System Agent Extension Archive

Windows IntroscopeSOAExtensionforOracleServiceBusV<version>Agent.windows.zip

Unix (AIX, Linux, Solaris) IntroscopeSOAExtensionforOracleServiceBusV<version>Agent.unix.tar



3 Extract the Introscope SPM OSB Agent extension archive to <Agent_Home>, which contains the agent configuration file and is typically called wily. An example <Agent_Home> is c:\bea\wlserver_10.0\wily.

If you’re extracting Introscope SPM OSB Agent extensions in a Unix environment,

use the appropriate command in this table.

The Introscope SPM OSB Agent extension archive contains these files:

4 You now need to configure the Introscope SPM OSB Agent extension.

The Introscope SPM OSB Agent extension is extracted.

Configuring Introscope SPM OSB Agent extensions

After extracting the Introscope SPM OSB Agent extensions as described in Extracting Introscope SPM OSB Agent extensions on page 63, perform these steps to configure the Introscope SPM OSB Agent extension.

Prerequisites

Be sure you’ve carried out these prerequisites before you configure the Introscope SPM OSB Agent extensions:

While configuring a Introscope SPM OSB Agent extension, the monitored application should not be running. Stop the server before starting the configuration.

To configure Introscope SPM OSB Agent extensions:




Unix

(AIX, Linux, Solaris)

tar -xvf IntroscopeSOAExtensionforOracleServiceBusV<version>Agent.unix.tar

File Description

OSB.pbd The ProbeBuilder Directives file containing the tracers required to enable your application to collect OSB components metrics.

OSB.pbd automatically extracts to the <Agent_Home> directory.

OSBAgent.jar Extension to the Introscope Agent required by Introscope SPM OSB.

OSBAgent.jar automatically extracts to the <Agent_Home>/ext directory.



b Search for the introscope.autoprobe.directivesFile property.

c Add OSB.pbd to the introscope.autoprobe.directivesFile property.

For example:

introscope.autoprobe.directivesFile=OSB.pbd,hotdeployd Save and close the IntroscopeAgent.profile file.

2 Restart the ALSB 2.6 or OSB 3.0 application server into which the Introscope SPM OSB Agent extension is installed.

This restarts the Agent and loads the Introscope SPM OSB Agent extension.

3 Verify your deployment by invoking any OSB service and verifying that the OSB node exists in the Investigator tree.

4 If you want to configure multiple physical agents into a single Virtual Agent, see Configuring virtual agents for Introscope SPM on page 54.

The Introscope SPM OSB Agent extension is installed and configured. Now extract the Introscope SPM OSB EM extension. See Extracting Introscope SPM OSB EM extensions on page 66.

Uninstalling Introscope SPM OSB Agent extensions

To uninstall Introscope SPM OSB Agent extensions:

1 Stop the OSB application server.

2 Unmodify the Introscope SPM OSB Agent extension configuration properties.


b Remove the OSB.pbd value from the introscope.autoprobe.directivesFile property.

c Save and close the IntroscopeAgent.profile file.

3 Delete the OSBAgent.jar file from the <Agent_Home>/ext directory.

4 Delete the OSB.pbd file from the <Agent_Home> directory.

The Introscope SPM OSB Agent extension is uninstalled.



Extracting Introscope SPM OSB EM extensions

When you extract the Introscope SPM OSB EM extensions, you are installing the Introscope SPM OSB Management Module.

» Important If you’re installing Introscope SPM OSB in a clustered environment, extract the Introscope SPM OSB EM extensions on both the MOM and the Collectors. However, deploy the Management Module only on the MOM.

Prerequisite

You must have installed and configured the appropriate version of Introscope SPM EM extension.

To extract Introscope SPM OSB EM extensions:

1 Stop the Enterprise Manager on which you will install the Introscope SPM OSB EM extension.

2 Choose from this table the Introscope SPM OSB EM extension archive appropriate for your environment.

3 Extract all files in the Introscope SPM OSB EM extension archive file to the <EM_Home> directory.

» Note If you’re extracting EM extensions in a Unix environment, use the

appropriate command in this table.

Operating System

EM Extension Archive

Windows IntroscopeSOAExtensionforOracleServiceBusV<version>EM.windows.zip


IntroscopeSOAExtensionforOracleServiceBusV<version>EM.unix.tar

OS EM Extension Extract Command

Unix


tar -xvf IntroscopeSOAExtensionforOracleServiceBusV<version>EM.unix.tar



The Introscope SPM OSB EM extension archive contains these files:


5 Verify your installation.

See Verifying your Introscope SPM OSB deployment on page 68.

The Introscope SPM OSB EM extension is installed.

File Description

OSB.overview.tv.xml Extension to the Introscope Workstation. Enables the Workstation to show the Overview tab for OSB components, when any metric node under the OSB node is selected in the Investigator tree.

OSB.overview.tv.xml automatically extracts to the <EM_Home>/ext/xmltv directory.

OSB_ManagementModuleV<version>.jar

Introscope SPM OSB Management Module component that Enables the Workstation to show OSB health information

in Workstation dashboards Contains pre-configured OSB metric groupings, and alerts.

OSB_ManagementModuleV<version>.jar automatically extracts to the <EM_Home>/deploy directory. When the Enterprise Manager is started, OSB_ManagementModuleV<version>.jar is automatically moved to the <EM_Home>/config/modules directory.

com.wily.powerpacks.osb.emext.calculator_<version>.jar

Note: The version number in this file name includes only three digits. For example, 8.1.0.

Calculator that aggregates: OSB Proxy Service's request and response metrics, then

posts those metrics under the respective Proxy Service node.

OSB Transport metrics under the respective Transport Type.

com.wily.powerpacks.osb.emext.calculator_<version>.jar automatically extracts to the <EM_Home>/product/enterprisemanager/plugins directory.



Uninstalling Introscope SPM OSB EM extensions

To uninstall the Introscope SPM OSB EM extension:


2 Delete <EM_Home>/config/modules/OSB_ManagementModuleV<version>.jar.

3 Delete <EM_Home>/ext/xmltv/OSB.overview.tv.xml.

4 Delete <EM_Home>/product/enterprisemanager/plugins/com.wily.powerpacks.osb.emext.calculator_<version>.jar.

» Note The version number in this file name includes only three digits. For example, 8.1.0.


The Introscope SPM OSB EM extension is uninstalled.

Verifying your Introscope SPM OSB deployment

To verify that your Introscope SPM OSB deployment:

Verifying your deployment means ensuring that the Introscope SPM OSB Agent and EM extension implementations are successful.

1 Invoke any application that involves at least one OSB-specific component.

2 Verify that you can see the OSB node in Investigator:

You can see the OSB node under an agent into which an Introscope SPM OSB Agent extension was installed.

3 Click the OSB node.

The Overview tab is active by default in the Viewer pane. This verifies that the OSB.overview.tv.xml file is loaded properly on the Enterprise Manager.

4 In the Workstation Management Module Editor, verify the OSB_ManagementModule <version> (*SuperDomain*) node.


b Under *SuperDomain* | Management Modules, see the OSB_ManagementModule <version> (*SuperDomain*) node.

This verifies that the OSB_ManagementModuleV<version>.jar file loaded properly.

5 If the agent is installed and configured properly, you can see a message in the Introscope Agent log file stating the Introscope SPM OSB Agent extension version that started.

For example, [INFO] [IntroscopeAgent.OSB] Started Introscope SOA Extension for Oracle Service Bus Release <version> (Build xxxxxx).

Installing and configuring Introscope SPM WPS/WESB Agent and EM extensions 69


Installing and configuring Introscope SPM WPS/WESB Agent and EM extensions

Websphere Process Server (WPS) includes Websphere Enterprise Service Bus (WESB) as well as some additional components. The service integrations bus manages the flow of messages in WPS. WESB handles any data transformation or routing required between services and clients with the help of mediation flows and primitives. When Introscope SPM monitors WPS, Introscope displays health data for both WPS and WESB.

IBM also provides Websphere Enterprise Service Bus as a standalone product. So when Introscope SPM monitors WESB only, Introscope displays health data about WESB only, not for WPS and WESB.

This topic describes how you can extract, install, and configure the Introscope SPM WPS/WESB Agent and EM extensions needed for Introscope SPM to monitor your WPS/WESB environment.

Before you begin the installation process, ensure that you have met the required prerequisites.

Introscope SPM WPS/WESB extensions install prerequisites checklist:

Check that for all Introscope SPM WPS/WESB Java Agent extensions you plan to install, that CA Wily Introscope Agent 8.1.0.0 or later is installed and configured correctly for WPS version 6.0.2, 6.1, 6.1.2, or 6.2.

Check that the Introscope Agent is communicating with the Enterprise Manager on which you plan to install the Introscope SPM WPS/WESB EM extension.

Check that your environment meets the requirements stated in Hardware and software requirements on page 26.



Downloading and extracting the Introscope SPM WPS/WESB installation archive

The Introscope SPM WPS/WESB installation archive contains two files: the Introscope SPM WPS/WESB Agent extension and EM extension After you download and extract the installation archive, you’ll download and extract the documentation archive. After you download and extract the installation archive, you’ll Then you’ll extract the Introscope SPM WPS/WESB Agent extensions, then the Introscope SPM WPS/WESB EM extensions.

To download and extract the installation archive:


2 Download from the Software Download Site the Introscope SPM WPS/WESB installation archive.




» Note If you’re extracting in a Unix or z/OS environment, use the appropriate

command in this table.

OS Installation Archive File Name

Windows IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>windows.zip

Unix(AIX, Linux, Solaris)

IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>unix.tar

z/OS IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>zOS.tar

OS Installation Archive Extract Command


tar -xvf IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>unix.tar

z/OS tar -xvfo IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>zOS.tar



The Introscope SPM WPS/WESB installation archive contains Agent extension and EM extension files. The files you see depend on your operating system, as shown

in this table:

4 Download from the Software Download Site the Introscope SPM WPS/WESB documentation.


OS Files that extract from the installation archive Description

Windows IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>Agent.windows.zip

IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>EM.windows.zip

Introscope SPM WPS/WESB Windows Agent extension

EM extension


IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>Agent.unix.tar

IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>EM.unix.tar

Introscope SPM WPS/WESB Unix Agent extension

EM extension

z/OS IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>Agent.zOS.tar

IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>EM.zOS.tar

Introscope SPM WPS/WESB z/OS Agent extension

EM extension


Windows IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>Docs.windows.zip

Unix (AIX, Linux, Solaris) IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>Docs.unix.tar

z/OS IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>Docs.zOS.tar



5 Extract the documentation file.

» Note If you’re extracting documentation in a Unix or z/OS environment, use

the appropriate command in this table.

The Introscope SPM WPS/WESB documentation archive contains a ReadMe file,

as shown in this table:


Now you will extract and configure the Introscope SPM WPS/WESB Agent extensions.

Extracting Introscope SPM WPS/WESB Agent extensions

After you extract the Introscope SPM WPS/WESB Agent extensions, you’ll perform some configuration tasks.

Prerequisites


You must have installed and configured the appropriate version of Introscope SPM Agent extensions.

You must have installed and configured the appropriate version of Introscope SPM EM extension.



Unix (AIX, Linux, Solaris) tar -xvf IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>Docs.unix.tar

z/OS tar -xvfo IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>Docs.zOS.tar

OS Files that extract from the documentation archive Description

Windows IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>_ReadMe.txt

Documentation


IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>_ReadMe.txt

Documentation

z/OS IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>_ReadMe.txt

Documentation



Extract the Introscope SPM WPS/WESB Agent extensions that you want to install and configure on a computer that satisfies all system requirements (see Introscope SPM Agent extension requirements on page 27).


Stop the WPS application server.

To extract Introscope SPM WPS/WESB Agent extensions:

Before extracting Introscope SPM WPS/WESB Agent extensions, you must first install and extract the installation archive. See Downloading and extracting the Introscope SPM WPS/WESB installation archive on page 70.

1 Choose from this table the Introscope SPM WPS/WESB Agent extension archive appropriate for your environment.

2 In the temp directory into which the installation archive was installed and extracted (see Downloading and extracting the Introscope SPM WPS/WESB installation archive on page 70), locate the appropriate Agent extension archive chosen in step 2.

3 Extract the Introscope SPM WPS/WESB Agent extension archive to <Agent_Home>, which contains the agent configuration and is typically called wily.

If you’re extracting Introscope SPM WPS/WESB Agent extensions in a Unix or z/

OS environment, use the appropriate command in this table.

Operating System Agent Extension Archive

Windows IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESB<version>Agent.windows.zip

Unix (AIX, Linux, Solaris) IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESB<version>Agent.unix.tar

z/OS IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESB<version>Agent.zOS.tar


Unix (AIX, Linux, Solaris) tar -xvf IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESB<version>Agent.unix.tar

z/OS tar -xvfo IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESB<version>Agent.zOS.tar



The Introscope SPM WPS/WESB Agent extension archive contains these files:

4 You now need to configure the Introscope SPM WPS/WESB Java Agent extensions.

The Introscope SPM WPS/WESB Agent extension is extracted.

Based on your environment, proceed to the appropriate configuration topic.

File Description

WPS.pbd The ProbeBuilder Directives file containing the tracers required to enable your application to collect WPS components-related metrics.

WPS.pbd automatically extracts to the <Agent_Home> directory.

WPS.pbd contains all the tracers needed for providing metrics in a WPS environment, which includes WPS components including WESB.

WESB.pbd The ProbeBuilder Directives file containing the tracers required to enable your application to collect WESB components-related metrics.

WESB.pbd automatically extracts to the <Agent_Home> directory.

WESB.pbd contains all the tracers needed for providing metrics in standalone WESB environment.

WPSAgentExt.jar Extension to the Introscope Agent required by Introscope SPM WPS/WESB.

WPSAgentExt.jar automatically extracts to the <Agent_Home>\ext directory.

Platform Go to this topic next

WPS Configuring Introscope SPM WPS Agent extensions on page 75

WESB Configuring Introscope SPM WESB Agent extensions on page 79



Configuring Introscope SPM WPS Agent extensions

After extracting the Introscope SPM WPS/WESB Agent extensions, perform these steps to configure each Introscope SPM WPS Agent extension.

Prerequisites

Be sure you’ve carried out these prerequisites before you configure the Introscope SPM WPS Agent extension:

While configuring a Introscope SPM WPS Agent extension, the server should not be running. Stop the server before starting the configuration.

To configure Introscope SPM WPS Agent extensions:




c Add WPS.pbd to the introscope.autoprobe.directivesFile property.

For example: introscope.autoprobe.directivesFile=webspheretypical.pbl,WPS.

pbd,hotdeploy

» Note The WPS.PBD retrieves the metrics related to both the WPS and WESB tiers.

d Save and close the IntroscopeAgent.profile file.



2 Optional: Configure IntroscopeAgent.profile so Introscope SPM monitors WebSphere PMI metrics.

If you want to view Performance Monitoring Infrastructure (PMI) metrics in Introscope SPM Investigator for the WPS-related components, you need to perform some configuration.

Prerequisites

The Introscope PowerPack for WebSphere Application Server Distributed v8.0 must be installed and configured. For more information, see the Introscope PowerPack for IBM® WebSphere® Application Server Distributed User Guide.


b Search for these properties:

introscope.agent.pmi.enable.WBIStats.RootGroup

introscope.agent.pmi.enable.SCAStats.RootGroup,

then choose the next step to go to depending on your environment.

c If the properties below are already present and set to true, no configuration is needed, and you can go to step 3 below.

introscope.agent.pmi.enable.WBIStats.RootGroup=true

introscope.agent.pmi.enable.SCAStats.RootGroup=true

d If the properties below are set to false, you must configure them by changing them to true as shown.



e If these properties are not in IntroscopeAgent.profile, add them to IntroscopeAgent.profile and set them to true to enable PMI metrics reporting in Introscope SPM:



f Save and close the IntroscopeAgent.profile file.

3 Optional: Configure WPS.pbd to provide separate metrics for different versions of a Business Process.

» Note Use the default configuration unless your environment has a business process that has more than one version.

If the PMI properties are then go to this step below

In IntroscopeAgent.profile and set to true step c

In IntroscopeAgent.profile and set to false step d

Not in IntroscopeAgent.profile step e



a Go to the <Agent_Home> directory and open the WPS.pbd file.

b Comment the ProcessCustomTracer and ProcessFaultTracer parameters as shown before you use the ProcessAndTimeNameFormatter.

#SetTracerParameter: ProcessCustomTracer nameformatter com.wily.powerpack.websphereprocserver.nameformatter.Process

ContextFormatter

#SetTracerParameter: ProcessFaultTracer nameformatter com.wily.powerpack.websphereprocserver.nameformatter.Process

ContextFormatter

c Uncomment the ProcessCustomTracer and ProcessFaultTracer parameters as shown to get the time attribute.

SetTracerParameter: ProcessCustomTracer nameformatter com.wily.powerpack.websphereprocserver.nameformatter.Process

AndTimeNameFormatter

SetTracerParameter: ProcessFaultTracer nameformatter com.wily.powerpack.websphereprocserver.nameformatter.Process

AndTimeNameFormatter

d Save and close WPS.pbd.

4 Optional: Configure the WPS.pbd to see the activities executed in the Business Process Execution.

» Important There is significant agent CPU overhead involved in sending the activities names data to the Enterprise Manager, therefore activity tracing is off by default. Turn on activity tracing only when required.

a Go to the <Agent_Home> directory and open the WPS.pbd file.

b Uncomment ActivityTracing and ActivityResponseTracing as shown to see the activities executed in the Business Process Execution.

TurnOn: ActivityTracing

TurnOn: ActivityResponseTracing

c Save and close WPS.pbd.

5 Start the WPS application server into which the Introscope SPM WPS Agent extension is installed.

This restarts the Agent and loads the Introscope SPM WPS Agent extension.

6 If you performed Optional: Configure IntroscopeAgent.profile so Introscope SPM monitors WebSphere PMI metrics. on page 76, enable the WPS/WESB specific modules from the Admin console.

See the IBM WPS/WESB documentation about enabling modules in the Admin Console.



7 Verify that the Introscope SPM WPS Agent extension is successfully installed and configured.

a Open the IntroscopeAgent.log in the <Agent_Home>\logs folder.

b Look for this log message (where xxxxxx is the build number)[INFO] [IntroscopeAgent.WebSphereProcessServer_WESB] Started Introscope SOAExtension for IBM WebSphere ProcessServer and WESB Release <version> (Build xxxxxx).

If you see the log message, the Introscope SPM WPS Agent extension is successfully loaded and running.

If you do not see the log message, review and verify the installation and configuration instructions.

8 Verify your deployment by invoking any application having WPS-specific components and verifying that the WProcServer node exists in the Investigator tree.

The Introscope SPM WPS Agent extension is installed and configured. Now extract the Introscope SPM WPS EM extension. See Extracting Introscope SPM WPS EM extensions on page 82.

Uninstalling Introscope SPM WPS Agent extensions

To uninstall Introscope SPM WPS Agent extensions:

1 Stop the WPS application server.

2 Unmodify the Introscope SPM WPS Agent extension configuration properties.


b Remove the WPS.pbd value from the introscope.autoprobe.directivesFile property.

c Remove any properties added to monitor WebSphere PMI metrics. See Optional: Configure IntroscopeAgent.profile so Introscope SPM monitors WebSphere PMI metrics. on page 76.


3 Delete the WPSAgentExt.jar file from the <Agent_Home>/ext directory.

The Introscope SPM WPS Agent extension is uninstalled.



Configuring Introscope SPM WESB Agent extensions

After extracting the Introscope SPM WPS/WESB Agent extensions, perform these steps to configure each Introscope SPM WESB Agent extension.

To configure Introscope SPM WESB Agent extensions:




c Add WESB.pbd to the introscope.autoprobe.directivesFile property.

For example:

introscope.autoprobe.directivesFile=webspheretypical.pbl,WESB.pbd ,hotdeploy

» Note The WESB.PBD is specific to WESB clients that retrieves metrics for all the components present in WESB


2 Optional: Configure IntroscopeAgent.profile so Introscope SPM monitors WebSphere PMI metrics.

If you want to view Performance Monitoring Infrastructure (PMI) metrics in Introscope SPM Investigator for the WESB-related components, you need to perform some configuration.

Prerequisites

The Introscope PowerPack for WebSphere Application Server Distributed v8.0 must be installed and configured. For more information, see the Introscope PowerPack for IBM® WebSphere® Application Server Distributed User Guide.




b Search for these properties

introscope.agent.pmi.enable.WBIStats.RootGroup

introscope.agent.pmi.enable.SCAStats.RootGroup,

then choose the next step to go to depending on your environment.

c If the properties below are already present and set to true, no configuration is needed, and you can go to step 3 below.



d If the properties below are set to false, you must configure them by changing them to true as shown.



e If these properties are not in IntroscopeAgent.profile, add them to IntroscopeAgent.profile and set them to true to enable PMI metrics reporting in Introscope SPM:



f Save and close the IntroscopeAgent.profile file.

3 Restart the WESB application server into which the Introscope SPM WESB Agent extension is installed.

This restarts the Agent and loads the Introscope SPM WESB Agent extension.

4 If you performed Optional: Configure IntroscopeAgent.profile so Introscope SPM monitors WebSphere PMI metrics. on page 79, enable the WPS/WESB specific modules from the Admin console.

See the IBM WPS/WESB documentation about enabling modules in the Admin Console.

5 Verify that the Introscope SPM WESB Agent extension is successfully installed and configured.

a Open the IntroscopeAgent.log in the <Agent_Home>\logs folder.

If the PMI properties are then go to this step below

In IntroscopeAgent.profile and set to true step c

In IntroscopeAgent.profile and set to false step d

Not in IntroscopeAgent.profile step e



b Look for this log message (where xxxxx is the build number).[INFO] [IntroscopeAgent.WebSphereProcessServer_WESB] Started Introscope SOAExtension for IBM WebSphere ProcessServer and WESB Release <version> Build xxxxxx).

c If you see the log message, the Introscope SPM WESB Agent extension is successfully loaded and running.

d If you do not see the log message, review and verify the installation and configuration instructions.

6 Verify your deployment by invoking any application having WESB-specific components and verifying that the WESB node exists in Introscope Investigator tree.

The Introscope SPM WESB Agent extension is configured. Now extract the Introscope SPM WESB EM extension. See Extracting and configuring Introscope SPM WESB EM extensions on page 85.

Uninstalling Introscope SPM WESB Agent extensions

To uninstall Introscope SPM WESB Agent extensions:

1 Stop the WESB application server.

2 Unmodify the Introscope SPM WESB Agent extension configuration properties.


b Remove the WESB.pbd value from the introscope.autoprobe.directivesFile property.

c Remove any properties added to monitor WebSphere PMI metrics. See Optional: Configure IntroscopeAgent.profile so Introscope SPM monitors WebSphere PMI metrics. on page 76.


3 Delete the WPSAgentExt.jar file from the <Agent_Home>/ext directory.

The Introscope SPM WESB Agent extension is uninstalled.



Extracting Introscope SPM WPS EM extensions

When you extract the Introscope SPM WPS EM extensions, you are installing the Introscope SPM WPS management module.

» Important If you’re installing Introscope SPM WPS in a clustered environment, extract the Introscope SPM WPS EM extensions on both the MOM and the Collectors. However, deploy the Management Module only on the MOM.

Prerequisites

You must have installed and configured the appropriate version of the Introscope SPM EM extension.

If you have already installed a WESB EM extension on the Enterprise Manager on which you want to install the WPS EM extension as well, see Extracting and configuring WPS and WESB EM extensions on the same Enterprise Manager or MOM on page 88.

To extract Introscope SPM WPS EM extensions:

1 Stop the Enterprise Manager on which you will install the Introscope SPM WPS EM extension.

2 Choose from this table the Introscope SPM WPS EM extension archive appropriate for your environment.

3 In the temp directory into which the installation archive was installed and extracted (see Downloading and extracting the Introscope SPM WPS/WESB installation archive on page 70), locate the appropriate EM extension archive chosen in step 2.


Windows IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>EM.windows.zip

Unix (AIX, Linux, Solaris) IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>EM.unix.tar

z/OS IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>EM.zOS.tar



4 Extract all files in the Introscope SPM WPS EM extension archive file to the <EM_Home> directory.

» Note If you’re extracting Introscope SPM WPS EM extensions in a Unix or

z/OS environment, use the appropriate command in this table.

The Introscope SPM WPS EM extension archive contains these files:


Unix


tar -xvf IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>EM.unix.tar

z/OS tar -xvfo IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>EM.zOS.tar

File Description

wps.overview.tv.xml Extension to the Introscope Workstation. Enables the Workstation to show the Overview tab for WPS components when any metric node under the WProcServer node is selected in the Investigator tree.

wps.overview.tv.xml automatically extracts to the <EM_Home>/ext/xmltv directory.

WPS_Management_ModuleV<version>.jar

Introscope SPM WPS management module that Enables the Workstation to show WPS health in

dashboards. Contains pre-configured WPS dashboards, metrics

groupings and alerts.

WPS_Management_ModuleV<version>.jar automatically extracts to the <EM_Home>/deploy directory. When the Enterprise Manager is started, WPS_Management_ModuleV<version>.jar is automatically moved to the <EM_Home>/config/ modules directory.

WESB_Management_ModuleV<version>.jar

Introscope SPM WESB management module that Enables the Workstation to show WESB health in

dashboards. Contains pre-configured WESB dashboards, metrics


WESB_Management_ModuleV<version>.jar automatically extracts to the <EM_Home>/deploy directory. When the Enterprise Manager is started, WESB_Management_ModuleV<version>.jar is automatically moved to the <EM_Home>/config/modules directory.



5 Delete the WESB_Management_ModuleV<version>.jar file from the <EM_Home>/deploy directory.


7 Verify your installation. See Verifying your Introscope SPM WPS deployment on page 89.

The Introscope SPM WPS EM extension is installed.

Uninstalling Introscope SPM WPS EM extensions

To uninstall the Introscope SPM WPS EM extension:


2 Delete <EM_Home>/config/modules/WPS_Management_ModuleV<version>.jar.

3 Delete <EM_Home>/ext/xmltv/wps.overview.tv.xml.

4 Delete <EM_Home>/product/enterprisemanager/plugins/com.wily.powerpack.websphereprocserver.em.ext_<version>.jar.



The Introscope SPM WPS EM extension is uninstalled.

com.wily.powerpack.websphereprocserver.em.ext_<version>.jar


Calculator that aggregates the metrics for each Mediation Flow component and its operations. See About aggregated metrics for mediation flows on page 281.

com.wily.powerpack.websphereprocserver.em.ext_<version>.jar automatically extracts to the <EM_Home>/product/enterprisemanager/plugins directory.

File Description



Extracting and configuring Introscope SPM WESB EM extensions

When you extract the Introscope SPM WPS/WESB EM extensions, you are installing the Introscope SPM WESB management module.

» Important If you’re installing Introscope SPM WESB in a clustered environment, extract the Introscope SPM WPS/WESB EM extensions on both the MOM and the Collectors. However, deploy the Management Module only on the MOM.

Prerequisite

You must have installed and configured the appropriate version of the Introscope SPM EM extension.

If you have already installed a WPS EM extension on the Enterprise Manager on which you want to install the WESB EM extension as well, see Extracting and configuring WPS and WESB EM extensions on the same Enterprise Manager or MOM on page 88.

To extract Introscope SPM WESB EM extensions:

1 Stop the Enterprise Manager on which you will install the Introscope SPM WESB EM extension.

2 Choose from this table the Introscope SPM WESB EM extension archive appropriate for your environment.

3 In the temp directory into which the installation archive was installed and extracted (see Downloading and extracting the Introscope SPM WPS/WESB installation archive on page 70), locate the appropriate EM extension archive chosen in step 2.


Windows IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>EM.windows.zip


IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>EM.unix.tar

z/OS IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>EM.zOS.tar



4 Extract all files in the Introscope SPM WESB EM extension archive file to the <EM_Home> directory.

» Note If you’re extracting Introscope SPM WESB EM extensions in a Unix or

z/OS environment, use the appropriate command in this table.

The Introscope SPM WESB EM extension archive contains these files:


Unix


tar -xvf IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>EM.unix.tar

z/OS tar -xvfo IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version>EM.zOS.tar

File Description

wps.overview.tv.xml Extension to the Introscope Workstation. Enables the Workstation to show the Overview tab for WESB components when any metric node under the WESB node is selected in the Investigator tree.

wps.overview.tv.xml automatically extracts to the <EM_Home>/ext/xmltv directory.

WPS_Management_ModuleV<version>.jar

Introscope SPM WPS management module that

Enables the Workstation to show WPS health in dashboards.

Contains pre-configured WPS dashboards, metrics groupings, and alerts.

WPS_Management_ModuleV<version>.jar automatically extracts to the <EM_Home>/deploy directory. When the Enterprise Manager is started, WPS_Management_ModuleV<version>.jar is automatically moved to the <EM_Home>/config/modules directory.



5 Delete the WPS_Management_ModuleV<version>.jar file from the <EM_Home>/deploy directory.


7 Verify your installation. See Verifying your Introscope SPM WESB deployment on page 90.

The Introscope SPM WESB EM extension is installed.

Uninstalling Introscope SPM WESB EM extensions

To uninstall the Introscope SPM WPS EM extension:


2 Delete <EM_Home>/config/modules/WESB_Management_ModuleV<version>.jar.

3 Delete <EM_Home>/ext/xmltv/wps.overview.tv.xml.

Delete <EM_Home>/product/enterprisemanager/plugins/com.wily.powerpack.websphereprocserver.em.ext_<version>.jar.



The Introscope SPM WESB EM extension is uninstalled.

WESB_Management_ModuleV<version>.jar

Introscope SPM WESB management module that Enables the Workstation to show WESB health in

dashboards. Contains pre-configured WESB dashboards, metrics


WESB_Management_ModuleV<version>.jar automatically extracts to the <EM_Home>/deploy directory. When the Enterprise Manager is started, WESB_Management_ModuleV<version>.jar is automatically moved to the <EM_Home>/config/modules directory.

com.wily.powerpack.websphereprocserver.em.ext_<version>.jar


Calculator that aggregates the metrics for each Mediation Flow component and its operations. See About aggregated metrics for mediation flows on page 281.

com.wily.powerpack.websphereprocserver.em.ext_<version>.jar automatically extracts to the <EM_Home>/product/enterprisemanager/plugins directory.

File Description



Extracting and configuring WPS and WESB EM extensions on the same Enterprise Manager or MOM

These topics describe how you extract and configure an Introscope SPM WPS or WESB EM extension when either the Introscope SPM WPS or the WESB EM extension is already installed on your Enterprise Manager or MOM and you want

to install the other extension. This allows you to view all the dashboards, tabs, and metrics for the additional platform.

To extract and configure WESB extensions in an existing Introscope SPM WPS environment:

If you

are running both Websphere Process Server and Websphere Enterprise Service Bus server in your environment

would like to connect the Introscope SPM agents for both of your implementations to a single Enterprise Manager or MOM

then you must perform these additional configuration steps.

1 Carry out step 1 through step 3 of To extract Introscope SPM WESB EM extensions: on page 85.

2 Extract to <EM_Home> only the WESB_Management_ModuleV<version>.jar file which provides Introscope SPM WESB dashboards, tabs, and metrics.

The WESB_Management_ModuleV<version>.jar file should automatically extract to the <EM_Home>\deploy directory.

If the WESB_Management_ModuleV<version>.jar file extracts to the <EM_Home> directory, move the file to the <EM_Home>\deploy directory.

When the Enterprise Manager is started, WESB_Management_ModuleV<version>.jar is automatically moved to the <EM_Home>/config/ modules directory


4 Verify your installation. See Verifying your Introscope SPM WESB deployment on page 90.

The Introscope SPM WESB EM extension is installed.



To extract and configure WPS extensions in an existing Introscope SPM WESB environment:

If you

are running both the Websphere Process Server and the Websphere Enterprise Service Bus server in your environment

would like to connect the Introscope SPM agents for both of your implementations to a single Enterprise Manager or MOM

then you must perform these additional configuration steps.

1 Carry out step 1 through step 3 of To extract Introscope SPM WPS EM extensions: on page 82.

2 Extract to <EM_Home> only the WPS_Management_ModuleV<version>.jar file, which provides Introscope SPM WPS dashboards, tabs, and metrics.

The WPS_Management_ModuleV<version>.jar file should automatically extract to the <EM_Home>\deploy directory.

If the WPS_Management_ModuleV<version>.jar file extracts to the <EM_Home> directory, move the file to the <EM_Home>\deploy directory.

When the Enterprise Manager is started, WPS_Management_ModuleV<version>.jar is automatically moved to the <EM_Home>/config/ modules directory


4 Verify your installation. See Verifying your Introscope SPM WPS deployment on page 89.

The Introscope SPM WPS EM extension is installed.

Verifying your Introscope SPM WPS deployment

To verify that your Introscope SPM WPS deployment:

Verifying your deployment means ensuring that the Introscope SPM WPS Agent and EM extension implementations are successful.

1 Invoke any application that involves at least one WPS-specific component.

2 Verify that you can see the WProcServer node in Investigator:

You can see the WProcServer node under an agent into which an Introscope SPM WPS Agent extension was installed.

3 Click the WProcServer node.

The Overview tab is active by default in the Viewer pane. This verifies that the wps.overview.tv.xml file is loaded properly on the Enterprise Manager.



4 In the Workstation Management Module Editor, verify the WPS_Management_Module <version> node.


b Under SuperDomain, see the WPS_Management_Module <version> node.

This verifies that the WPS_Management_ModuleV<version>.jar file loaded properly.

5 If the agent is installed and configured properly, you can see a message in the Introscope Agent log file stating the Introscope SPM WPS Agent extension version that started.

For example:

[INFO] [IntroscopeAgent.WebSphereProcessServer_WESB] Started

Introscope SOAExtension for IBM WebSphere ProcessServer and WESB

Release <version> (Build xxxxxx).

Verifying your Introscope SPM WESB deployment

To verify that your Introscope SPM WESB deployment:

Verifying your deployment means ensuring that the Introscope SPM WESB Agent and EM extension implementations are successful.

1 Invoke any application that involves at least one WESB-specific component.

2 Verify that you can see the WESB node in Investigator:

You can see the WESB node under an agent into which an Introscope SPM WPS Agent extension was installed.

3 Click the WESB node.

The Overview tab is active by default in the Viewer pane. This verifies that the wps.overview.tv.xml file is loaded properly on the Enterprise Manager.

4 In the Workstation Management Module Editor, verify the WESB_Management_Module <version> node.


b Under SuperDomain, see the WESB_Management_Module <version> node.

This verifies that the WESB_Management_ModuleV<version>.jar file loaded properly.



5 If the agent is installed and configured properly, you can see a message in the Introscope Agent log file stating the Introscope SPM WESB Agent extension version that started.

For example:[INFO] [IntroscopeAgent.WebSphereProcessServer_WESB] Started

Introscope SOAExtension for IBM WebSphere ProcessServer and WESB

Release <version> (Build xxxxxx).

Monitoring web services 93

CHAPTER 3

Monitoring web services

Introscope SPM enables you to monitor web services by viewing web service related metrics in Introscope. This chapter discusses using the Introscope Console and Investigator to view and interpret web service metrics.

Viewing web services data in Introscope SPM . . . . . . . . . . 94

SOA Performance Management dashboards . . . . . . . . . . 95

SOA Performance Management tabs . . . . . . . . . . . . . 105

Viewing web service metrics in the Investigator . . . . . . . . . 128

Viewing agent web service metrics . . . . . . . . . . . . . 132

Viewing Introscope SPM metric groupings and alerts . . . . . . . 138

Checking the health of your web services . . . . . . . . . . . 140

94 Monitoring web services


Viewing web services data in Introscope SPMWhen Introscope SPM is installed, metric information is viewed through the Introscope Workstation using Introscope SPM-specific dashboards and tabs. A SOA Dependency Map is also available to view a graphical display of web service dependencies. You use the SOA Dependency Map to see how web services are related to each other - which web services and operations on an agent depend on web services and operations on the same or a different agent. The SOA Dependency Map displays key web service metrics for the agents, services, and operations.

You can also view ErrorDector and Transaction Tracing information in the Investigator to help analyze web service transactions.

Web service data is available in these locations in the Introscope Workstation:

Investigator tree node name What you see in the associated Overview tab

Agent application High-level health indicators of all the applications instrumented on the agent. For more information, see the Introscope Workstation User Guide.

This tab is supplied by default with Introscope.

WebServices Overview tables listing the client and server web service namespaces that belong to the selected agent application.

Client or Server Overview table listing the web service namespaces that belong to the selected agent application client or server.

web service

Note: The node name displayed is the name of a web service in use by the agent application client or server.

Overview table listing the operations that belong to the selected web service.

operation name (method) Graphs showing the current level of activity for these metrics for the selected operation: Average Response Time Concurrent Invocations Errors Per Interval Responses Per Interval SOAP Faults Per Interval Stall Count

SOA Performance Management dashboards 95


Starting the Introscope Workstation

Start the Introscope Workstation, then Investigator to get a complete view of your web service transactions and performance.

To start the Introscope Workstation:

Choose Start > Programs > CA Wily > Introscope_Version > Introscope Workstation.

» Note The Introscope Enterprise Manager must be started before starting the Workstation.

When you start the Introscope Workstation, you see the Console containing various Introscope dashboards. With Introscope SPM, you get six custom dashboards in addition to those provided with Introscope. Dashboards are a quick way to check on the health of your web services in Introscope SPM. Color-coded alerts (green, yellow, red) tell you in a glance how your web services are performing. For more information about Introscope SPM dashboards, see SOA Performance Management dashboards on page 95.

To see Introscope metrics for web services in a tree view, you can look in the Investigator. Here, you see metrics about web services within each agent, aggregated across agents, as well as web service errors and Transaction Traces. For detailed information on using the Workstation, see the Introscope Workstation User Guide. For more information about Introscope SPM metrics, see SOA Performance Management tabs on page 105.

SOA Performance Management dashboardsIntroscope SPM provides pre-configured dashboards to show a variety of web service performance data. Dashboards aggregate data across all your deployed agents.

Use these dashboards in Introscope to view web service metrics:

Introscope SPM Overview: Shows an overview of monitored web services in terms of client and server performance and alert summary. For more information, see Introscope SPM Performance Overview dashboard on page 96.

Introscope SPM Client Health: Shows the client’s performance. For more information, see Introscope SPM Client Health dashboard on page 99.

Introscope SPM Server Health: Shows the server’s performance. For more information, see Introscope SPM Server Health dashboard on page 100.

Introscope SPM Most Critical Operations: Shows the most critical web service operations. For more information, see Introscope SPM Most Critical Operations dashboard on page 101.



Introscope SPM Most Dependent Operations: Shows the most dependent web service operations. For more information, see Introscope SPM Most Dependent Operations dashboard on page 102.

Introscope SPM Busiest Operations: Shows the busiest web service operations. For more information, see Introscope SPM Busiest Operations dashboard on page 104.

Introscope SPM comes with default caution/danger alert thresholds for many of the performance metrics displayed in the dashboards. See the Introscope Workstation User Guide for information on customizing these alerts and thresholds to your environment.

To view dashboards:

1 Start the Introscope Workstation Console.

2 Select a dashboard from the drop-down list.

Introscope SPM Performance Overview dashboard

When monitoring web services, your first step is to view the SOA Performance Overview dashboard. It displays information about the overall health of your client and server performance.

Double-click a service to see it in the Investigator.



Use the SOA Performance Overview dashboard to see:

Top 10 slowest client and server services

Average response times for client and server

Alerts indicating the overall client and server health, reporting the overall status of the following:

Response Time

SOAP Faults

Errors

Stalls

» Note The default Average Response Time danger and caution threshold settings for the Client (2.5 and 5.5 seconds) are set slightly higher than for the Server (2 and 5 seconds) to allow for network latency.

To get more information:

Double-click one of the top 10 slowest services to see the Investigator metrics for that operation.

Determining whether a problem is caused by the client or server

The alerts displayed in the client and server health sections of the SOA Performance Overview dashboard may indicate one of four scenarios:

green client + green server = all is well

green client + yellow/red server = there is a server issue, but network traffic is fast, so it hasn’t affected the client yet

yellow/red client + green server = slow network traffic or some other client-side issue

yellow/red client + yellow/red server = probably a server problem

Causes of client or server slowness

Common causes of client slowness include:

Concurrency (many users are sending requests at the same time)

Server is slow

Server slowness can have many causes, including:

Other web services EJBs

JMS JDBC

File systems External systems (MQ, DB)



Why average response time is not the whole story

The alerts displayed in the client and server health sections of the SOA Performance Overview dashboard represent Summary Alerts for the status of four alerts: Average Response Time, SOAP Faults Per Interval, Errors Per Interval, and Stalls Per Interval. It is important to read these metrics together to obtain an accurate representation of web service performance.

For example, you may see a low Average Response Time along with a high SOAP Faults Per Interval. Normally, a low Average Response Time tells you that all is well. However, in some cases, a low Average Response Time could mean that you are getting a lot of web service (SOAP) faults. If there are a lot of faults, operations stop quickly.

» Note While many web service implementations use a fault to signify an error, it is not always the case. For more information, see About error and SOAP fault metrics on page 129. With some web services, a high rate of faults may indicate that the end user is asking the application to do something that it cannot do, or cannot find.

Response times for synchronous and asynchronous invocations

Synchronous and asynchronous web service invocation types report client response time slightly differently:

In synchronous web service invocations, the request message leaves the client, the request is processed and fulfilled by the server, and a response message comes back to the client that the request has been fulfilled and is complete. With synchronous web service invocations, the response time on the server side will never be longer than the response time on the client side, because the client time includes the server time.

In asynchronous web service invocations, the request message leaves the client, the server receives the request and sends a confirmation response message back to the client. The request may or may not have been fulfilled when the server sends the confirmation message. Asynchronous web service invocations occur when the web service implementation needs more information to fulfill the request, or the request needs to be sent to another web service or database.

In an asynchronous environment, the client-side Average Response Time is never indicative of the entire time to process a request. Introscope displays only the time it takes to receive the confirmation of the request, not the fulfillment of the request.



More detailed information

The SOA Performance Overview dashboard also provides links to the Client Health, Server Health, Most Critical Operations, Most Dependent Operations, and Busiest Operations dashboards, which have more detailed information about your SOA environment. Double-click the tabs at the top of the SOA Performance Overview dashboard to navigate to these dashboards.

You can also find more overview information in the Workstation Investigator using the SOA Performance Overview tabs. For more information on the overview tabs, see Using the Overview tabs on page 105. For more information on all tabs, see SOA Performance Management tabs on page 105.

Introscope SPM Client Health dashboard

The SOA Performance Client Health dashboard contains data viewers that show detailed information for triaging client issues.

Use the SOA Performance Client Health dashboard to see:

Top 10 Slowest Client Operations

Double-click an operation to see it in the Investigator.



Client Operations Average Response Time—each metric represents the average response time for one method or operation

Client Services SOAP Faults Per Interval—total faults for all web services

Client Services Average Response Time (per web service)—each metric represents the average of response times for all methods or operations in the web service

Client Services Responses Per Interval—total responses for all web services


Double-click one of the top 10 slowest operations to see the Investigator metrics for that operation.

Hover your mouse cursor over any data point to display a tool-tip showing details for that web services data point.

Introscope SPM Server Health dashboard

The SOA Performance Server Health dashboard contains data viewers that show detailed information used to triage server issues.




Use the SOA Performance Server Health dashboard to see:

Top 10 slowest web service operations

Server Operations Average Response Time—each metric represents the average response time for one method or operation

Server Services SOAP Faults Per Interval—total faults for all web services

Server Services Average Response Time (per web service)—each metric represents the average of response times for all methods or operations in the web service

Server Services Responses Per Interval—total responses for all web services


Double-click one of the top 10 slowest operations to see the Investigator metrics for that operation.


Introscope SPM Most Critical Operations dashboard

The Introscope SPM Most Critical Operations dashboard contains the operations with the highest number of operations that depend on them. These operations are the most important potential points of failure and need close monitoring.

Use the Most Critical Operations dashboard to monitor the most critical operations and the Deviations tab in the Investigator for triage purposes. For more information about the tab, see Using the Deviations tab on page 118.



The dashboard show graphs of these deviation metrics:

Average Response Time Deviation

Errors Per Interval Deviation

Responses Per Interval Deviation

For more information about these metrics, see Using the Most Critical tab on page 124.


Double-click one of the top 10 Most Critical Operations to see the Investigator metrics for that operation.

Introscope SPM Most Dependent Operations dashboard

The Introscope SPM Most Dependent Operations dashboard shows the operations with the highest number of dependencies on related operations for all agents.




Use the dashboard to monitor the most dependent operations for all agents and the Deviations tab in the Investigator for triage purposes for a single agent. For more information about the Deviations tab, see Using the Deviations tab on page 118.

The dashboard shows graphs of these deviation metrics:




For more information about these metrics, see Using the Most Dependent tab on page 125.


Double-click one of the top 10 most dependent operations to see the Investigator metrics for that operation.




Introscope SPM Busiest Operations dashboard

The SOA Performance Busiest Operations dashboard contains data viewers that show detailed information about the highest invocation rates per interval experienced by the server and client.

Use the SOA Performance Busiest Operations dashboard to see:

Top 10 Busiest client and server operations

Busiest Client Operations Responses Per Interval—total responses for all web services

Busiest Server Operations Responses Per Interval—total responses for all web services


Double-click one of the top 10 busiest operations to see the Investigator metrics for that operation.


SOA Performance Management tabs 105


SOA Performance Management tabsIn addition to the tabs supplied with Introscope Investigator, Introscope SPM provides tabs to help you triage your web services:

Using the Overview tabs, below

Using the Dependencies tabs on page 110

Using the Deviations tab on page 118

Using the Most Critical tab on page 124

Using the Most Dependent tab on page 125

Using the Errors tab on page 126

Using the Overview tabs

In addition to the Overview tab supplied with Introscope Investigator, Introscope SPM provides four web services-specific Overview tabs. This table provides brief descriptions of the Overview tabs based on their locations in the Introscope Investigator tree.

To view the Introscope and Introscope SPM Overview tabs:

1 Open the Introscope Investigator, click an agent node, then click the Overview tab in the Viewer pane.

You can view the application Overview alerts, which show the overall status of each application instrumented on the agent. This is the default Overview tab provided with Introscope.

This is the agent node. This is the Overview tab.



2 Click the WebServices node, and then click the Overview tab in the Viewer pane.

You can view two tables showing the agent client and server web service namespace metrics. When you select one of the metrics, a graph appears below the Client or Server list of metrics, showing details for the selected metric. Hover your cursor over any data point in the graph to view more information about the data point.

This is the WebServices node. Notice the namespace metrics for both the agent’s client and server.



3 Click the Client or Server node, and then click the Overview tab in the Viewer pane.

You can view a table showing the client or server namespace metrics. When you select one of the metrics, a graph appears below the Client or Server list of metrics, showing details for the selected metric. Hover your cursor over any data point in the graph to view more information about the data point.

» Note The data displayed in the graph at the bottom of Viewer pane is by default the Average Response Time. However, you can see other metric data by clicking the column header of that metric in the table. For example: to see Errors Per Interval metrics in the graph, click the column header of Errors Per Interval metric column.

Client node.

Server node.

Namespaces label.



4 Click a web service node, and then click the Overview tab in the Viewer pane.

You can view a table showing the operations metrics for the selected web service. When you select one of the metrics, a graph appears below the list of web service metrics, showing details for the selected metric. Hover your cursor over any data point in the graph to view more information about the data point.

This is a web service node.



5 Click an operation name (method) node, and then click the Overview tab in the Viewer pane.

For the selected operation (method), you can view a graph of the current activity level for each of these metrics:

Average Response Time

Concurrent Invocations

Errors Per Interval

Responses Per Interval

SOAP Faults Per Interval

Stall Count

Hover your cursor over any data point in the graph to view more information about the data point.

This is an operation node.



Using the Dependencies tabs

Introscope SPM provides metrics for monitoring web service operation health. They can be viewed in the Dependencies tab. These metrics list the most critical direct and indirect and most dependent direct and indirect counts for operations.

About direct and indirect operations

In a web service transaction, an operation can be located either upstream or downstream from other operations depending on where it sits in the dependency chain.

For example, if operation A calls B calls C, the transaction looks like this

A --> B --> C.

In this transaction,

A is upstream from C

C is downstream from A.

In a transaction consisting of multiple operations, direct operations are those that are immediately upstream or downstream from another operation. In the example above, Operations A and B are direct operations; so are B and C. On the SOA Dependency Map, direct operations are located immediately adjacent to each other. See Getting to know the SOA Dependency Map on page 146.

In a transaction consisting of multiple operations, indirect operations are either upstream or downstream from another operation, but are not directly adjacent to it.

For example if Operation A calls two other Operations (B and C), which are each calling operations themselves (B is calling D and C is calling E), then Operations D and E are indirect operations in relationship to Operation A. On the SOA Dependency Map, indirect operations not located adjacent to each other. See Getting to know the SOA Dependency Map on page 146.

T



About critical and dependent operations

Operations in a web service operation can be considered critical within the dependency chain or dependent on other operations in the dependency chain, or both critical and dependent.

About critical operations and their metrics

A critical operation is a web service operation that relies on the execution of upstream operations. Each of those upstream operations could be direct or indirect based on where they sit in the dependency chain. Introscope SPM provides two metrics about critical operations: the Critical Direct and Critical Indirect operations.

Critical Direct metric —The number of operations directly upstream from this critical operation.

Critical Indirect metric —The number of operations directly and indirectly upstream from this critical operation.

For example, if the Critical Indirect metric value for Operation A is 5, that means that five direct or indirect operations execute prior to Operation A executing.

About dependency operations and their metrics

A dependency operation is web service operation that relies on the execution of downstream operations. Each of those downstream operations could be indirect or direct based on where they sit in the dependency chain. Introscope SPM provides two metrics about dependency operations: the Dependency Direct and Dependency Indirect metric counts.

Dependency Direct metric —The number of operations directly downstream from this dependent operation.

Dependency Indirect metric —The number of operations directly and indirectly downstream from this dependent operation.

For example, if the Dependency Indirect metric value for Operation C is 8, that means that eight direct or indirect operations that are downstream from Operation C must complete in order for Operation A to execute.



Critical and Dependency Direct and Indirect metrics example

Let’s say that a server is calling four clients that each in turn calls one downstream server. If the client operations are all critical, then depending on where each operation sits in the dependency chain, some are critical or dependent, direct or indirect. Two examples are shown in this table and figure.

2. Introscope SPM displays these metrics for Test server:Critical Direct: 0Critical Indirect: 0Dependency Direct: 4

3. Introscope SPM displays these metrics for SayHello server 5:Critical Direct: 1Critical Indirect: 2Dependency Direct: 0Dependency Indirect: 0

1. SayHello client 1 is a critical operation in this dependency chain.



Here’s what the Introscope SPM metric values would be for the two operations shown above.

Operation name in figure Associated metrics

Test Server Direct Critical to noneIndirect Critical to noneMetric value for Critical Direct = 0Metric value for Critical Indirect = 0Direct Dependency on Hello Clients 1, 2, 3, 4Indirect Dependency on Hello Servers 5, 6, 7, 8Metric value for Dependency Direct = 4Metric value for Dependency Indirect = 8

SayHello Server 5 Direct Critical to Say Hello Client 1Indirect Critical to Test ServerMetric value for Critical Direct = 1Metric value for Critical Indirect = 2Direct Dependency on none Indirect Dependency on noneMetric value for Dependency Direct = 0Metric value for Dependency Indirect = 0



About the Dependencies tab

Introscope SPM provides Dependencies tabs in several locations in the Introscope Investigator. Use these tabs to view dependencies metrics for web services. This table lists brief descriptions of the Dependencies tabs based on their locations in the Introscope Investigator:

» Note If there are no dependencies that exist between clients, servers, or operations, then Introscope SPM cannot gather and display dependencies metrics in the Introscope SPM dashboards, Dependencies tab, or the SOA Dependency Map.

If your environment does have SOA dependencies, upon startup it can take Introscope SPM about 30 minutes to gather dependency data. During this period, no dependency data displays in the Introscope SPM dashboards, Dependencies tab, or the SOA Dependency Map. In addition, you may not see any deviation metrics for the first 70 minutes if you don't invoke any transactions that use web services within first 10 minutes after start up. This is because Introscope SPM refreshes the SOA Dependency Map once an hour. You can change the refresh rate by updating the com.wily.introscope.soa.deviation.dependency.refreshrate property value. See Introscope SPM EM extension properties on page 327.

Investigator tree node name What you see in the Dependencies tab

WebServices Dependencies tables listing the client and server web service namespaces, operations, and dependencies metrics that belong to the selected Agent application.

Client or Server Dependencies table listing the client or server web service namespaces, operations, and dependencies metrics that belong to the selected Agent application.

namespace

Note: The node name displayed is the name of web service in use by the Agent application client or server.

Dependencies table listing the operations and its associated dependency metrics that belong to the selected web service.



To use the Dependencies tab:

1 Click the WebServices node, and then click the Dependencies tab in the Viewer pane.

You can view two tables showing the Agent client and server web service namespace metrics.

Notice the dependencies metrics display for these operations. If there are multiple entries for an operation look at the first column to see the service to which it belongs.

Here’s the WebServices node.



2 Click the Client or Server node, and then click the Dependencies tab in the Viewer pane.

You can view a table showing the client or server namespace metrics.

Here’s the Client node.



3 Click a namspace node, and then click the Dependencies tab in the Viewer pane.

You can view a table showing the operations with critical and dependent metrics for the selected web service.

This is the namespace node.



Using the Deviations tab

Deviation is the measure of the dispersion of data about a mean value. A low deviation value indicates that the data is clustered around the mean, whereas a high deviation value indicates that the data is widely spread with significantly higher or lower figures than the mean.

Introscope SPM computes the deviation from the mean for web service operations metrics. The computation of the mean value is based on a rolling "n" day mean, which requires heavy CPU usage. To minimize the performance impact on the Enterprise Manager, Introscope SPM limits the number of operations used to calculate the Average Response Time Deviation, Errors Per Interval Deviation, and Responses Per Interval Deviation metrics.

By default, that number of operations that Introscope SPM uses to calculate the deviation metrics is 25. If you want to change this number value, you need to configure the com.wily.introscope.soa.deviation.count.per.metric property. See Introscope SPM EM extension properties on page 327.

For information about how deviation metrics are displayed in the Deviations dashboard, see Introscope SPM Most Critical Operations dashboard on page 101 and Introscope SPM Most Dependent Operations dashboard on page 102.

Introscope SPM provides three metrics for monitoring namespace and operation deviations:

Average Response Time Deviation—The deviation of the average response time, which includes the time spent processing the request on the application server and the time it takes for the browser to receive the HTML response and load associated images per interval.

Errors Per Interval Deviation—The deviation of the number of exceptions reported by JVM and HTTP error codes, which might include a 404 Page Not Found status reported by the HTTP server, a SQL exception, or a Java exception.

Responses Per Interval Deviation—The deviation of invocations finished within an interval; it is a measure of data throughput and thus of application performance.

Introscope SPM provides a series of Deviations tabs in several locations in the Introscope Investigator.

When viewing deviations metrics in the Deviations tabs, the deviation metric data is shown for each namespace and operation unless viewed at the namespace level. In this case, the deviation metric data displays only for the operation.



Use these tabs to view deviation metrics for web services. This table lists brief descriptions of the Deviations tabs based on their locations in the Introscope Investigator tree:

» Important Introscope SPM computes the deviation from the mean for web service operations metrics. The computation of the mean value is based on a rolling "n" day mean.

Therefore, out of the box deviation data is only available for operations. For deviations to be available at the namespace level, you must configure the deviation properties in the Enterprise Manager. For more information, see Introscope SPM EM extension configuration properties on page 325.

To use the Deviations tab:

» Note If there are no dependencies that exist between clients, servers, or operations, then Introscope SPM cannot gather and display dependencies metrics in the Introscope SPM dashboards, Deviations tab, or the SOA Dependency Map. If your environment does have SOA dependencies, upon startup, it can take Introscope SPM about 30 minutes to gather deviations data. During this period, no deviations data will display in the Introscope SPM dashboards, Deviations tab, or the SOA Dependency Map.

If your environment does have SOA dependencies, upon startup it can take Introscope SPM about 30 minutes to gather dependency data.

Investigator tree node name What you see in the Deviations tab

WebServices Deviations tables listing the client and server web service namespaces and deviations metrics that belong to the selected Agent application.

Client or Server Deviations table listing the client and server web service namespaces and deviations metrics that belong to the selected Agent application.

namespaces

Note: The node name displayed is the name of web service in use by the Agent application client or server.

Deviations table listing the operations and its deviation metrics that belong to the selected web service.



During this period, no dependency data displays in the Introscope SPM dashboards, Deviations tab, or the SOA Dependency Map. In addition, you may not see any deviation metrics for the first 70 minutes if you don't invoke any transactions that use web services within first 10 minutes after start up. This is because Introscope SPM refreshes the SOA Dependency Map once an hour. You can change the refresh rate by updating the com.wily.introscope.soa.deviation.dependency.refreshrate property value. See Introscope SPM EM extension properties on page 327.

1 Click the WebServices node, and then click the Deviations tab in the Viewer pane.

You can view two tables showing the Agent client and server web service namespace metrics.



The figure below displays metric data configured to show namespace instead of operation name. You can make such a configuration to the com.wily.introscope.soa.deviation.metric.expressionlist and com.wily.introscope.soa.deviation.metric.calledbackends properties in the IntroscopeEnterpriseManager.properties file. Introscope SPM out of the box displays deviation metrics for only for operations. For more information about the configuration required to display deviation metrics data, see Introscope SPM EM extension configuration properties on page 325.

Here’s the WebServices node.

Here’s the Deviations tab.This table displays the Agent client web service namespace metrics.

This table displays the Agent server web service namespace metrics.

Notice the deviations metrics that display for these namespaces.



1 Click the Client or Server node, and then click the Deviations tab in the Viewer pane.

You can view a table showing the client or server namespace metrics.

» Note The figure below displays metric data based on deviation properties configured in the IntroscopeEnterpriseManager.properties file. Introscope SPM out of the box displays deviation metrics for only for operations. For more information about the configuration required to display deviation metrics data, see Introscope SPM EM extension configuration properties on page 325.

Here’s the Client node.



2 Click a namspace node, and then click the Deviations tab in the Viewer pane.

You can view a table showing the operations with deviations metrics for the selected web service.

Here’s a namespace node.

Here’s the table displaying operations with Average Response Time Deviation, Errors Per Interval Deviation, and Responses Per Interval



Using the Most Critical tab

View the Most Critical tab only at the Web Services node to view the operations with the highest number of operations that depend on them. These operations are the most important potential points of failure and can be used for triage purposes, while the Most Critical Operations dashboard should be used to monitor deviation metrics. For more information about the dashboard, see Introscope SPM Most Critical Operations dashboard on page 101.

To use the Most Critical tab:

Click the WebServices node, and then click the Most Critical tab in the Viewer pane.

The most critical operations reported by the agent displays.



The top ten most critical operations display, as do these deviation metrics in graph format:




Using the Most Dependent tab

View the Most Dependent tab only at the Web Services node to view the operations with the highest number of dependencies on related operations. The table format can be used for triage purposes, while the Most Dependent Operations dashboard should be used to monitor deviation metrics. For more information about the dashboard, see Introscope SPM Most Dependent Operations dashboard on page 102.

To use the Most Dependent tab:

Click the WebServices node, and then click the Most Dependent tab in the Viewer pane.



The top ten most dependent operations for the agent display as do these deviation metrics in graph format:




Using the Errors tab

When ErrorDetector is installed with Introscope, the Introscope Investigator provides an Errors tab, where you can see a list of errors and error details for resources and components you select in the Investigator tree. For more information, see the Introscope Workstation User Guide. When viewing errors using Introscope SPM, you also get information about agent application client- and server-side SOAP faults.

To use the Errors tab to view web service errors and SOAP faults:

1 Open Introscope Investigator, click a Client or Server node, and then click the Errors tab in the Viewer pane.

The top pane of the Errors tab lists the time, description, and type of each error.



The bottom pane of the Errors tab, which is called the Error Snapshot, shows detailed information in red about the error selected in the list above. SOAP fault error messages have the prefix SOAP Fault at the beginning of the error message name.

3.

This is the Server node.

Notice that SOAP fault error messages include SOAP Fault at the beginning of the error message.

This is the Errors tab.



Viewing web service metrics in the InvestigatorYou can use the Introscope Investigator to find more detailed metric data about the client or server of a web service, including Blame stack information.

Using the Investigator, you can view metrics at the front-end or the back-end of your application. This capability, called Boundary Blame, is enabled by default. When Boundary Blame is enabled, only the front-end component and a back-end system are represented as blamed components in the Investigator tree, indicating whether a response time problem is internal to the application server (slow servlet) or external (slow back-end). Introscope SPM automatically detects web services calls to back-ends.

See the Introscope Java Agent Guide, Introscope .NET Agent Guide, and Introscope Workstation User Guide for more information about Boundary Blame.

About Introscope SPM metricsIntroscope supplies these five basic metrics for each monitored method or class:

Average Response Time (ms)


Errors Per Interval


Stall Count

In addition to the five Introscope basic metrics, Introscope SPM provides these metrics for each operation in a web service:

SOAP Faults Per Interval: how many SOAP Faults are produced or consumed by the SOAP platform that are recorded by the Introscope SPM Agent extension in a 15-second time slice

» Note For more information about Errors Per Interval, SOAP Faults Per Interval, and Errors displayed in ErrorDetector, see About error and SOAP fault metrics on page 129.

Critical Direct Top N

Critical Indirect Top N

Dependent Direct Top N

Dependent Indirect Top N

What deviation graphs you have to create (if appropriate)

There are various ways to view web service metrics in the Investigator:

Metrics per Introscope Agent (see page 132)

Metrics aggregated across all Introscope agents (see page 135)

Viewing web service metrics in the Investigator 129


About error and SOAP fault metrics

Though the Errors Per Interval, SOAP Faults Per Interval, and ErrorDetector errors all seem similar, they are in fact collecting and displaying quite different information. This table summarizes the more in-depth explanations given below.

This metric type Is monitored by To monitor and display Reported here

Errors Per Interval Introscope Java or .NET Agent

All Java and .NET exceptions generated by the monitored application

See Errors Per Interval metric on page 130.

Introscope SPM Investigator tree nodes, dashboards, tabs, and SOA Dependency Map

See the topics in this chapter and Using the SOA Dependency Map for triage on page 176.


Introscope SPM Agent extension

SOAP faults that are produced or consumed by the SOAP platform.

See SOAP Faults Per Interval metric on page 131.

Introscope SPM Investigator tree nodes, dashboards, tabs, and SOA Dependency Map

See the topics in this chapter and Using the SOA Dependency Map for triage on page 176.

Errors Per Interval ErrorDetector Errors for J2EE resources and .NET Framework resources.

See ErrorDetector Errors Per Interval metric on page 132.

ErrorDetector Live or Historical Error Viewer

See Viewing web service faults in ErrorDetector on page 204.



Errors Per Interval metric

The Errors Per Interval metrics provided with Introscope SPM (as opposed to ErrorDetector) allows you to monitor all errors and exceptions generated by the monitored application. The Errors Per Interval metric is monitored and generated by the Introscope Java or .NET Agent. Introscope SPM aggregates the Errors Per Interval metric as shown in this figure.

Here are the Errors Per Interval aggregated by Introscope SPM for a client machine.

Here’s the SOAP Faults Per Interval metric.

Viewing web service metrics in the Investigator 131


SOAP Faults Per Interval metric

The SOAP Faults Per Interval metric (see figure above) allows you to monitor SOAP faults that are that are produced or consumed by the SOAP platform. The SOAP Faults Per Interval metric is generated by Introscope SPM Agent extension.

SOAP faults occur when a web service returns a fault response rather than the normal response. This can happen, for example, as the result of code specifically returning a fault to indicate that the web service was unable to perform the requested action. Or when the SOAP engine automatically manufactures a fault in response to some error condition that is not explicitly handled by the web service code itself, such as an uncaught exception thrown from within the web service code.

The SOAP Faults Per Interval metric differs from the Errors Per Interval metric because though typically a SOAP fault is related to an error, this relationship is not necessarily a one to one ratio. Sometimes an error can be returned from a web service call as a SOAP fault, and the client code receiving the fault does not manufacture and throw an exception. Therefore the client Agent does not report an error, but does report a SOAP fault. In addition, sometimes a SOAP fault can be generated without an exception being thrown.

In addition the one to one ratio of errors to SOAP faults may change based on the way the web service application is written or on how the SOAP faults are generated by the application server based on the exception. A developer may choose to catch an exception and simply send a normal response message with a specific error code. Or a developer may choose between filtering out different exceptions and only send back SOAP faults based on the business logic.

The visibility of a SOAP fault depends on the business logic of the web service as well as the web service client. For example, let’s say a developer wants to generate an Invalid Parameter SOAP fault as a result of a particular parameter within the XML request object sent to a web service. There may not be an Errors per Interval metric generated in this case because there is no Java exception being thrown on the web service side.



ErrorDetector Errors Per Interval metric

ErrorDetector produces Errors Per Interval metrics for J2EE resources such as J2EE connectors, servlets, JTA, and HTTP as well as for .NET Framework resources such as ASP.NET pages, ADO.NET data sources, messaging queues, web mail, and enterprise services transactions.

You view these errors in Workstation using the ErrorDetector New Live Error Viewer or by querying a historical event. See Viewing web service faults in ErrorDetector on page 204 and the Introscope ErrorDetector Guide.

Viewing agent web service metricsOnce your applications are instrumented and providing data, you can view their performance metrics in Introscope Investigator.

» Note Introscope SPM relies on the agent extension being able to identify a web service operation from its invocation, either the remote procedure call itself, or from the transmitted SOAP message. With Axis web services that use the Message style of service, the Introscope SPM agent extension may not identify the web service operation on the client, or outgoing, side of the invocation. This affects the recorded metrics and behavior of Introscope SPM.

For example, client-side metrics may be reported under the Enterprise Manager node as shown where <endpoint> is the URL at which the service is located:

WebServices|Client|<endpoint>|UnknownOperationName

For example, what you see may look like this:

WebServices|Client|http://ca.travel.com

travel|UnknownOperationName

To view web service metrics per agent:

1 Open an Introscope Investigator window.

Viewing agent web service metrics 133


2 Expand the Introscope Agent node you’re interested in.

Web service metric data appears in the Investigator tree under the agent’s WebServices node. Under the WebServices node is a Client node and a Server node.

3 Expand the Client and Server nodes to see the web services listed under each.

4 Expand each web service to see its individual operations.

Client node Server node

WebServices nodeAgent node



About the web service name node

Under both server and client nodes, the first level shown is the web service name. In Introscope SPM, the web service name is based on the target namespace, which is a Uniform Resource Identifier (URI). There are two types of URIs: Uniform Resource Locator (URL) and Uniform Resource Name (URN). For example, in the figure below, the web service name is a URN.

» Note Some server-side implementations might only expose the URL, in which case the entire URL appears.

Web service method (called the operation name node).

Web service name node.



About the operation name node

One level below the web service name node is the operation name (method name). By expanding the Investigator tree to the method level, then viewing the metrics you can determine which exposed web service method is performing poorly.

These metrics appear for each operation in a web service:

Average Response Time (ms)


Errors Per Interval



Stall Count

See About Introscope SPM metrics on page 128.

To view web service metrics aggregated across all agents:

In order to view metric totals aggregated across all agents, you must have defined a virtual agent by configuring the agentclusters.xml file. See Configuring virtual agents for Introscope SPM on page 54.

1 In the Investigator, expand the Virtual Agent node defined in the agentclusters.xml configuration.

You can see all the web service metric totals across all agents.

2 Expand each web service name to see the metrics defined for each operation.



In the figure below, the WebServicesVirtualAgent node under the Introscope SuperDomain shows the aggregated web service server metrics.

WebServicesVirtualAgent node Here are the server metrics configured to be aggregated in the WebServicesVirtualAgent node.



To view web service alert states aggregated across all agents:

1 In the Investigator, expand the Custom Metric Host node, then the Alerts node below it.

2 Expand the SOA Performance Management <version> node.

1. Here’s the Custom Metrics Host node.

2. Here are the Alerts and SOA Performance Management <version> nodes.

3. When you choose an alert in the Investigator tree (see highlighted alert), you can then see its alert state. In this case, the Individual Server Average Response Time alert state is 3 or red.



Interpreting alert states

Under the Virtual Agent Alerts > web services node, you can see the alert state (not counts) for specific alert types, aggregated across all agents. These numeric values correspond to alert states:

0 = not reporting

1 = green

2 = yellow

3 = red

Alert state thresholds are set in Introscope. For more information, see the Introscope Configuration and Administration Guide.

Viewing Introscope SPM metric groupings and alertsYou can view Introscope SPM-specific metrics groupings and alerts in the Workstation Management Module Editor.

To view Introscope SPM-specific metrics groupings and alerts:

For information on creating metrics groupings and alerts, see the Introscope Workstation User Guide.

1 From any Workstation window, select Workstation > Management Module Editor.

2 In the Management Module Editor window, select the SOA Performance > Management <version> (*SuperDomain*) Management Module.

Viewing Introscope SPM metric groupings and alerts 139


3 The Introscope SPM-specific metrics groupings and alerts appear, as shown in this figure.

SOA Performance Management <version> node

SOA Performance Management alerts

SOA Performance Management metric groupings



Checking the health of your web servicesLooking at the Introscope SPM dashboards and Investigator gives you a quick view of the overall health of your web services. Here, you can see performance metrics for each operation in your web services, and run Transaction Traces to see the details, or component parts, of slow business transactions.

To check on the health of your web services:

Step 1 In the Introscope Workstation Console, look at the SOA Performance Management Overview dashboard.

This dashboard gives you an overview of the health of your web services. The alerts in the client and server health areas of the dashboard helps you determine how web services are functioning together. The Top 10 Slowest Client and Server services help to pinpoint services you may want to adjust for better performance. You can double-click a service in the Top 10 lists to open the Introscope Investigator and view more specific data.

Checking the health of your web services 141


Step 2 Double-click a tab at the top of the SOA Performance Management Overview dashboard to open other dashboards. Below you see the SOA Performance Management Client Health dashboard, which gives a more specific look at the health of your client.

You can hover your cursor over data points in the graphs to view specific information about that data point.



Step 3 From the SOA Performance Management Client Health dashboard, double-click one of the top 10 slowest operations to go to see it in the Investigator.

Double-clicking an operation on the dashboard takes you to its response time metric in the Investigator.

Checking the health of your web services 143


Step 4 You look at business transactions of interest in the Investigator by running a Transaction Trace Session. This shows you a set of transactions meeting your criteria, and for each transaction found, shows you the individual performance of each part of the transaction.

Using SOA Dependency Map to triage web service problems 145

CHAPTER 4

Using SOA Dependency Map to triage web service problems


Getting to know the SOA Dependency Map . . . . . . . . . . . 146

SOA Dependency Map components . . . . . . . . . . . . . 151

Setting up the SOA Dependency Map . . . . . . . . . . . . 159

Choosing a SOA Dependency Map content type . . . . . . . . . 161

Choosing a SOA Dependency Map view . . . . . . . . . . . . 166

Navigating the SOA Dependency Map . . . . . . . . . . . . 169

Using the SOA Dependency Map for triage . . . . . . . . . . . 176

SOA Dependency Map FAQs . . . . . . . . . . . . . . . 180

146 Using SOA Dependency Map to triage web service problems


Getting to know the SOA Dependency MapThe Introscope SPM SOA Dependency Map is an interactive graphical interface that allows you to view all the web services (referred to as services after this) in your SOA environment as well as their real-time dependency relationships and metrics.

If you manage a heterogeneous SOA environment made up of pure services or a mix of SOAP and non-SOAP services such as XML/HTTP or XML/JMS, your job is to monitor all these services and understand how they relate to one another. The SOA Dependency Map helps you visualize how all these different services are integrated as a single, interconnected whole.

» Note The Introscope SPM SOA Dependency Map displays only web services and does not represent process flows from OSB and WPS/WESB.

Monitoring your SOA environment requires you to be aware of services in the SOA as they are deployed, not as they were designed. You need to know in real time:

what services are actually deployed

when new services are deployed

how they are all interconnected.

With different groups in your organization developing and deploying services, no single architectural diagram can summarize the overall deployment of services. Even when there is a process in place to record deployed services, you may not be involved or informed. And even if you’re informed, the service repository list of services may or may not be up-to-date.

Even when services are in the registry, the dependencies and names of the services are static, and thus quickly become stale. One reason for this is when new applications are deployed, they may embed services that are then discovered by other developers. These hidden services then become mission-critical for other applications, yet remain unknown to your organization until they manifest in a critical problem.

Your problem is that even with these challenges, your organization expects you to be responsible for the health and availability of all services. You are successful when you can become aware of all services within the SOA environment in an automatic and timely manner—preferably in real-time or close to real-time. Introscope SPM allows you to fulfill your mission.

Getting to know the SOA Dependency Map 147


SOA Dependency Map Concepts

When you click any of these Investigator tree nodes, you can click the SOA Dependency Map tab to see the corresponding SOA Dependency Map.

Agent

Virtual agent

WebServices

WebServices > Client

WebServices > Server

individual services or operations under the client or server nodes.

The SOA Dependency Map displays three kinds of client-server dependency relationships in your SOA environment: between agents, web services, and web service operations.

If you are new to the SOA world, terms such as services, operations, faults, and dependencies may seem strange and unfamiliar because you are used to dealing with concepts like applications, transactions, front-ends, and back-ends. However, when using Introscope, you often work with agents and operation names. From examining these in the SOA Dependency Map, you’ll quickly learn how web services clients and servers relate to agents and operations. Briefly, front-ends and back-ends are similar to clients and servers, respectively.

Web services consist of one or more operations. A dependency exists when the implementation of one operation invokes a subsequent operation, often belonging to a different web service and running in a different application server. For example, a travel-agent web service that books a flight may invoke a web service belonging to an airline to place the reservation, and another web service belonging to a credit-card processor to charge the customer. There are dependencies between the travel-agent web service and the airline web service, and between the travel-agent web service and the credit-card processor web service.

Dependencies between web services often result from combining web services to form higher order-web services. To continue the example, a failure or performance problem with either of the constituent web services affects the behavior of the travel-agent web service. The SOA Dependency Map shows all of the web services in your SOA environment, as well as the graphical structure of web service operations with their dependencies and the performance of those dependent operations. This helps you understand the root-cause analysis for slow responses, faults, and so on. Knowledge and exploitation of the dependencies between web services is a useful aspect of root cause determination when you receive alerts.



Knowing where I am on the SOA Dependency Map

While the SOA Dependency Map is a map, it’s different from a paper map because what you see depends on two factors, in this order: the SOA Dependency Map content type you’ve chosen, then the Investigator tree node you’ve selected. This means the SOA Dependency Map context changes as you make decisions to view different data.

The SOA Dependency Map allows you to choose a filter, and then choose a limited view based on the filter results. By analogy, say you are using a browser-based map application that shows you every available transportation option in your metropolitan area. You tell the application to filter the view to show you only the airports; then you limit the view by zooming into a neighborhood. The resulting map would look very different if you had instead chosen to view the rail lines instead of the airports.

It’s important to remember that the SOA Dependency Map does not work separately from the Investigator tree. In fact, the interaction between the Investigator tree and the SOA Dependency Map provides a powerful and flexible tool. This is because the Investigator tree can provide a guide to the SOA Dependency Map, much the way an index of streets acts as a guide to a street map. Likewise, using the SOA Dependency Map, you can slowly expand a broad complex network of your web services. Then, click a map node to jump to a new tree node and repaint map from there. This allows you to click once to focus in on a particular Investigator or SOA Dependency Map node of interest and eliminate the clutter of uninteresting network branches.

Let’s examine these SOA Dependency Map context factors one at a time.

How the SOA Dependency Map content type affects what you see

The first factor that the SOA Dependency Map uses to determine what to display is the SOA Dependency Map content type: agent, service, or operation. If you have selected a content type, for example Services, and then click an Investigator tree node, you will see a SOA Dependency Map showing only the services on the agents that relate to that node. But if you then switch to Agents content type and back to Services again, you’ll see all the services on every agent that is associated with that node. What this means is that a switch of content type applies to everything on the SOA Dependency Map. When you chose the Agents content type, and then the Services content type, SOA Dependency Map interprets this request as you wanting to see all the services on all the currently displayed agents. For more information, see Choosing a SOA Dependency Map content type on page 161.

Getting to know the SOA Dependency Map 149


To continue the real-life map analogy from the section above, this would be like viewing a map of cities connected by trains based on Japan’s largest city, Tokyo, and its trains to other major cities. If you decided to zoom out to a view of earth’s major cities connected by train, then back in to a map of Japan, you’d see a map of all of Japan’s cities connected by train, rather than the map's focus being on Tokyo.

How the Introscope node affects what you see

The second factor that the SOA Dependency Map uses to determine what to display is the Introscope node that you have selected in the Investigator tree. The first SOA Dependency Map node you see and where you travel on the map from there is always based on the currently selected Investigator tree node. If you move around the map, the map displayed is always based on the Investigator tree node. If you select a different Investigator tree node, the associated SOA Dependency Map may look quite different.

For example, let’s say you are circumnavigating the earth in a spaceship and the porthole you're looking out of faces only one way. This means that the view you have is solely based on your position with respect to the earth. When you are over India, you look south toward Australia and admire the view. You take a nap and wake up over Mexico toward South America. The view of the world has changed entirely even though you are on the same flight axis.



What can I accomplish using SOA Dependency Map?

The SOA Dependency Map displays the SOA environment agents, services, and operations related to client and server web services. You can use the SOA Dependency Map to accomplish these important tasks:

I can accomplish this To help me To learn more see

Become aware of services in my SOA environment as deployed, not as designed

Get current accurate services information about my environment

Getting to know the SOA Dependency Map on page 146

Visually assess the global impact of problem services and drill down into the details of the problem within three to four mouse clicks

Research and resolve my SOA environment problems

Using the SOA Dependency Map for triage on page 176

Work with IT architects by viewing both the physical and logical view of my enterprise SOA environment

Plan and carry out enterprise-wide SOA initiatives

Choosing a SOA Dependency Map view on page 166

Create SOA Dependency Map images to share with others

Share the same view of service dependencies and problems with other collaborators in my organization who don’t use Introscope SPM

Outputting SOA Dependency Map images for sharing on page 177

View my SOA environment agents, services, and operations in the SOA Dependency Map

Understand what is going on in my SOA environment without needing an expert to interpret the service performance data

Using the SOA Dependency Map for triage on page 176

View the dependency relationships of my monitored agents, services, and operations in the SOA Dependency Map

Understand which agents, services, and operations are dependent on each other

Unrolling dependencies levels on page 169

Click on a map node and go to that component in the Investigator tree

Reorient myself on the Investigator tree and the SOA Dependency Map based on my current map node location

Jumping from a SOA Dependency Map node to the associated Investigator tree node on page 171

Start a Transaction Trace session on a problem service directly from the SOA Dependency Map

See all the Transaction Traces associated with that problem service without needing to set up a manual Transaction Trace

Starting a Transaction Trace session from SOA Dependency Map on page 180

SOA Dependency Map components 151


SOA Dependency Map componentsBecoming familiar with the SOA Dependency Map components can speed your understanding and use of its capabilities.

The SOA Dependency Map components highlighted in this diagram are described in the table below. Portions of two maps are used to show all the components.

1

3 2 4

13

149

5

18

15

19

611

128

107

16

17

20

21

22

24 25 262328

27



This legend table describes the SOA Dependency Map components and shows

their associated icons.

Icon or Image Map Component or Button Name

Description

1. SOA Dependency Map tab Click to display the SOA Dependency Map associated with the node selected on the Investigator tree.

2. View dropdown list Choose either a Physical or Logical representation of your web services environment.

3. Content type dropdown list If the Physical view is selected in the View dropdown, you can choose to display a map based on Operations, Services, or Agents content type.

If the Logical view is selected, you can choose to base your map on either Operations or Services.

The Custom Virtual Agent itself doesn't have a map, because it has no dependencies. However, you can choose to display a map of Custom Virtual Agent Services or Operations.

The default view is the Physical view, unless the selected node is a child of a Custom Virtual Agent.

The content type default depends on the selected node—for an agent, it is Agents; for a service, it is Services; and for an operation, it is Operations.

4. Primary Metric dropdown list

Choose one of the Introscope basic metrics to display for all operations and services shown on the map: Average Response Time Concurrent Invocations Errors Per Interval Faults Per Interval Stall Count

5. Client operation icon Client-side operation icon that displays on the SOA Dependency Map when you’ve chosen the Physical view.

6. Client operation name Operation name of the displayed client.

7. Primary Metric value Most current value of the metric selected in the Primary Metric dropdown list for the displayed item. Each each map item has its own icon, name, and primary metric value.

8. Tooltips button Select Introscope SPM metrics to display in tooltips in addition to displaying the Primary Metric data.



9. Unroll Dependencies button

Add a dependency (if one exists) for every lowest-level agent, service, or operation item.

If there are no additional dependencies, a message displays stating Additional dependencies not found.

10. Roll up Dependencies button

Remove all the lowest-level dependencies from the SOA Dependency Map.

11. Pan tool Drag the SOA Dependency Map around within the visible scrolling area.

12. Magnify a selected area Magnify a rectangular area of the SOA Dependency Map.

13. Zoom in and out Drag the mouse up and down to zoom in and out of the SOA Dependency Map.

This can substitute for not having a wheel on your mouse.

14. Fit to tab Fits the entire current view of SOA Dependency Map within the tab.

15 Save as image button Presents a dialog that lets you choose the image type and specify a file name for a graphical version of your current SOA Dependency Map.

16. Server operation icon Server-side operation icon that displays on the SOA Dependency Map when you’ve chosen the Physical view.

17. Server operation name

18. Agent name

19. Arrow showing one web service item calling another

Shows a web service item dependency.

20 Client service name

21 Server service icon Server-side service icon that displays on the SOA Dependency Map when you’ve chosen the Physical view.

22. Scroll bar


Description



23. Client Service icon Client-side service icon that displays on the SOA Dependency Map when you’ve chosen the Physical view.

24. Server Service icon Server-side service icon that displays on the SOA Dependency Map when you’ve chosen the Logical view.

25. Client service icon Client-side service icon that displays on the SOA Dependency Map when you’ve chosen the Logical view.

26. Client operation icon Client-side operation icon that displays on the SOA Dependency Map when you’ve chosen the Logical view.

27. Server operation icon Server-side operation icon that displays on the SOA Dependency Map when you’ve chosen the Logical view.

28. Agent icon Agent icon that displays on the SOA Dependency Map when you’ve chosen the Physical view Agent content type.


Description



How Investigator tree nodes relate to SOA Dependency Map nodes

When you select an Introscope tree node, that node is the starting point for the SOA Dependency Map. Initially you’ll see only the dependencies originating from that Introscope tree node displayed on the SOA Dependency Map.

Each box or item on the SOA Dependency Map is a map node. For example, a client-side operation icon is a map node, as is the client service box that contains this operation and perhaps other operations.

You can make a variety of choices to see more dependencies. For example, you can choose a different content type, such as Services or Operations, to see additional dependencies unrelated to those for the currently selected service or agent. Or you can you can right-click on a service in the SOA Dependency Map, and then choose Show All Operations to see all the operations related to that service.

SOA Dependency Map defaults

These are the Introscope SPM SOA Dependency Map defaults.

If you select a node in the Investigator tree, then the SOA Dependency Map displays the Physical view and content type associated with that web service item.

If you select an agent in the Investigator tree, the SOA Dependency Map displays the Physical view showing the agent map node.

If you select a service in the Investigator tree, the SOA Dependency Map displays the Physical view showing services map nodes.

If you select an operation in the Investigator tree, the SOA Dependency Map displays the Physical view showing operations map nodes.

If you select the WebServices node in the Investigator tree, then the SOA Dependency Map displays all the services or operations based on your view and content type choices.

When viewing the SOA Dependency Map using the Operations content type, you can see:

client map nodes are in green boxes

server map nodes are in blue boxes

Agents map nodes are in gray boxes.

These colored boxes represent the services and agents to which these operations belong.



If you select a client or server operation in the Investigator tree, then the SOA Dependency Map displays a partial dependency map for that specific client or server operation.

You’ll see the dependencies for the selected node plus one additional level of dependency by default when you select any node in the Investigator tree.

You can unroll the dependencies in two ways to see more operations:

Use the Add Dependencies button to unroll or add another full level of dependencies.

Right-click an individual item and choose Show Next Dependency from the menu.

How Introscope SPM creates the SOA Dependency Map

The SOA Dependency Map shows you both monitored web services and the dependency relationships between them. The Introscope SPM Agent extension sends source data about discovered web services and their dependencies to the Enterprise Manager. The Enterprise Manager then displays this data in the Workstation as the SOA Dependency Map.

The Introscope SPM Agent extension discovers all monitored web services, whether or not the web services have dependencies. In two cases the SOA Dependency Map displays a single standalone node without arrows indicating a relationship to another SOA Dependency Map item:

when an item has no dependencies

when an item has dependencies that are not monitored by Introscope.

For more information about standalone SOA Dependency Map nodes, see Choosing a SOA Dependency Map view on page 166.

As Introscope SPM discovers SOA dependencies, the dependencies are added to the SOA Dependency Map. Attempting to add a previously discovered dependency has no effect on the SOA Dependency Map.



» Note Introscope SPM requires time to discover all the web services in your environment and to collect data in order to display a complete SOA Dependency Map when you first install and deploy Introscope SPMand when you add a new web application to your environment. In these cases and others when data is not available, you’ll see a status message. For more informations, see I’m experiencing a problem viewing the SOA Dependency Map. What’s wrong? on page 183.

In addition, when Introscope SPM discovers a new dependency, the Enterprise Manager checks the SOA Dependency Map for possible logical equivalences. For information on Introscope SPM logical equivalence heuristics, see SOA Dependency Map FAQs on page 180.

About how the SOA Dependency Map is saved

The Enterprise Manager saves the SOA Dependency Map in the <EM_Home>/data/dependencymap directory. The Enterprise Manager saves two versions of the SOA Dependency Map file:

dependencymap.sav, which is the most recently saved SOA Dependency Map

dependencymap.bak, which is the previously saved SOA Dependency Map.

The Enterprise Manager saves the most currently discovered dependencies in the SOA Dependency Map to the dependencymap.sav file once an hour, as well as during the standard manual Enterprise Manager shutdown process. The Enterprise Manager holds currently discovered dependencies in the SOA Dependency Map memory cache between dependencymap.sav file saves. If the Enterprise Manager stops suddenly, the restart loads the most recent copy of the SOA Dependency Map, which could be up to one hour old.

The dependencymap.sav file contains all the discovered SOA Dependency Map dependencies. Upon Enterprise Manager start-up, the Enterprise Manager loads the SOA Dependency Map from the dependencymap.sav file so that Introscope SPM doesn’t have to rediscover the previously discovered dependencies. If the the dependencymap.sav file doesn’t exist, the SOA Dependency Map is created as described in SOA Dependency Map components on page 151.

If you want the Enterprise Manager to ignore the saved SOA Dependency Map at start up, then you must delete, move, or rename both the dependencymap.sav and dependencymap.bak files.

There are two cases when you may want the Enterprise Manager to ignore the saved SOA Dependency Map at startup:

When you want to change the enabling and disabling of logical equivalence heuristics, and therefore want to force the Enterprise Manager to rediscover all dependencies and apply the rules according to the new settings. For more



information, see SOA Dependency Map FAQs on page 180 and the logical equivalence heuristics properties in Introscope SPM EM extension configuration on page 326.

When an agent is disconnected, all map nodes and dependencies sourced from that agent are removed from the SOA Dependency Map. This might happen when your enterprise organization reconfigures its systems and changes the deployed applications.

However, the disconnected agent can only be handled if the Enterprise Manager is running. If the Enterprise Manager happens to be stopped, then the agent unmount is not detected and the map nodes and dependencies remain displayed within the SOA Dependency Map until they age expire which, by default, takes 60 days. You may prefer to not display out-of-date data in the SOA Dependency Map.

While the Enterprise Manager is stopped, the Workstation cannot be running. However, once the Enterprise Manager is restarted, then the Dependency Map displayed by the Workstation will still show the web services and their dependencies that belong to the disconnected agent. These are only removed from the map if the Enterprise Manager receives an unmount event for the agent.

To delete, move, or rename the saved SOA Dependency Map file:


» Note If you delete the saved SOA Dependency Map files while the Enterprise Manager is running, then Enterprise Manager recreates the files from the SOA Dependency Map at the next hourly interval.

2 Navigate to the <EM_Home>/data/dependencymap directory.

3 Find and delete, move, or rename the dependencymap.sav file.

4 Find and delete, move, or rename the dependencymap.bak file.

All former dependencies data is no longer available for display in the SOA Dependency Map.


Introscope SPM discovers all the current dependencies in the monitored SOAP-based applications and creates a new SOA Dependency Map.

Setting up the SOA Dependency Map 159


About SOA Dependency Map node aging and removal

The Enterprise Manager monitors the discovery of new agent, service, and operations dependencies. When a discovery is made, the map is updated. However, if the SOA Dependency Map node for an agent, service, or operation is not re-discovered over a period of time, it is removed from the SOA Dependency Map. Whenever removed web services are invoked and noticed again by the Enterprise Manager, then they are added again as SOA Dependency Map nodes.

You can configure when dependencies and the associated SOA Dependency Map nodes should be removed from the map by setting property values in the IntroscopeEnterpriseManager.properties file. See Introscope SPM EM extension properties on page 327.

Setting up the SOA Dependency MapOut-of-the box, Introscope SPM provides the SOA Dependency Map ready for you to view and use to monitor and triage your SOA environment. However, you can choose the map content to view based on what best serves your needs.

Setting Introscope SPM metrics to display on the SOA Dependency Map

You can view both Introscope basic and Introscope SPM metrics on the SOA Dependency Map. Under each SOA Dependency Map service and operation node, the Primary metric displays the Introscope basic metric you choose of primary interest to you. In addition, when you hover your mouse over any SOA Dependency Map agent, service, or operation node, tooltips display the Introscope SPM metrics you choose to view.

To change this SOA Dependency Map content See this topic

Introscope basic metric set at the SOA Dependency Map’s Primary metric

Setting Introscope SPM metrics to display on the SOA Dependency Map on page 159

Tooltips metrics Setting Introscope SPM metrics to display on the SOA Dependency Map on page 159

The level to view your SOA environment: agent or services or operations

Choosing a SOA Dependency Map content type on page 161

The representation of your SOA environment: physical or logical

Choosing a SOA Dependency Map view on page 166



» Note The metrics that the SOA Dependency Map displays for agents and services are the aggregated values of all the web service operations under that agent or service, not just the map nodes currently selected or displayed on the SOA Dependency Map.

For example, let's say you are examining a server-side service map node in the SOA Dependency Map. When you hover over the map node, tooltips display the metrics you've chosen to see. However, the server map node metrics can be due to client invocations that have a dependent client node as well as non-monitored clients, or clients that don't appear in the SOA Dependency Map. For example, a C++ client. All client invocations contribute to server-side metrics calculations.

Setting the SOA Dependency Map Primary Metric

You use the Primary Metric dropdown list to choose the Introscope basic metric to display on each client and server service and operation node.

To set the SOA Dependency Map Primary Metric:

1 Click the Primary Metric dropdown list in the SOA Dependency Map tool bar.

2 Select one of these Introscope basic metrics for display on every SOA Dependency Map client and server service and operation node:

Average Response Time


Errors per Interval


Stall count.

» Note The Average Response Time metric is the SOA Dependency Map default.

The SOA Dependency Map client and server agent, service, and operation nodes display the current metric value for the Introscope basic metric you selected.

In addition, the tooltips display additional information about the selected metric including min and max and count values, as appropriate for the metric and Investigator node you’ve selected.

Setting the SOA Dependency Map tooltips metrics

When you hover over an agent, service or operation map node on the SOA Dependency Map, you can choose to have tooltips display any or all of the Introscope SPM metrics. For more information about Introscope SPM metrics, see About Introscope SPM metrics on page 128. These metrics are in addition to additional data about the Primary Metric that is also displayed in tooltips.

Choosing a SOA Dependency Map content type 161


To set SOA Dependency Map tooltips metrics:

1 Click the Tooltips button in the SOA Dependency Map tool bar.

2 Select the Introscope SPM metrics to be displayed as SOA Dependency Map tooltips.

3 Click OK.

Based on the Investigator node you’ve selected, when you hover over a SOA Dependency Map client or server service or operation node, the SOA Dependency Map displays all or some of the selected metrics, depending on the metrics that the Enterprise Manager reports to that Investigator tree node.

For example, if you are monitoring your critical operations and set the SOA Dependency Map to display the associated Dependency Direct tooltips metric, you will see data for this metric display when you hover over an Investigator tree operation node. However, if you hover over an Investigator tree services node, you will not see Dependency Direct tooltips metric displayed. This is because services don’t generate data to calculate the Dependency Direct metric.

» Note Because the SOA Dependency Map always displays the Primary Metric data in tooltip, you cannot deselect the Primary Metric tooltip in the Choose Tootips Metrics dialog box.

» Tip If you set the SOA Dependency Map tooltips to display the Introscope SPM dependency and critical metrics, if you hover over a selected SOA Dependency Map node and these metrics display, this means that the selected component has upstream or downstream dependencies.

Choosing a SOA Dependency Map content typeThe SOA Dependency Map provides a way for you to easily view and move around a representation of your SOA environment as well as understand the context in which a problem emerges. If you notice an anomaly in several services, the SOA Dependency Map helps you to drill down to investigate without becoming disoriented.

Web services can run on web service clients or web service servers. Each client is associated with one server, and each client and server can run services and operations.

You can choose to view your SOA landscape from the viewpoint of one of three dependency relationships: agents, services, or operations. Being able to choose the best component relationship to examine in any particular situation helps you to drill down to specific subsets of the SOA Dependency Map as well as to specific services without losing your sense of where you are in the overall SOA topology.



It’s important to understand that the SOA Dependency Map displays first based on the content type you’ve chosen and then second based on the Investigator tree node you’ve chosen.

If you choose a content type—for example Services—then click an Investigator tree node, you will see a SOA Dependency Map showing the content type associated with the selected Investigator tree node. You will see only the services (on whatever agents) that relate to that Investigator node.

If you remain on the same Investigator tree node and choose another content type—for example Agents—the SOA Dependency Map displays all the agents with dependencies associated with the selected service.

If, after selecting Agents, you choose Services again, the SOA Dependency Map expands all the services on that service’s agent and shows them all. And if services on that agent are dependent on services on another agent, those services are shown as well. In short, a switch of content type applies to everything on the SOA Dependency Map, which in this case interprets moving from Agents to Services as asking to see all services on all the currently displayed agents.



This means you end up seeing a lot more services than you first saw, and the SOA Dependency Map looks different although you are on the same Investigator tree node.



About standalone map nodes

If you have selected a content type, you may see standalone items associated with that content type on the SOA Dependency Map. For example, if you choose Services then click an Investigator tree node, you may see a SOA Dependency Map showing both standalone and dependent services associated with the selected node.

If you change the content type, you no longer see standalone map nodes on the SOA Dependency Map. This is because after a content type change without an Investigator node change, the SOA Dependency Map displays only items having dependent relationships.



To continue the example above, if you change from the Services content type to Operations, only dependent operations associated with the selected Server Investigator tree node appear.

To set the SOA Dependency Map content type:

Click the Content Type dropdown list, and select either Agent, Service, or Operations.

The SOA Dependency Map refreshes and displays your SOA environment based on the content type that you selected.



Choosing a SOA Dependency Map viewSOA Dependency Map provides two ways of displaying the SOA components in your environment:

the physical view is a representation based on the physical location of services and operations, as detected by Introscope agents

the logical view is a representation based on groupings of similarly named services and operations, regardless of their physical location.

This example explains the difference between these views, and how each can be helpful when you are triaging a web service problem.

Imagine you are trying to analyze the root cause of a service problem and have triaged the problem to the specific service, when you discover that the service actually sits behind a load balancer. The load balancer distributes requests to five separate application servers. Finding the problem instance requires you to understand how performance varies between the physical instances. But to understand performance, you must understand the relationships between logical instances, what service is calling another service) and then on what physical instances these calls are being made. In other words, which instance of service A is calling which instance of service B.

In addition, you are interested in understanding how traffic to the service is distributed among its instances. For example, if a logical service is experiencing 100 invocations per minute, but is made up of five instances, then it’s critical for you to understand how those 100 invocations break down over each individual instance, and that 90 of the 100 invocations are actually going to a single instance.

The SOA Dependency Map allows you to toggle the View dropdown list to differentiate between the logical and physical instances of a service and determine how a problem in a specific instance may be affecting the overall performance of the logical service.

The default SOA Dependency Map view is the Physical view, unless you’ve selected a Virtual Agent child node. In that case, the default view is the Logical view.

To choose a SOA Dependency Map view:

Click the View dropdown list, and then select either Physical or Logical.

Choosing a SOA Dependency Map view 167


The SOA Dependency Map refreshes and displays your SOA environment based on the view that you selected. For example, if you had been looking at Operations in the Physical view, and then selected to the Logical view, the SOA Dependency Map refreshes and displays Operations based on a logical representation of the SOA Dependency Map.

Using SOA Dependency Map views and content types to solve your problems

Now that you understand how to change the SOA Dependency Map views and content type, you can use them together to solve your web services problems. This table shows what each combination helps you accomplish:

Choose this view And choose this content type

To view this on the SOA Dependency Map

Physical Agents The corresponding dependencies between the different physical agents involved in the monitored applications. When the transaction involves a single agent, the SOA Dependency Map displays that single agent’s node.

Physical or Logical Services A logical view aggregating multiple instances of the same service to display as a single service without association to the physical nodes where they are deployed.

Metrics shown are aggregated values among the physical instances.

Click any service node in the Investigator tree to get the Physical view Services content type.

If you then choose the Logical view, you see the Logical view Services content type. This merges the duplicated services into a single service (with the surrounding agent boxes are removed) and shows the logical dependency between different services.



Physical or Logical Operations A logical view aggregates and shows multiple instances of the same operation as a single operation without association to the physical nodes where they are deployed.

Metrics shown are aggregated values among physical instances.

Click any operation under a service node in the Investigator tree to get the Physical Operations view.

Change to the Logical view and Operations content type to get the logical view of the operations. This merges the duplicated operations into a single operation, the surrounding agent boxes are removed, and shows the logical dependency between different operations.

Choose this view And choose this content type

To view this on the SOA Dependency Map

Navigating the SOA Dependency Map 169


Navigating the SOA Dependency MapThis section discusses how you can tour your SOA environment using the SOA Dependency Map. Move between views, follow web service dependencies, and see current or historical metrics for specific client and server services and operations.

Unrolling dependencies levels

When you select an Investigator web services-related node, and then click the SOA Dependency Map tab, the SOA Dependency Map displays a single level of dependency relationship. If there is no additional layer of dependencies, you’ll see the message Additional dependencies not found.

Introscope SPM provides two ways to for the SOA Dependency Map to display additional dependency levels, which is also called unrolling.

To unroll dependencies levels:

Right-click any SOA Dependency Map node and select Show Next Dependency.

The SOA Dependency Map unrolls the next level of dependency only for the selected map node. For example, when a server-side operation is being unrolled, the next level of dependency that unrolls is the associated client-side operation.

Click the Show next dependencies button on the SOA Dependency Map tool bar.

The SOA Dependency Map unrolls dependencies for every lowest-level item in the map. So if an initial map node displays three dependencies, clicking this button adds a new level of dependencies for each of the three items.

Rolling up to hide dependencies

If you have unrolled many levels of agents, services, or operations dependencies, you may want to view fewer dependencies levels. Introscope SPM provides two ways to roll up and hide levels.

To roll up dependencies levels:

Right-click any SOA Dependency Map node and select Hide Dependencies.

The SOA Dependency Map rolls up all the dependency levels for the selected map node.

Click the Hide Dependencies button on the SOA Dependency Map tool bar.

The SOA Dependency Map rolls up the lowest-level of dependencies in the map.



Showing all operations for a service

If you have chosen to display the Operations content type, the SOA Dependency Map can be expanded to display all the operations for a specified service.

To show all operations for a service:

1 In the Investigator tree, select any individual operation of a service under the Client or Server node.

2 Click the SOA Dependency Map tab.

The SOA Dependency Map displays corresponding client or server operation along with its first-level dependencies within boxes representing the corresponding services and agents.

3 Select a service map node, then right-click, and choose Show all Operations.

The SOA Dependency Map displays all the operations for that client or server-side service.

Showing all services for an agent

If you have chosen to display the Agents content type, you can expand the SOA Dependency Map to display all the services for a specified agent.

To show all services for an agent:

1 In the Investigator tree, select any individual service under the Client or Server node.

2 Click the SOA Dependency Map tab.

The SOA Dependency Map displays the corresponding client or server service along with its first-level dependencies within one or more boxes representing the corresponding agents.

3 Select an associated agent in the SOA Dependency Map, then right-click, and choose Show all Services.

The SOA Dependency Map displays all the services for that agent.



Jumping from a SOA Dependency Map node to the associated Investigator tree node

If you are on a SOA Dependency Map node, when in the Physical view you can redraw the SOA Dependency Map based on the associated Investigator tree node.

If you have been slowly expanding the SOA Dependency Map one dependency level at a time, you may now be viewing a broad expanse of operations, services, or agents. If your organization has complex SOA networks, the map looks quite full, and you may not know exactly where you are. By using the Jump here in tree functionality, you can click on a map node and go to that component in the Investigator tree. This is like starting over to reorient yourself based on your current map node location.

In an analogy to working with a paper map, you can be working closely with one area of a map, and then look at a completely different area as you continue your planning or traveling. For example, imagine you are the navigator as your friend drives from London to Paris via the Euroshuttle that takes cars from England to France via the Chunnel train. Once you’ve crossed from England into France, you move the map on your lap to put Paris, not London as the center of your navigating attention. Similarly, you can jump to a new Investigator tree node to redraw the SOA Dependency Map.

To jump from a SOA Dependency Map node to the associated Investigator tree node:

When on a SOA Dependency Map node in Physical view, right-click and select Jump here in tree.

The selection in the Investigator tree moves to the new Investigator tree node, and this becomes the new focal point for the SOA Dependency Map.

Panning, zooming, and fitting the SOA Dependency Map

You can use four tools to move, enlarge, and refit the SOA Dependency Map around the tab view.

To move the SOA Dependency Map around the tab view:

1 Click the Pan tool button, and then click the SOA Dependency Map.

2 Drag the map within the tab to center and examine your areas of interest.

To magnify an area of the SOA Dependency Map:

1 Click the Magnify a selection tool (magnifying glass within a box), and then click the SOA Dependency Map.

2 Drag to select the rectangular area you want to magnify.



To zoom in and out of the SOA Dependency Map:

1 Click the Zoom in and out tool (magnifying glass with up/down arrows) button.

2 Roll your mouse forward and backward to zoom in and out on the SOA Dependency Map.

» Note Alternatively, you can use the mouse wheel to move up and down the SOA Dependency Map to see other areas interest.

To resize the SOA Dependency Map to fit in the tab:

Click the Fit to Tab tool (magnifying glass with +) button.

The SOA Dependency Map resizes to fit within the tab.

MOM SOA Dependency MapIf you have a clustered Introscope environment, the SOA Dependency Map displays the web services and discovered dependencies for the Collectors reporting to the MOM. In this figure, when the SOA Dependency Map is in the Physical Agent view, you can see that the MOM is connected to three Collectors. An agent on Collector 1 is calling an agent on Collector 2.

Here’s an agent on Collector 1 calling an agent on Collector 2.

Here’s the MOM connected to 3 Collectors.

Here’s the agent on Collector 2 being called.

Here’s Collector 1.





In this figure, the SOA Dependency Map in the Physical Services view shows services on a Collector 2 agent that have dependencies on a Collector 1 agent.

» Note The SOA Dependency Map data is saved only on Collectors. The MOM receives its data from the Collectors, and does not save any SOA Dependency Map data. See About how the SOA Dependency Map is saved on page 157.

Here’s the MOM.

Here is a service from a Collector 2 agent calling a service on a Collector 1 agent.





Reloading SOA Dependency Map upon discovery of new services and operations

You can update the SOA Dependency Map when the Introscope SPM Agent extension discovers new web services or operations and sends the data to the Enterprise Manager. The Enterprise Manager sends the data to the Workstation for display on the SOA Dependency Map.

To reload the SOA Dependency Map:

1 Notice the Available data has changed message when it appears below the SOA Dependency Map tool bar.

This message appears when the Introscope SPM Agent extension has discovered one or more new web services or operations and has sent the data to the Enterprise Manager. The Enterprise Manager then notifies the Workstation that this data is ready for display on the SOA Dependency Map.

When you click the Click here link, the SOA Dependency Map reloads and displays the newly discovered services and operations.

The SOA Dependency Map is displaying three sets of discovered client and server services when the Available data has changed message appears.



2 Click Click here to reload the dependencies in the SOA Dependency Map and view the new web services or operations and metrics.

The Workstation loads the newly discovered web service or operation and its metrics on the SOA Dependency Map.

After the SOA Dependency Map reloads, the view changes to the default SOA Dependency Map view associated with the Investigator tree node you clicked last.

For example, let’s say you open a new Investigator window and click the WebServices tree node, and then click the SOA Dependency Map tab to view the discovered dependencies. You see the Physical Services view, which is the default view for the WebServices tree node. You then decide to change to the Physical Operations view. If the Available data has changed message appears and you click Click here, the SOA Dependency Map reloads and displays the Physical Services view, which is the default view for the WebServices tree node you began on.

Notice that the Available data has changed message no longer displays because the SOA Dependency Map now displays all of the discovered services and operations.

After the SOA Dependency Map reloads, it displays four sets of discovered client and server services.



However, if you had clicked the WebServices tree node, and then clicked an Agent1 tree node, you’d see the default view for the Agent1 node, which is the Physical Agents view. You again decide to change to the Physical Operations view. If the New Available Data message then appears and you click Click here, the SOA Dependency Map reloads and displays the Physical Agents view, which is the default view for the Agent1 tree node you last clicked.

Using the SOA Dependency Map for triageHere are two scenarios that illustrate how you can use the SOA Dependency Map to rapidly handle your SOA environment problems.

Scenario 1

The Investigator tree organizes metrics by their physical location, while the SOA Dependency Map allows you to view a key metric as business transactions flow through the system from location to location.

If a client and a server are on different Introscope agents, then their performance metrics are in completely different locations in the Investigator tree. However, on the SOA Dependency Map, the client and server, along with their key performance metrics, are shown on linked SOA Dependency Map nodes. This is useful for triage purposes.

For example, if a client has a much longer average response time than the linked server, then that suggests there is some kind of network performance problem.

Similarly, if a server has a much longer average response time than a linked web client, then that suggests a performance problem in the components between the server front-end and the client back-end.

Using the SOA Dependency Map for triage 177


Scenario 2

When triaging a high-priority problem, you must rapidly understand what is going on in your SOA environment without having an expert to interpret the service performance data.

Suppose you have received an alert notification fromIntroscope SPM, and five critical services are experiencing unacceptably long response times. You must investigate and determine how to fix the problem as quickly as possible.

First you must understand the scope of the problem and what’s affected. To do that, you must understand service dependencies and locate transaction bottlenecks quickly. The problem is that in a complex environment with dozens of critical services, most of them reporting metrics, it's very difficult to determine dependencies and bottlenecks quickly, even if your organization has set up key custom dashboards. Generally, finding affected services requires you to drill down through many branches of the Introscope tree metrics.

Compounding your challenge is that your key collaborators, such as the enterprise architect, aren’t Introscope experts. They can’t rapidly understand metrics and dashboards, so that you must spend several minutes explaining to the enterprise application architect what the metrics mean.

Using Introscope SPM and the SOA Dependency Map, you can visually assess the global impact of problem services, drill down into the details of the problem within three to four mouse clicks, and have other IT collaborators rapidly understand the performance information you are presenting.

Outputting SOA Dependency Map images for sharing

You can output images of the SOA Dependency Map in a variety of formats to share with others.

In reporting and discussing a problem, you must collaborate with colleagues unfamiliar with Introscope SPM and SOA terms to effectively resolve problems. For example, if you are responding to an alert, you may work with your organization's enterprise architect and lead developers from a number of key services in order to resolve an application problem. These other people are not Introscope SPM users and can’t install any CA Wily Technology software on their local machines due to IT restrictions.

These limitations prevent you from sharing valuable information such as graphical views of services with your colleagues who need to be able to see the same view that you do. Resorting to screenshots and print-outs is a slow and an inconvenient way to research and communicate a problem issue.



By sending an image of the SOA Dependency Map at the agent, service, or operation view at any magnification allows you to share the same view of service dependencies and problems with other collaborators in your organization who don’t run Introscope SPM.

To output SOA Dependency Map images:

1 Click the Save as Image button.

The Export Image dialog box appears.

2 Choose the settings for the output file from the descriptions in this table.

Choose this To set this

Type The output file type.

Save as JPEG, GIF, PDF, PNG, or SVG.

Filename The destination path and file name for the output image file.

Image Content The part of the SOA Dependency Map you choose to save in the image file. Visible Window—Saves only the SOA Dependency Map that

is visible in the current window even if the SOA Dependency Map contains more content.

For example, if the SOA Dependency Map currently displays 100 nodes, but you have zoomed in to view only 10 nodes, Introscope SPM creates a zoomed image of only those 10 nodes.

Note: You must choose the size Current Zoom Level in order to choose Visible Window Only.

Draw Grid—This choice is not enabled. Selected Objects Only—Saves only the object that you

selected in the SOA Dependency Map.

For example, if you select a client web service in the SOA Dependency Map then choose Selected Objects Only, Introscope SPM creates an image of that client web service only.

Note: You can use the Actual size setting of the Size property to save the entire SOA Dependency Map in its default size, regardless of the zoom level.

Using the SOA Dependency Map for triage 179


3 Click OK.

Introscope SPM creates the SOA Dependency Map image and saves it to your specified location.

Disconnected agents are grayed out

When an agent is disconnected from an Enterprise Manager, the corresponding SOA Dependency Map nodes become inactive (grayed out). When an agent is unmounted from the Workstation or auto-unmounted by the Enterprise Manager, all the web services monitored by that agent are removed from the SOA Dependency Map, as well as the dependencies that start from or end with a removed web service. When the agent is remounted to the Workstation, the SOA Dependency Map rediscovers all the dependencies from that agent.

How renaming an agent updates the SOA Dependency Map

If you rename an agent in IntroscopeAgent.profile and restart the managed application, you’ll see the following:

new agent is displayed on the SOA Dependency Map. In addition, any new agent, web service, or operations dependencies that are discovered based on the new agent are added to the SOA Dependency Map under the new agent.

SOA Dependency Map nodes from the unmounted agent are removed from the SOA Dependency Map. This is because the Introscope SPM Agent extension is

Image Characteristics

Used to set the image quality and file size.

Slide the slider bar or pick a number from 1 to 100, where 100 is the best quality to choose the image quality for the image. The higher the quality image, the larger the saved image file size.

Size Choose the size of the Output content: Current Zoom Level—If you have zoomed in on an area of

the SOA Dependency Map, the image shows the zoomed in area.Use this in conjunction with the Visible Window Only Image Content choice.

Actual Size—The image shows the entire SOA Dependency Map. In the case of a larger map, it does not shrink the SOA Dependency Map image to fit in the window.

Fit in Canvas—The image shows the entire SOA Dependency Map. In the case of a large map, shrinks the SOA Dependency Map image to fit in the window.

Custom—You choose the image width and height settings in pixels.

Choose this To set this



no longer reporting data from the unmounted agent to the Enterprise Manager.

Starting a Transaction Trace session from SOA Dependency Map

You can start a Transaction Trace session directly from a map node. This allows you to quickly get from a high-level service view or map node directly to a detailed view of the actual transactions that pass through that service.

For example, let’s say you are trying to resolve a problem in a particular service that you noticed due to a red alert on the Introscope SPM dashboards. Because this problem service is used by a critical business transaction, it’s important for you to view those transactions as quickly as possible.

Instead of having to go to the Transaction Trace viewer, enter filter criteria, and manually kick off a Transaction Trace session, you can save time by kicking off a Transaction Trace session directly from the SOA Dependency Map.

To start a Transaction Trace session from a map node:

Right-click any map node and select Launch Transaction Trace.

Introscope SPM launches a Transaction Trace session showing all the related transactions associated with the selected map node. See About Introscope SPM cross-process transaction tracing on page 186.

SOA Dependency Map FAQsHere are some frequently-asked questions about the SOA Dependency Map.

FAQ Answer

Can I go back to a previous SOA Dependency Map? No. The SOA Dependency Map always reflects the current dependencies between the monitored web services. However, because it’s likely your organization will deploy, modify, or remove applications in a production environment only occasionally, the SOA Dependency Map structure should remain fairly static.

Where does the SOA Dependency Map get its information?

Introscope agents monitor the execution of the web services and transmit information about the sequence of calls to the Enterprise Manager. Cross-process correlation information is used to track the sequence of calls across multiple processes. The Enterprise Manager discovers the web service dependencies from the received sequences of web service invocations.

SOA Dependency Map FAQs 181


What problems can I find and fix using the SOA Dependency Map?

The SOA Dependency Map helps you to visualize the dependency relationships between the web services and shows where a specific web service may be used by many other web services.

The SOA Dependency Map helps you identify which component is performing poorly within a chain of web service calls. The inclusion of both client-side web services and server-side web services can highlight the contribution of network performance to a problem.

Can I filter SOA Dependency Map components? Not directly. However, you can use the Investigator tree to limit the scope of the displayed SOA Dependency Map. Choosing a specific agent, service, or operation in the Investigator tree, allows you to unroll the SOA Dependency Map based on that tree node. Within the SOA Dependency Map, you can select a map node and jump to the associated Investigator tree node. This allows you to quickly view the SOA Dependency Map based on a brand new tree node.

What happens when I add a service? How is it added to the map, and how fast will I see it on the SOA Dependency Map?

Newly added services are detected by the agent monitoring the application server hosting the newly deployed service. Details of the web service calls are transmitted to the Enterprise Manager, which adds any previously unknown services to the SOA Dependency Map, including any newly discovered dependencies on already known services.

The Workstation checks to see if the SOA Dependency Map has changed once every 15 seconds. If the SOA Dependency Map has changed, the Enterprise Manager sends new map data to the Workstation and updates the SOA Dependency Map metric values.

You won’t see revised SOA Dependency Map instantly, because it takes time for data about a newly added web services to work its way through the system. However, it should not take longer than a few minutes if you are running Introscope on a standalone Enterprise Manager. It may take longer if you are running Introscope on a cluster.

FAQ Answer



Can I bookmark a SOA Dependency Map? It is not currently possible to bookmark a SOA Dependency Map, however, the web services and their operations displayed in the Investigator tree can be considered as a whole series of bookmarks. Choosing a web service or its operation in the Investigator tree limits the scope of the SOA Dependency Map to the selected component and the components that it immediately depends upon. The SOA Dependency Map can be tailored by changing the view or expanding/collapsing.

Can I save a live map and return to it later? No. However, you can save a current map as an image. See Outputting SOA Dependency Map images for sharing on page 177.

I couldn’t find an agent, service, or operation that I was looking for. How do I find it?

Locate the desired agent, service, or operation in the Investigator tree, select that tree node, and then click the SOA Dependency Map tab. To discover more agents, services, or operations that the selected item depends upon, use the Add and Hide Dependencies buttons.

Also, by switching back and forth between the content types (Agents, Services, Operations), you can often notice sibling items. For example, other operations belonging to the same service. For example, select an operation, switch to Services content type, and then back to the Operations content type. This results in the SOA Dependency Map displaying all the operations belonging to that service. A similar technique works for all the services belonging to an agent. The usefulness of particular views varies according to the nature and complexity of a SOA.

FAQ Answer

SOA Dependency Map FAQs 183


I’m experiencing a problem viewing the SOA Dependency Map. What’s wrong?

If the SOA Dependency Map is empty in the SOA Dependency Map tab, but web service metrics are showing up in the Investigator tree, it could be for the following reasons: when the SOA Dependency Map is first

installed and in some other cases, it hasn't had a chance to collect data on everything yet. The Introscope SPM needs the web services applications to be in use and running for a while to collect data on all the nodes.

Services and operations that haven’t been called (thus are not in use), do not display on the map until they are called. For more information, see Reloading SOA Dependency Map upon discovery of new services and operations on page 174.

an Introscope agent cache flush has just taken place, removing all web services and dependency data. The Introscope SPM needs the web services applications to be running for a while to collect data on all the nodes.

the mapping tracers have become disabled in the agent's profile. Ensure that the IntroscopeAgent.profile file contains the property com.wily.introscope.agent.transactiontrace.boundaryTracing.enable and it is not set to False.

If the SOA Dependency Map is present but incomplete—that is, it contains some web services but not all—it could be because: the missing web services are running on an

application server that is not monitored by an Introscope agent.

you changed the name of the agent, resulting in no data for the associated map nodes. Introscope SPM needs some time to collect the data to display the new agent map nodes.

the missing web services are implemented on an unsupported platform or an unsupported SOAP engine.

FAQ Answer



About Introscope SPM logical equivalenceIntroscope SPM provides three heuristics for determining logical equivalence. For information about the properties used to configure Introscope SPM heuristics, see Introscope SPM EM extension configuration on page 326.

If your environment uses logical equivalence, you should understand how CA Wily SOA Performance Management defines client-side and server-side equivalence:

For a client-side web service, if a client-side web service depends on more than one server-side web service, then all of the server-side web services must be logically equivalent.

For a server-side web service, if a server-side web service is depended upon by more than one client-side web service, then all of the client-side web services must be logically equivalent.

For name matching, when two physical web service operations have the same metric path after deletion of the agent specifier, those operations are considered as logically equivalent.

Using Transaction Tracing to triage web service problems 185

CHAPTER 5

Using Transaction Tracing to triage web service problems

Introscope SPM enables you to monitor web services by viewing web service-related metrics in Introscope. This chapter discusses using the Introscope dashboards and Investigator to view and interpret web service metrics.


About Introscope SPM cross-process transaction tracing . . . . . . 186

Viewing correlated events using Transaction Tracer . . . . . . . . 201

Viewing web service data with Transaction Tracer . . . . . . . . 203

Viewing web service faults in ErrorDetector . . . . . . . . . . 204

186 Using Transaction Tracing to triage web service problems


About Introscope SPM cross-process transaction tracing

In Introscope, cross-process transaction tracing is Transaction Tracer’s capability to trace synchronous transactions, for instance servlets to EJBs, across JVM and CLR boundaries for specific versions of WebSphere and WebLogic application servers.

In Introscope SPM, cross-process transaction tracing is expanded to cross JVM and CLR boundaries to and from any supported Java or .NET platform. This capability includes transactions crossing WebSphere, WebLogic, Axis, SAP NetWeaver, and .NET boundaries. Introscope SPM cross-process transaction tracing is enabled for HTTP, HTTPS, and JMS transport protocols.

Whether your environment consists of a homogeneous (for example WebSphere to WebSphere or Java to Java) or heterogeneous (for example WebLogic to SAP NetWeaver or Java to .NET) collection of web services platforms, a web services business transaction can be tracked across any combination of platforms as long as there is a Introscope SPM Agent extension present at every node that needs to be traced. This gives you the ability to drill down into the details of a transaction not just within a single JVM or CLR, but into a web service transaction that goes into the JVM or CLR in a separate node.

You do not have to perform any additional configuration or procedures to enable Introscope SPM cross-process transaction tracing, as this functionality is built into the product and is always operating.

» Note If you want to monitor .NET cross-process transactions, you must have configured the .NET Agent for cross-process tracing. The configuration is available in the Sample.exe.config file in the <Agent_Home> directory. For more information, see the Introscope .NET Agent Guide.

In addition to starting a Transaction Trace session from the Workstation console, you can also start a trace session directly from the SOA Dependency Map. See Starting a Transaction Trace session from SOA Dependency Map on page 180.

Introscope SPM provides the web service namespace and operation name in the Transaction Trace properties window. Namespace and operation name are different ways to identify a web service. You might use either a namespace or an operation name to gather information to help you triage or to identify problematic web services.

In a Transaction Trace, the operation name is the name of an operation, but sometimes makes sense only within the context of the namespace. The namespace can come from an application component that provides a set of operations that have names.

About Introscope SPM cross-process transaction tracing 187


In the example figure below, the operation name is makeReservation, which by itself provides little meaning because an airline, a theater, or a doctor's practice all could use applications having a makeReservation operation. However, the namespace of http://www.ca.com/wsu/travel/TravelAgent shows that this web service transaction is for a travel agency. This demonstrates how knowing the operation name and its context from the namespace helps you to decide on what action to take next in solving your application performance issue.

The namespace and operation name properties for the selected transaction component are here in the Properties section at the bottom of the Component Details pane.



Using cross-process transaction tracing to solve difficult problems

Here’s an example of how a cross-process Transaction Trace helps application support personnel identify and assess a difficult problem quickly and effectively. In the situation shown in the figure below, a six second (very long) transaction consisted of calls from a web service (A) to another web service (B) to a CICS mainframe back-end. Without the Introscope SPM cross-process Transaction Trace functionality, it would be very difficult to find the source of this problem. To the casual observer it appears that the problem is related to Web Service A because that’s the service that seems to be taking a long time. To the CICS mainframe team, their mainframe monitoring tools show that the CICS back-end is fine. CICS is performing its normal function of servicing a high volume of invocations in rapid succession. Therefore, finding the root cause of this slow transaction in this type of distributed environment can be difficult and frustrating.

However, using Introscope and Introscope SPM to view this Transaction Trace, the application support specialist can easily see that the reason for the large number of CICS invocations is very likely due to faulty programming logic, such as a nested loop, in Web Service B. From the Transaction Trace for Web Service B, it appears that the action of making a large number of calls to the CICS mainframe is responsible for the majority (5 seconds) of the entire transaction execution time.



After looking at this diagram, Application Support can go directly to the owner or developer of Web Service B with a request to perform an in-depth investigation.

1. Here’s Web Service A making calls to Web Service B.

2. Here’s the duration of Web Service B’s invocations to the CICS back-end (end point of transaction not shown in the trace because it’s not instrumented). This transaction takes 5000 ms or five seconds, and is the source of the problem.

3. Here are all of Web Service B’s many invocations to the CICS back-end.

Web Service A

Web Service B

Notice that all the calls in the entire transaction that includes Web Service A take 6000 ms or six seconds.



Following an Introscope SPM transaction

The process of carrying out and viewing a typical web services transaction monitored by Introscope SPM involves four steps.

» Note The following examples use simplified cross-process transactions and associated figures.

Step 1 A business process transaction includes calls to different JVMs or CLRs on a local or remote machine.

Step 2 Agents on the called JVMs or CLRs report the calls to the same Collector Enterprise Manager.

Step 3 You run a Transaction Trace and select the entire business process.

For example, the HotelEnquiry business process highlighted in the figure below is the starting point of the business transaction that calls three other web services: Hotel1.getQuote, Hotel2.getQuote, and Hotel3.getQuote.

2. Here’s the HotelEnquiry web service called in a sample travel application.

1. Start in the Transaction Trace Viewer’s Summary View.

3. See the three web services called by the HotelEnquiry web service.



Step 4 In the Transaction Tracer Viewer Summary view, you can see the separate calls, including all the JVMs and CLRs.

In this example, all calls are to and from a Java JVM, so this is a homogeneous Java to Java transaction trace.

Example: Java to Java cross-process transaction

The ClearingHouseService business process highlighted in the figure below is the starting point of the transaction that calls other web services. In this case, the ClearingHouseService is on a WebLogic 9 machine making calls to another WebLogic machine.

1. Here’s the ClearingHouseService making calls from a WebLogic 9.0 host machine (oct6506al-w2s-1).

3. Here are all the calls made in this transaction. This is a good example of a homogeneous cross-process web service transaction because the calls are WebLogic to WebLogic (Java to Java).

2. Here are the CheckingAccountService and CreditManagmentService on another WebLogic host machine (mokap01-xp) being called by the WebLogic 9.0 hosted ClearingHouseService.



By clicking the Trace View tab, Workstation displays the traces and trace times making up the ClearingHouseService business process.

1. Here’s the ClearingHouseService web service transaction shown in the Trace View.

2. There are four web services (in red list box above) called by the ClearingHouseService web service.

Note the transaction duration as the calls move across multiple WebLogic application nodes.



By clicking the Duration column heading, Workstation sorts the transactions by time length. Now all the web service transactions called by the ClearingHouse web service are listed together.

1. Here’s the Duration column, and the time-sorted transactions related to the ClearingHouse web service.

2. Here are the four web services called by the ClearingHouseService web service.

3 Here’s the sum of the transactions comprising the ClearingHouseService web service.



Example: Java to .NET cross-process transaction

The WASBookingService business process highlighted in the Transaction Trace Viewer Summary View in the figure below is the starting point of the transaction that calls other web services. In this case, the WASBookingService is on a WebSphere 6.1 machine making calls to a .NET machine.

2. Here are all the calls made in this transaction. This is a good example of a heterogeneous cross-process web service transaction because the calls are WebSphere to .NET (Java to .NET).

1. Here the WASBookingService on a WebSphere 6.1 machine (UNI6506-XP-1) is calling the LoginSite on a .NET machine (mokap01-xp).



By clicking the Trace View tab, Workstation displays the traces and trace times making up WASBookingService business process.

3. Here’s the sum of the transactions comprising the WasBookingService web service.

2. Here are the two transactions called by the WasBookingService web service (all shown in the red trace list box above).

1. Here’s the WasBookingService transaction shown in the Trace View.



Filtering Introscope SPM Transaction Traces

If you are trying to resolve a problem in a particular service that was surfaced by Introscope SPM dashboards and tabs, because this problem service is used by a critical business transaction, it’s critical for you to determine the problem root cause as quickly as possible. Introscope SPM allows you to filter on a web service namespace or operation name to help you do this.

The Introscope SPM transaction trace filter allows you to isolate transactions and focus only on those that are of interest to you. This adds functionality to the Introscope Transaction Trace Session dialog box, allowing you to filter through all the incoming transactions and display only the ones that pass the selected filter’s constraints. If you are seeing some issues with your services and suspect a particular service, the namespace filter allows you to filter for transactions with that namespace. Once you know the namespace, the operationname filter allows you to filter transactions for one or more specific operations to help you triage the issue.



To filter an Introscope SPM Transaction Trace session:

1 Click Workstation > New Transaction Trace Session.

The New Transaction Trace Session dialog box appears,

There may be variations as to the number of filters available if you have more CA Wily Introscope products installed. At the very least, the two filters shown in the figure below appear Introscope SPM. Each filter is controlled by a check box. The check box is used to activate that particular filter. The first two always appear, regardless of the number of CA Wily Introscope products installed.

Here is the Introscope SPM Transaction Trace filter filtering on an operation name.



2 Click the Introscope SPM filter check box (the third one in the dialog box) to activate or deactivate the Introscope SPM filter.

When the check box is selected, the filter components are activated. The third component (the value field) may or may not be activated, depending on the value of the operation in the filter.

3 Create a filter expression by selecting a field, an operation, entering a value, and selecting the case sensitivity option.

4 Click Add to add the filter to the list of defined filters.

From the list of defined filters you can choose a filter to set it as the filter to use, or you can use defined filters to build complex filters.

5 To activate a filter, select the filter and click the Set Filter button.

The previous set filter is replaced. Only one set filter is in effect at a time.

6 In the Run Session for field, enter the length of the Transaction Trace session.

7 In the Trace Agents section, select one or more agents for which to trace transactions:

8 Click OK to start the Transaction Trace session.

Transaction Trace results appear in the Transaction Trace Viewer window. For more information see Introscope Workstation User Guide and Following an Introscope SPM transaction on page 190.

Introscope SPM filtersThe fields of the Introscope SPM filter component are defined in the following section. Complex filters are described in Complex filters on page 200.

operationname (example: processTransfer)

Input an operation name you are interested in searching on. The values are case-sensitive and must reflect the exact spelling of the expected incoming field names. See the figure below step 1 on page 197.



namespace (example: ClearningHouse.demobank.ca.com)

Input a namespace you are interested in searching on. The values are case-sensitive and must reflect the exact spelling of the expected incoming field names.

Adding a filter

You can add a filter by defining it and clicking the Add button. When you add a filter, you are adding the filter to the list of available filters. You must take the further step of selecting the Introscope SPM filter and clicking the Set Filter button in order to designate that filter as the one to use.

Duplicates are not allowed. If a new filter is being added and it is identical to one that already exists, an error is displayed saying that it will not be allowed.

» Note Filter definitions are stored only after you click the OK button. Storing the filter definitions makes them available the next time the Transaction Trace Session dialog is opened. Clicking the OK button automatically stores the filters on a per-user basis. Each user has their own set of filters stored.

Removing a filter

You can remove a filter by selecting it and clicking the Remove button. Use Ctrl+click to make multiple selections. You can only remove a filter if it is not used as a component of another filter. For example, if filters f1 and f2 are used to create the combined AND filter defined as f1 AND f2, then filter f1 cannot be deleted until the AND filter has itself been deleted.

Here is the Introscope SPM Transaction Trace filter filtering on a namespace.



» Note You must click the OK button in order for the removed filter(s) to be permanently removed. While the filters are removed from the screen immediately after the Remove button is clicked, cancelling and restoring the dialog without having clicked the OK button brings them right back.

Setting a filter

You can set a filter by selecting it and clicking the Set Filter button. You can select only one filter at a time. If you want to use more than one filter, create a complex filter. When selected, the filter’s description appears in the Filter Text box below the list of filters. You must set a filter before clicking the OK button. When you click Set Filter, any previously set filters are replaced by the current filter.

Complex filters

You can create complex filters by combining one or more filters from the filter list using either the AND or the OR operator. The filters that you are combining must already exist in the list of defined filters. When you use the AND or the OR operator to join together two simple filter statements, a new filter is created and that filter can then be used as a filter by itself or as a building block for creating additional filters. So, to create the complex filter f1 contains s1 AND f2 contains s2 you first create the individual simple filters and then join them.

To create a complex filter:

1 Create the filter f1 contains s1.

2 Create the filter f2 contains s2.

3 Use Ctrl+click to select both filters in the filter list and then click AND.

The new complex filter f1 contains s1 AND f2 contains s2 now appears in the list. You can set this filter or use it to create other complex filters.

Using the AND operator means that the trace has to pass all components of the filter. For example, the filter f1 contains s1 AND f2 exists requires that an incoming trace passes both the f1 contains s1 constraint as well as f2 exists.

Using the OR operator means that the trace has to pass at least one of the components of the filter. For example, the filter f1 contains s1 OR f2 exists requires that an incoming trace passes either the f1 contains s1 constraint or f2 exists or both.

Viewing correlated events using Transaction Tracer 201


For example, you can filter on both operation name and namespace at the same time, as shown in this figure.

Viewing correlated events using Transaction TracerIf you are reviewing details about a Introscope SPM transaction, you can view the correlated events. This allows you to see whether there are web services on other processes or nodes that are called during the transaction.

To view correlated events using Transaction Tracer:

1 Open Workstation and run a Transaction Trace session.

For more information, see the Introscope Workstation User Guide.

2 Select a Transaction Trace from the list.

3 In the Transaction Trace window, select Trace> Correlated Events.

The Historical Query Viewer opens listing the correlated events, which are the web services on other processes or nodes that are part of the selected Transaction Trace.

Here is the Introscope SPM Transaction Trace filter filtering on both a namespace and an operation.



Here’s the Historical Query Viewer displaying the correlated events related to the transaction shown in the Trace View.

Here’s a transaction highlighted in the Trace View.

Viewing web service data with Transaction Tracer 203


Viewing web service data with Transaction TracerUsing Transaction Tracer, you can see a web service within a Transaction Trace. You can also run Transaction Traces against a web service endpoint.

To see business transactions related to web services:

1 With the Workstation open, select Workstation > Query Historical Events.

2 In the Query field, enter query information in one of these ways:

To query for any event containing web services, enter webservices

Enter the desired URL

3 Click Go.

The results show any business transactions or errors that contain web services information.

Click any row in the table to see the components in the Transaction Trace, and then click any component to see its details in the Component Details pane. From this information, you can determine which component in the web service is causing problems.

» Note When viewing a Transaction Trace session using Trace View, you can use the Ctrl key to select all transactions that are correlated to a specific transaction. Then click Trace > Save As to save the correlated transactions in an XML file. However, when you open the Time Range drop-down historical query viewer and load the saved XML file and use the Trace View to view the historical data, you may find that the Trace View has changed or does not display the traces. This is because the Time Range historical viewer is not able to display correlated transactions. In addition, in a live Transaction Trace session, the Trace View may vary with time as correlated data continues to be reported to Enterprise Manager.

To learn more about using Transaction Tracer and analyzing the information contained in the Transaction Trace Viewer, see the Introscope Workstation User Guide.



Viewing web service faults in ErrorDetectorBefore learning how to view errors and faults using the ErrorDetector Live or Historical Error Viewer in Introscope SPM, it’s helpful to understand the difference between an error and a thrown and caught exception.

About the difference between errors and exceptions

In Java, exceptions are the way to indicate to a calling method that an abnormal condition has occurred. When an exception occurs, it is said to be thrown. Often, these abnormal conditions are anticipated. In these cases, there is an exception handler that catches the thrown exception. A thrown and caught exception is an abnormal condition in the system that was resolved without negative impact to the system.

Errors can be more serious problems. A thrown exception can become an error if there are no exception handlers to deal with the specific exception. CA Wily has defined a set of criteria to describe serious errors, based on information contained in the J2EE and .NET specifications. The most common type of error is a thrown exception. Some examples of common errors are:

HTTP errors (404, 500, etc.)

SQL statement errors

network connectivity errors (time out errors)

back-end errors (e.g., can't send a message through

JMS, can't write a message to the message queue)

When ErrorDetector is run with Introscope SPM in addition to Introscope, Introscope SPM supplies to ErrorDetector SOAP fault information, including a SOAP Fault prefix to the Error Message.

Viewing web service faults in ErrorDetector 205


To view live errors:

Choose Workstation > New Live Error Viewer.

You see live errors coming in. Click any row to see details in the Error Snapshot in the bottom pane.

Notice that SOAP fault error messages include SOAP Fault in the error message content.



To view historical errors:

1 Choose Workstation > Query Historical Events.

2 In the Query field, enter:

type:errorsnapshot AND webservices

A table of results opens.

3 Click a row in the table in the top pane to see error details in the lower error snapshot pane. The error message appears in red.

For an error on the server side, you can see the root cause of the error in the red error message.

Notice that SOAP fault error messages include SOAP Fault in the error message content.

Viewing web service faults in ErrorDetector 207


On the client and server sides, you can see the root cause along with the SOAP fault exception.

SOAP fault error messages have the prefix SOAP Fault at the beginning of the red Error Message.

To learn more about using ErrorDetector and analyzing error information, see the Introscope ErrorDetector Guide.

Monitoring Oracle Service Bus (OSB) 209

CHAPTER 6

Monitoring Oracle Service Bus (OSB)

Introscope SPM enables you to monitor OSB components and view the service-related metrics in Introscope. This chapter discusses using the Introscope SPM OSB-specific dashboards and metrics to monitor your OSB environment.

Using Introscope SPM to monitor OSB . . . . . . . . . . . . 210

Viewing OSB metrics . . . . . . . . . . . . . . . . . . 211

Viewing OSB dashboards . . . . . . . . . . . . . . . . 230

Viewing and creating OSB metric groupings . . . . . . . . . . 241

Viewing and creating OSB alerts . . . . . . . . . . . . . . 242

About OSB cross-process transaction tracing . . . . . . . . . . 244

210 Monitoring Oracle Service Bus (OSB)


Using Introscope SPM to monitor OSBYou can view live data in the Investigator and Console to monitor the performance of OSB.

To view data in the Investigator and Console:

1 Ensure that your applications are instrumented and providing data.

2 Ensure that the Enterprise Manager is running.

3 Start the Workstation.

4 Log in to the Workstation.

5 Navigate to the Investigator.

Metrics that are specific to OSB appear under the OSB node. This figure shows the metrics collected by Introscope SPM.

6 Navigate to the Introscope Workstation Console.

Introscope SPM provides a number of pre-configured dashboards for displaying OSB performance metrics. See Viewing OSB dashboards on page 230.

Viewing OSB metrics 211


Viewing OSB metricsIntroscope SPM provides the metrics for the following components of OSB:

Business Services: Business services in OSB are definitions of enterprise web services for which the bus is a client. The external web services are implemented in and hosted by external systems. So the bus must know what interface to call, how to call, and what to expect as a result of a call. Business services model these interfaces so that the bus can invoke the required external services and interact with the external systems. A business service configuration includes its interface, transport settings, and security settings.

Introscope SPM monitors how business services interacts with the external systems and provides data about their overall health. The Investigator displays metrics for each business service under the OSB > BusinessServices node.

Pipelines: A pipeline is a named sequence of stages representing a non-branching, one-way processing path. Pipelines belong to one of the following categories:

Request pipelines that process the request path of the message flow.

Response pipelines that process the response path of the message flow.

Error pipelines that handle errors for stages and nodes in a message flow as well as errors at the level of the message flow or business service.

To implement the processing logic of a proxy service, request and response pipelines are paired together in pipeline pair nodes. These pipeline pair nodes can be combined with other nodes into a single-rooted tree structure to control overall flow.

Introscope SPM monitors how the request and response pipelines perform and provides data about their overall health. Investigator displays metrics for pipelines along with the proxy service to which they belong under the OSB > Pipelines node.

Proxy Services: Proxy services in OSB are definitions of intermediary web services that the service bus implements and hosts locally. The bus uses proxy services to route messages between business services such as enterprise web services and databases, and service clients such as presentation applications or other business services.

A proxy service configuration includes its interface, transport settings, security settings, and a message flow definition. The message flow definition defines the logic that determines how messages are handled as they flow through the proxy service.

Introscope SPM monitors how the performance of the proxy services and provides data about their overall health. Metrics for each proxy service are displayed in the Investigator under the OSB > ProxyServices node.



Transports: OSB includes support for several commonly used transport protocols. A transport provider manages the life cycle and runtime behavior of transport endpoints. Target endpoints are resources where messages originate or are targeted. The native providers in OSB let you configure proxy and business services that require these transport protocols. You can also create or install custom transport providers

Introscope SPM monitors the transport protocols and provides metrics for each. Investigator displays transport metrics as well as metrics for inbound and outbound endpoints under the OSB > Transports node.

UDDI: Universal Description, Discovery, and Integration (UDDI) is a platform-independent, XML-based registry for businesses worldwide to list themselves on the Internet. UDDI is an open industry initiative that enables businesses to publish service listings and discover each other and define how the services or software applications interact over the Internet.

OSB works with any UDDI registry that is compliant with UDDI version 3.0. You can

publish information about any proxy service to a registry. The registry may be based on Web Services Description Language (WSDL), SOAP, or XML.

inquire for specific services in a registry or list all services available. You can search on business entity, service name pattern, or both.

import business services from a registry.

Introscope SPM monitors the UDDI registries. The Investigator displays UDDI metrics for publish, import, and inquiry operations under the OSB > UDDI node.

XQueries: OSB uses the Oracle Data Services Platform implementation of the XQuery engine, which fully supports all of the language features that are described in the World Wide Web Consortium (W3C). Transformation maps describe the mapping between two data types. OSB supports data mapping using XQuery. You can create, parse, and execute the transformations.

Introscope SPM monitors the XQuery transformations for creating, parsing, and executing XQueries. Investigator displays metrics for creating, parsing, and executing XQueries under the OSB > XQueries node.



About OSB metrics

When you select a metric in the Investigator tree, the data for the metric is displayed in a graphical format in the Viewer pane on the right side of the page. The metrics that appear in the Investigator depend on the resources that your applications use.

The following standard Introscope metrics appear for each operation in OSB:

Average Response Time (ms): average time taken for executing or invoking a specific operation or action.

Concurrent Invocations: how many requests are going through at a given time (throughput).

Errors Per Interval: how many errors are recorded by the Introscope Agent by catching a Java or .NET exception in a 15-second time slice.

Responses Per Interval: the number of invocations that completed during a 15-second time slice.

Stall Count: how many operations, invocations, or calls are taking longer than 30 seconds in a 15-second time slice.

Viewing OSB tabs and metrics» Note The Introscope SPM SOA Dependency Map displays only web services

and does not represent process flows from OSB.

To view the OSB tab and metrics:

1 Click the OSB node.

In the Viewer pane, the Overview tab is active by default, and all the proxy services and business services that OSB is currently using are listed in their respective tables.

2 Double-click a proxy service or a business service to view all the associated metrics in a graphical format.

3 Expand the OSB node.

Under the OSB node are sub-nodes for Business Services, Pipelines, Proxy Services, Transports, UDDI, and XQueries. OSB metric data appears under these sub-nodes.

4 Expand the sub-nodes to see the individual operations and metrics listed under each.



This figure shows the Investigator metrics for OSB.



Viewing Business Services metrics

To view the Business Services metrics:

1 Click the OSB > BusinessServices node.

In the Viewer pane, the Overview tab is active by default and all the business services that OSB is currently using are listed in a table.

2 Click a business service and a corresponding metric to view the data for that metric in a graphical format.

3 Double-click a business service to view all the associated metrics in a graphical format.

4 Expand the BusinessServices node.

You can see all the business services listed under this node. The business services’ names appear as configured in OSB.

5 Expand all the business services to see the metrics listed for each.

This figure shows the Investigator metrics for business services.



» Note Introscope SPM provides only three metrics for business services: Average Response Time, Errors Per Interval, and Responses Per Interval. Stall Count and Concurrent Invocations metrics are relevant only if the transactions are of request-response type. Because business transactions are not of the request-response type, Stall Count and Concurrent Invocations metrics are not provided.

» Important Average Response Time for business services is based on the Business Service Execution Time.Business Service Execution Time = OSB Transport Time + Actual Service Execution Time + Network Lapse.

Viewing Pipelines metrics

To view the Pipelines metrics:

1 Click the OSB > Pipelines node.

In the Viewer pane, the Overview tab is active by default and all the pipeline components that OSB is currently using are listed in a table.

In the Investigator, the proxy services to which the pipelines belong are listed under the Pipelines node. The pipeline components are listed under the proxy services.

2 In the Viewer pane, click a pipeline component and a corresponding metric to view the data for that metric in a graphical format.

3 Double-click a pipeline component to view all the associated metrics in a graphical format.

4 You can also expand the Pipelines node, expand one of the proxy services nodes, and click a pipeline component to view data for all associated metrics in a graphical format.



This figure shows the Investigator metrics for Pipelines.

Viewing Proxy Services metrics

To view the Proxy Services metrics:

1 Click the OSB > ProxyServices node.

In the Viewer pane, the Overview tab is active by default and all the proxy services that OSB is currently using are listed in a table.

2 Click a proxy service and a corresponding metric to view the data for that metric in a graphical format.

a Double-click a proxy service to view all the associated metrics in a graphical format.

The request and response operations for the proxy service are listed in a table.

b Click the Request operation and a corresponding metric for the operation to view data for that metric in a graphical format.

c Click the Response operation and a corresponding metric for the operation to view data for that metric in a graphical format.

d Double-click the Request operation or expand a proxy service and click the Request operation.

Data for all the metrics for the Request operation are displayed in a graphical format.



e Double-click the Response operation or expand a proxy service and click the Response operation.

Data for all the metrics for the Response operation are displayed in a graphical format.

3 You can also expand the ProxyServices node in the Investigator tree.

» Note Metrics under OSB|ProxyServices|{proxyname} are aggregated metrics from the Request and Response sub-nodes. See About Proxy Service aggregated metrics on page 219.

a Expand all the proxy services to see the metrics listed for each.

b Expand the Request and Response sub-nodes to see the metrics listed for each.

For each proxy service, metrics under the Request sub-node are associated with processing the request from the corresponding proxy service. Metrics under the Response sub-node are associated with processing the response to the corresponding proxy service.

This figure shows the Investigator metrics for proxy services.



About Proxy Service aggregated metrics

Introscope SPM aggregates the five standard Introscope metrics for Proxy Services Requests and Responses, which are always asynchronous, under the OSB|ProxyServices|{proxyname} Investigator node. For example in this figure,

OSB|ProxyServices|LoanGateway1 has five standard Introscope metrics that are aggregated from the OSB|ProxyServices|LoanGateway1|Request and OSB|ProxyServices|LoanGateway1|Response sub-nodes.

Here are the aggregated metrics from the Request and Response sub-nodes for the LoanGateway1 proxy service.

Here’s the Request node for the LoanGateway1 proxy service.

Here’s the Response node for the LoanGateway1 proxy service.



Here are the terms used in the equations that Introscope SPM uses for generating the aggregated standard Introscope metric calculations below.

If Proxy1 has Request (Req) and Response (Res) metrics, then the aggregated metrics are calculated based on these equations:

ART(Proxy1) = [ART(Req) * Count(Req) + ART(Res) * Count(Res)] / [Max of Count(Req, Res)]

CI(Proxy1) = CI(Req) + CI(Res)

EPI(Proxy1) = EPI(Req) + EPI(Res)

RPI(Proxy1) = Max of [RPI(Req), RPI(Res)]

SC(Proxy1) = SC(Req) + SC(Res)

Viewing Transports metrics

To view the Transports metrics:

1 Click the OSB > Transports node.

In the Viewer pane, the Overview tab is active by default and all the transport types that OSB is currently using are listed in a table.

2 Click a transport type and a corresponding metric to view the data for that metric in a graphical format.

» Note Metrics under OSB|Transports|{transporttype} are aggregated metrics. See About Transports aggregated metrics on page 224.

3 Double-click a transport type or expand the Transports node and click a transport type.

Data for all the metrics for the selected transport type are displayed in a graphical format.

This term in the equation Means this

ART Average Response Time

CI Concurrent Invocations

EPI Errors Per Interval

RPI Responses Per Interval

SC Stall Count

Count Data count shown for each metric in the investigator

Req Request node

Res Response node



4 Expand a transport type node and click a sub-node for these transport types: InboundMessageContext, OutboundMessageContext, or TransportProvider.

TransportProvider, InboundMessageContext, OutboundMessageContext, and ColocatedMessageContext are interfaces used by OSB. The sendMessageAsync, send, close, getRequestPayload, getResponsePayload methods are defined in these interfaces.

» Note The ColocatedMessageContext sub-node appears in the Investigator tree based on the application you are using when a protocol transformation occurs within OSB. For example. when a proxy service calls another proxy within OSB.

The ColocatedMessageContext sub-node contain all the nodes that are available in the Inbound and Outbound endpoints.

In the Viewer pane, the Overview tab is active by default and all the methods that the transport type is currently using are listed in a table.

5 Click a method and a corresponding metric to view data for that metric in a graphical format.

6 Double-click a method or expand a sub-node for the transport type InboundMessageContext, OutboundMessageContext, or TransportProvider, and then click a method.

This method is responsible for...

sendMessageAsync sending messages to OutboundMessageContext.

send sending messages to an outside service.

close sending the response back to the client.

getRequestPayload getting the request message payload.

getResponsePayload getting the response message payload.



Data for all the metrics for the method are displayed in a graphical format. This figure shows the Investigator metrics for OSB transports.



1 Expand the Transports node and click Inbound or Outbound sub-nodes.

In the Viewer pane, the Overview tab is active by default and all the endpoints that the inbound and outbound endpoints currently use are listed in a table as shown in this figure.

2 Click an endpoint and a corresponding metric to view data for that metric in a graphical format.



3 Double-click an endpoint or expand an Inbound or Outbound endpoint node and click an endpoint. Data for all the metrics for the endpoint are displayed in a graphical format.

Fourteen OSB transport types are supported by Introscope SPM out of the box:

See OSB Transports I - Overview dashboard on page 236 and OSB Transports II - Overview dashboard on page 237 for details.

When ever a specific transport type is used, the transport type and metrics for it are displayed. If a custom transport type is used in OSB, the Java package name defined for that transport type is displayed in Investigator. For example, if the OSB Console uses the custom transport type com.bea.wli.sb.test.service, Investigator displays this as a transport type.

About Transports aggregated metrics

Introscope SPM aggregates the five standard Introscope metrics under each Transport type. For transports, all the sub-nodes and the associated methods are calculated for aggregation and are displayed under its corresponding transport type.

HTTP/HTTPS MQ

JMS WS

EJB JPD

FTP SB

Email DSP

SFTP File

Tuxedo Local



For example, in this figure you can see that

OSB|Transports|HTTP has five standard Introscope metrics that are aggregated from the methods of these sub-nodes:

HttpInboundMessageContext

HttpOutboundMessageContext

HttpTransportProvider

Here are the metrics used in the aggregation for the HTTP transport type.

Here are the aggregated metrics for the HTTP transport type.







Here are the equations used for generating the aggregated metric calculations.

If Transport type (Type1) has Class1(Method1) and Class2(Method2) metrics, then the aggregated blame point metrics are calculated based on these equations:

ART(Type1) = [ART(Method1) * Count(Method1) + ART(Method2) * Count(Method2)] / [Max of Count(Method1, Method2)]

CI(Type1) = CI(Method1) + CI(Method2)

EPI(Type1) = EPI(Method1) + EPI(Method2)

RPI(Type1) = Max of [RPI(Method1), RPI(Method2)]

SC(Type1) = SC(Method1) + SC(Method2)

This term in the equation Means this

ART Average Response Time

CI Concurrent Invocations

EPI Errors Per Interval

RPI Responses Per Interval

SC Stall Count

Count Data count shown for each metric in the investigator.

Class1, Class2 Correspond to HttpInboundMessageContext, HttpOutboundMessageContext, HttpTransportProvider and so on.

Method1, Method2 Correspond to getRequestPayload, sendMessageAsync, getResponsePayload and so on.

Type1 The transport type, for example HTTP, JMS, FTP, or SFTP



Viewing UDDI metrics» Note To view UDDI metrics, you must configure the AquaLogic Service

Registry. Then only UDDI metrics will display in Investigator under the OSB > UDDI node. AquaLogic Service Bus can interact with any UDDI 3.0 compliant registry including the AquaLogic Service Registry.

To view the UDDI metrics:

1 Click the OSB > UDDI node.

In the Viewer pane, the Overview tab is active by default and all the methods that UDDI registries are currently using are listed in a table.

2 Click a method and a corresponding metric for the method, to view the data for that metric in a graphical format.

3 Double-click a method to view data for all the metrics for the method.

4 Expand the UDDI node and click one of the sub-nodes for Inquiry, Import, or Publish operations.

In the Viewer pane, the Overview tab is active by default and all the UDDI registries and their corresponding methods are listed in a table.

The methods listed are those that are currently being used by Import, Inquiry, and Publish operations. The Inquiry operation is responsible for extracting information for the services that are registered in UDDI registries. The Import operation is responsible for importing the business services from UDDI registries. The Publish operation is responsible for either manually or automatically publishing the proxy services from OSB to UDDI registries.

5 Click a UDDI registry, its corresponding method, and a corresponding metric for the operation to view data for that metric in a graphical format.

6 Double-click a UDDI registry and its corresponding method to view data for all the metrics for the method in a graphical format.

The getBusinessServices method is responsible for extracting information for the services that are registered in UDDI registries. The importServices method is responsible for importing business services from UDDI registries. The manualPublishServices and autoPublishServices methods are responsible for manually and automatically publishing proxy services to UDDI registries.

7 You can also expand the UDDI node to see all the UDDI operations.

a Expand all the operations to see the methods listed for each.

b Expand all the methods to see the metrics listed for each.



This figure shows the Investigator metrics for UDDI registries.



Viewing XQueries metrics

To view the XQueries metrics:

1 Click the OSB > XQueries node.

In the Viewer pane, the Overview tab is active by default and all the methods that the XQueries transformations are currently using are listed in a table.

2 Click a method and a corresponding metric to view the data for that metric in a graphical format.

3 Double-click a method or expand the XQueries node and click a method name.

Data for all the metrics for the method are displayed in a graphical format.

Create, Parse, and Execute methods are listed for XQueries. Metrics for the create and parse methods are populated only once for each XQuery. Metrics for the execute method are populated with every execution of an XQuery expression or condition.

This figure shows the Investigator metrics for XQueries.



Viewing OSB dashboardsOSB dashboards combine and present application metrics in views that you can use to monitor your application environment. Dashboards aggregate data across all the deployed agents and deliver the in-depth performance information required for you to rapidly diagnose and resolve problems.

The OSB dashboards provide:

High-level application health and status views of the application.

At-a-glance notification of problems in the production application environment.

Data that enables you to quickly identify the problems.

Pre-defined navigation between high-level and drill-down performance information.

The installer for OSB places the Management Module jar OSB_ManagementModuleV<version>.jar file in the <EM_Home>/deploy directory. This Management Module provides ten pre-defined dashboards for OSB.

Dashboards are associated with alerts that show the overall health of the application. Each alert has a metric value:

Gray indicates that no data is available

Green indicates OK

Yellow indicates Caution

Red indicates Danger

To view dashboards:


2 Select one of the following dashboards from the drop-down list:

OSB Home

OSB Proxy Services - Overview

OSB Proxy Services - Details

OSB Business Services - Overview

OSB Pipelines - Overview

OSB Transports I - Overview

OSB Transports II - Overview

OSB Transport Endpoints - Overview

OSB XQuery - Overview

OSB UDDI - Overview

Viewing OSB dashboards 231


OSB Home Dashboard

When monitoring OSB, first view the OSB Home dashboard. It depicts an architectural overview of OSB, all the components involved in the bus, and the internal workflow.

Each component has alerts to show its overall health.

To view more information:

Double-click an alert associated with a component to open the component's dashboard. For example, click the Pipelines response times alert to go to the Pipelines - Overview dashboard.

Double-click a tab to navigate to the associated dashboard.



OSB Proxy Services - Overview dashboard

The dashboard shows:

Overall health of proxy services.

Alerts and graphs for Average Response Time, Errors Per Interval, and Stall counts.

Top 10 slowest proxy services.


Double-click a proxy service in the 10 Slowest Proxy Services chart to view its details in the Investigator.

Right-click a graph or an alert, click Links, and navigate to OSB Home or the corresponding alert in the Management Module.



OSB Proxy Services - Details dashboard


Overall health of request and response operations for proxy services.

Alerts for Average Response Time, Errors Per Interval, and Stall Counts.

Graphs for Average Response Time and Stall Counts.


Right-click a graph or an alert, click Links, and navigate to the corresponding alert in the Management Module.



OSB Business Services - Overview dashboard


Overall health of business services.

Alerts and graphs for Average Response Time and Errors Per Interval.

Top 10 slowest business services.


Double-click a business service in the 10 Slowest Business Services chart to view its details in the Investigator.




OSB Pipelines - Overview dashboard


Overall health of pipelines.

Alerts and graphs for Average Response Time, Errors Per Interval, and Stall Counts.

Top 10 slowest pipelines.


Double-click a pipeline in the 10 Slowest Pipelines chart to view its details in the Investigator.




OSB Transports I - Overview dashboard


Overall health of transports.

Alerts for Average Response Time, Errors Per Interval, and Stall Counts for all transport types.

Graphs for Average Response Times for HTTP/HTTPS, JMS, EJB, FTP, Email, and SFTP transport types.





OSB Transports II - Overview dashboard

The dashboard shows graphs for Average Response Times for Tuxedo, MQ, WS, JPD, SB, DSP, File, and Local transport types.


Right-click a graph, click Links, and navigate to the corresponding alert in the Management Module.



OSB Transports Endpoints - Overview dashboard


Overall health of inbound and outbound Endpoints for all transport types.

Graph for Average Response Times and alerts for Errors Per Interval and Stall Counts for all Inbound Services and Outbound Endpoints for all transport types.

Top 10 slowest Inbound Services.

Top 10 slowest Outbound Endpoints.



Double-click an inbound service or outbound endpoint in the chart that displays the Top 10 inbound services or outbound endpoints, respectively, to view its details in the Investigator.



OSB XQuery - Overview dashboard


Overall health of XQueries.

Alerts for Average Response Time, Errors Per Interval, and Stall Counts for Execute operations.

Graphs for Average Response Time, Errors Per Interval, and Stall Counts for Execute operations.

Graphs for Average Response Time and Errors Per Interval for Parse operations.



» Note Graphs for Parse do not have any associated alerts, so when you right-click Links, you will navigate to the corresponding metric grouping.



OSB UDDI - Overview dashboard


Overall health of UDDI registries.

Alerts and graphs for Average Response Time and Errors Per Interval for Import and Publish operations for the UDDI registries



Viewing and creating OSB metric groupings 241


Viewing and creating OSB metric groupings You can view OSB metric groupings using the Workstation Management Module Editor.

To view OSB metrics groupings across all agents:

1 In the Investigator, click Workstation > New Management Module Editor.

The Management Module Editor opens.

2 Expand the following nodes:

a *SuperDomain*.

b Management Modules.

c OSB_ManagementModule <version> (*Super Domain*).

3 Expand the Metric Groupings node to view all metric groupings for OSB.

4 Click a metric grouping to view it in the Viewer pane.

5 Click Elements > New Metric Grouping to create a new metric grouping based on the OSB Management Module.

For information about creating and defining metric groupings, see the Introscope Configuration and Administration Guide.

This figure shows the Investigator metric groupings in the Management Module Editor.



Viewing and creating OSB alertsYou can view the OSB alerts using the Workstation Management Module Editor as well as in Investigator.

To view OSB alerts using Management Module Editor:

1 In the Investigator, click Workstation > New Management Module Editor. The Management Module Editor opens.


a *SuperDomain*.


c OSB_ManagementModule <version> (*Super Domain*).

3 Expand the Alerts node to view all alerts for OSB.

4 Click an alert to view it in the Viewer pane.

5 Click Elements > New Alert to create a new alert.

For information about creating and defining alerts, see the Introscope Configuration and Administration Guide.

This figure shows the Investigator alerts in the Management Module Editor.

Viewing and creating OSB alerts 243


To view OSB alerts using Investigator:

1 In the Investigator, expand the following nodes:

a *SuperDomain*

b Custom Metric Host (Virtual)

c Custom Metric Process (Virtual)

d Custom Metric Agent (Virtual)

e Alerts.

2 Expand the OSB_ManagementModule <version> (*Super Domain*) node to view all alerts for OSB.

3 Click an alert to view its current status in the Viewer pane.

Each alert has a metric value:

0 indicates Not Reporting

1 indicates Normal

2 indicates Caution

3 indicates Danger

This figure shows the Investigator alerts.



About OSB cross-process transaction tracingIntroscope SPM provides SOAP, HTTP, and JMS level Transaction Tracing for OSB.

Transaction Tracing also covers Transaction Trace correlation as a service passes through various OSB components. Even if these components are involved in message transformation or protocol transformation, their operations are visible in the cross-process Transaction Tracing.

OSB cross-process Transaction Tracing is enabled for SOAP, HTTP, and JMS level Transaction Tracing. Whether your environment consists of a homogeneous (for example, Java to Java) or heterogeneous (for example, Java to .NET) collection of platforms, a business transaction can be tracked across any combination of platforms as long as an OSB Agent extension and Introscope SPM are present at every node that needs to be traced. This gives you the ability to drill down into the details of a transaction not just within a single JVM or CLR, but into a transaction that goes into the JVM or CLR in a separate node.

You have to download and install the OSB Agent extensions and EM extensions. See Installing and configuring Introscope SPM on page 25. You do not have to perform any additional configuration or procedures to enable OSB cross-process transaction tracing, as this functionality is built into the product and is always operating.

» Note If a call from OSB is being executed by a service on an unmonitored agent, you get the execution time of the business service pointing to the unmonitored service. For example, a client calls a proxy service, which in turn calls a legacy application. Even if you do not have the Introscope SPM and OSB Agent extensions on the legacy application, you get the execution time of the business service pointing to the legacy application. In this case, the Transaction Tracer also shows errors, if any.

About OSB cross-process transaction tracing 245


Following an OSB transaction

By using cross-process Transaction Tracing, you can find out how a message gets transformed and routed inside OSB. You can also find out which business services and proxy services are being called during a transaction.

The process of carrying out and viewing a typical OSB transaction monitored by Introscope SPM involves four steps.

1 A business process transaction includes calls to different JVMs or CLRs on a local or remote machine.

2 Agents on the called JVMs or CLRs report the calls to the same Collector Enterprise Manager.

3 You run a Transaction Trace and select the entire business process.

4 In the Transaction Tracer Viewer Trace or Summary view, you can see the separate calls, including all the JVMs and CLRs.

» Note The following example uses simplified cross-process transactions shown in the associated figures.

In this example, all calls are to and from a Java JVM, showing homogeneous Java to Java transaction traces.

Example: Java to Java OSB cross-process transaction

This message flow example helps you understand how Introscope SPM monitors and displays OSB cross-process Transaction Tracing.



As shown in the figure below, the client JSP_largaccts_webservice sends a message to the OSB proxy service loangateway2. In the proxy service message flow, the message transformation is done by a service callout to Business Service A (CreditRatingService), and the transformed message is ultimately routed to Business Service B (loanSalesProcessor).

» Note A service callout is an action that you can configure in the OSB Console to call business services.

Here’s the proxy service (loan gateway2) when looking at the Trace View tab.



The proxy service (loangateway2) executes two EJBs, namely LargeSimpleBean and creditSimpleBean. As shown in this figure, you can also see the other components involved in the proxy service execution such as pipelines and XQueries.

2. Here are the largeSimplebean and creditSimplebean external services called by the proxy service.

1. Here’s the proxy service (loan gateway2) in the Summary View.



Viewing an OSB Transaction Trace

By clicking the Trace View tab, Workstation displays the traces and trace times making up the entire business process.

The actual time spent in each service is displayed in the Trace View. This helps you find out which external service called by the OSB proxy service took the maximum time to execute. In the figure shown below for example, in the proxy service loan gateway, the service call out to the CreditRating Business Service took 922 ms to execute, much longer than the call to the loanSaleProcessor business service, which took 16 ms.

Without the OSB cross-process Transaction Trace functionality, it would be very difficult to find the source of this problem. However, by using Introscope SPM to view this Transaction Trace, you can easily see in this figure that the service callout is responsible for the majority of the entire transaction execution time.

1. Here’s the CreditRatingService business service in the Trace View. The Duration column shows it took 922 ms to execute.

2. Here’s the CreditRatingService’s 922 ms transaction time.

3. Here’s the loanSalesProcess’s much shorter 16 ms transaction time.



Viewing correlated events using Transaction Tracer

If you are reviewing details about an OSB transaction, you can view the correlated events. This allows you to see whether there are web services on other processes or nodes that are called during the transaction.





3 In the Transaction Trace window, select Trace > Correlated Events.



The Historical Query Viewer opens listing the correlated events, which are the web services on other processes or nodes that are part of the selected Transaction Trace.



Monitoring WebSphere Process Server (WPS) 251

CHAPTER 7

Monitoring WebSphere Process Server (WPS)

Introscope SPM enables you to monitor WebSphere Process Server (WPS) web services and view the associated web service-related metrics and WPS components-related metrics in Introscope. This chapter discusses using the Introscope SPM WPS-specific dashboards and metrics to monitor your WPS environment.

Using Introscope SPM to monitor WPS and WESB . . . . . . . . . 252

About WPS and WESB component metrics . . . . . . . . . . . 253

About WPS and WESB metrics . . . . . . . . . . . . . . . 256

Viewing WPS tabs and metrics . . . . . . . . . . . . . . . 257

Viewing WESB tabs and metrics . . . . . . . . . . . . . . 269

Viewing WPS and WESB shared component metrics . . . . . . . . 271

Viewing WPS dashboards . . . . . . . . . . . . . . . . 284

Viewing WESB dashboards . . . . . . . . . . . . . . . . 294

Viewing and creating WPS and WESB metric groupings . . . . . . . 302

Viewing and creating WPS and WESB alerts . . . . . . . . . . 304

About WPS cross-process transaction tracing . . . . . . . . . . 308

252 Monitoring WebSphere Process Server (WPS)


Using Introscope SPM to monitor WPS and WESBYou can view live data in the Investigator and Console to monitor the performance of WPS and Websphere Enterprise Service Bus (WESB).

To view data in the Investigator and Console:

1 Ensure that your applications are instrumented and providing data.

2 Ensure that the Enterprise Manager is running.

3 Start the Introscope Workstation.

See Starting the Introscope Workstation on page 95.

4 Navigate to the Introscope Investigator window.

Metrics that are specific to WPS appear under the WProcServer node in the Investigator tree. Metrics that are specific to WESB appear under the WESB node in the Investigator tree. This figure shows some of the metrics collected by Introscope SPM.

5 Navigate to the Introscope Workstation Console.

Here are the WPS components.

The WProcServer node represents the WPS server.

If you are monitoring a standalone WESB environment, you’ll see the WESB node here.

About WPS and WESB component metrics 253


Introscope SPM provides a number of pre-configured dashboards for displaying WPS and WESB performance metrics. See For information about the tabs and metrics for WPS and WESB shared components, see Viewing WPS and WESB shared component metrics on page 271. on page 270.

About WPS and WESB component metricsIntroscope SPM provides metrics for monitoring the health of your WPS or WESB environment.

WPS is a comprehensive Service Oriented Architecture (SOA) integration platform that lets you integrate existing applications with newer applications so that they work together seamlessly. WPS facilitates this seamless integration with the help of service components, supporting services, and WESB. Service components for WPS are business processes, business states, business rules, and human tasks. Supporting services for WPS are mediation flows, interface maps, business object maps, Java components, relationships, selectors, and adapters.

Introscope SPM monitors how WPS service components and supporting services and WESB perform to integrate applications seamlessly, which provides data about WPS overall health.

Websphere Process Server includes Websphere Enterprise Service Bus as well as some additional components. WESB manages the flow of messages in WPS and handles any data transformation or routing required between services and clients with the help of mediation flows and primitives. So when Introscope SPM monitors WPS, Introscope displays health data for both WPS and WESB.

IBM also provides Websphere Enterprise Service Bus as a standalone product. So when Introscope SPM monitors WESB only, Introscope displays health data about WESB only, not for WPS and WESB.



This table shows the metrics and dashboards Introscope SPM provides for each of these environments:

WPS and WESB shared components

Introscope SPM provides the metrics for the following WPS and WESB shared components:

Mediation Flow: A WESB component made up of request flows for handling requests, response flows for handling responses, event flows for handling events, and fault flows for handling faults. A request flow begins for each source operation and response flow begins for each target operation.

Mediation Primitive: Mediation primitives are WESB building blocks that implement the capabilities of a mediation flow component. Each mediation flow contains mediation primitives that let you transform data, if required.

Java component: A component that allows you to customize Java implementations in WPS/WESB.

Business Object Map: Supporting service component that assigns values to the target business objects service components based on the values in the source business objects service components. One business object becomes the source and another becomes the target. The business object map maps the source and target.

This Introscope SPM metric & dashboard are displayed in this environment

Business Processes WPS Only

Business State Machines WPS Only

Business Rules WPS Only

Human Tasks WPS Only

Interface Maps WPS Only

Selectors WPS Only

Mediation Flows WPS and WESB

Mediation Primitives WPS and WESB

Java Components WPS and WESB

BO Maps WPS and WESB

Relationships WPS and WESB

J2CA (Adapters) WPS and WESB

Data Binding WPS and WESB

About WPS and WESB component metrics 255


Relationship: Relationship establishes an association between data from two or more data types. The figure below shows a relationship that defines the correlation between a Customer and the Customer ID.

Adapter: An adapter is an application that enables a WebSphere Process Server to communicate with the external Enterprise Information System (EIS). Outbound communication occurs when a WebSphere Process Server calls an EIS-specific operation. Inbound communication occurs when the application listens for a specific EIS event.

Data Binding: A data binding is used to convert business objects to a stream of data during inbound and outbound processing.

WPS-specific components

Introscope SPM provides the metrics for the following WPS components, as well as WPS faults:

Business Process: A procedure made up of individual tasks that are executed in a specific order to achieve a particular goal. A business process is made up of at least one task that may be involved in receiving a message in response to a request.

Business State Machine: A business state machine is an event-driven application. It waits for an event to occur and, based on the event, chooses an appropriate action to execute. Once the action is executed, the machine may go to another state or simply wait for another event to occur.

Business Rule: A rule that captures and implements business policies and practices. A business rule can enforce business policy, make a decision, or infer new data from existing data.

Human Task: A task performed by a human. This may involve interaction with processes or services in WPS.



Interface Map: A supporting service that reconciles the differences between components that have different interfaces. They resolve and reconcile differences across multiple interfaces using transformation and other rudimentary operations between interfaces. These operations enable the components to communicate.

Selector: A component that provide flexibility in the processing of service components during run time. A selector accepts one invocation from the client application and allows different targets to be called at runtime based on the selection criteria.

» Note If you want to view Performance Monitoring Infrastructure (PMI) metrics for WPS-related components in Introscope SPM Investigator, you need to perform some configuration. See Optional: Configure IntroscopeAgent.profile so Introscope SPM monitors WebSphere PMI metrics. on page 76. For information about configuring the PMI service for WebSphere Application Server Distributed, see the CA Wily Introscope PowerPack for IBM® WebSphere® Application Server Distributed User Guide.

About WPS and WESB metricsThe following metrics appear for each WPS and WESB node in the Investigator tree:

Average Response Time (ms): average time taken for executing or invoking a specific operation or action.

Concurrent Invocations: how many requests are going through at a given time (throughput).

Errors Per Interval: how many errors are recorded by the Introscope Agent by catching a Java exception in a 15-second time slice.

Responses Per Interval: the number of invocations that completed during a 15-second time slice.

Stall Count: how many operations, invocations, or calls are taking longer than 30 seconds in a 15-second time slice.

Viewing WPS tabs and metrics 257


Viewing WPS tabs and metrics» Note The Introscope SPM SOA Dependency Map displays only web services,

and does not represent process flows from WPS.

To view WPS tabs and metrics:


2 Expand the Introscope Agent node you are interested in, and then click the WProcServer node.

In the Viewer pane, the Overview tab is active by default, and all the business processes, business state machines, and mediation flows that WPS is currently using are listed in their respective tables.

3 Double-click a business process, business state machine, or mediation flow to view all the associated metrics in a graphical format.

4 Expand the WProcServer node.

Under the WProcServer node are sub-nodes for Business Process, Business State Machines, Business Rules, Human Tasks, Interface Maps, Selectors, Java Components, Mediation Flows, Business Object Maps, Relationships, Adapters, and Data Bindings. WPS metric data appears under these sub-nodes.

5 Expand the sub-nodes to see the individual operations and metrics listed under each. This figure shows the Investigator metrics for WPS.



For information about the tabs and metrics for WPS and WESB shared components, see Viewing WPS and WESB shared component metrics on page 271.



Viewing Business Processes metrics

To view the Business Processes metrics:

1 Click the WProcServer > BusinessProcesses node.

In the Viewer pane, the Overview tab is active by default and all the business processes that WPS is currently using are listed in a table.

2 Click a business process to view the Average Response Time metric data in a graphical format.

3 Double-click a business process to view all the associated metrics in a graphical format.

4 Expand the BusinessProcesses node.

You can see all the business processes listed under this node.

5 Expand all the business processes sub-nodes to see the metrics listed for each.

Each business process shows the metrics for the processing done for that specific business process only.



This figure shows the Investigator metrics for business processes.

.



» Note You must perform some configuration to display separate metrics if you have different versions of the same Business Process. For information about this configuration, see Optional: Configure WPS.pbd to provide separate metrics for different versions of a Business Process. on page 76.If you perform this configuration, then the business process name under the BusinessProcesses node is displayed as shown in the figure below. Notice that:* the business process name contains a time stamp to differentiate between various versions of the same process.* in the time stamp, an underscore [_] symbol replaces the colon [:] that is typically part of the business process name.

This figure shows the Investigator metrics for business processes.

Here’s the process name with the time stamp.



Viewing Business State Machines metrics

To view the Business State Machines metrics:

1 Click the WProcServer > BusinessStateMachines node.

2 In the Viewer pane, the Overview tab is active by default and all the business state machines that WPS is currently using are listed in a table.

3 Click a business state machine to view the Average Response Time metric in a graphical format.

4 Double-click a business state machine to view all the associated metrics in a graphical format.

5 Expand the BusinessStateMachines node.

6 You can see all the business state machines listed under this node.

7 Expand all the business state machines to see the metrics listed for each.

Each business state machine shows the metrics for the processing done for that specific business state machine only.

This figure shows the Investigator metrics for business state machines.



Viewing Business Rules metrics

To view the Business Rules metrics:

1 Click the WProcServer > BusinessRules node.

In the Viewer pane, the Overview tab is active by default and all the business rules that WPS is currently using are listed in a table.

2 Click a business rule to view the Average Response Time metric in a graphical format.

3 Double-click a business rule to view all the associated metrics in a graphical format.

4 Expand the BusinessRules node.

You can see all the business rules listed under this node.

5 Expand all the business rules to see the metrics listed for each.

This figure shows the Investigator metrics for business rules.



Viewing Human Tasks metrics

To view the Human Tasks metrics:

1 Click the WProcServer > HumanTasks node.

In the Viewer pane, the Overview tab is active by default and all the human tasks that WPS is currently using are listed in a table.

2 Click a human task to view the Average Response Time metric in a graphical format.

3 Double-click a human task to view all the associated metrics in a graphical format.

4 Expand the HumanTasks node.

You can see all the human tasks listed under this node.

5 Expand all the human tasks to see the metrics listed for each.

This figure shows the Investigator metrics for human tasks.



Viewing Interface Maps metrics

To view the Interface Maps metrics:

1 Click the WProcServer > InterfaceMaps node.

In the Viewer pane, the Overview tab is active by default and all the interface maps that WPS is currently using are listed in a table.

2 Click an interface map to view the Average Response Time metric in a graphical format.

3 Double-click an interface map to view all the associated metrics in a graphical format.

4 Expand the InterfaceMaps node.

You can see all the interface maps listed under this node.

5 Expand all the interface maps to see the metrics listed for each.

For synchronous invocations these metrics represent the total time taken by the interface map component. For asynchronous invocation these metrics represent input and output transformations separately.

This figure shows the Investigator metrics for interface maps.



Viewing Selectors metrics

To view the Selectors metrics:

1 Click the WProcServer > Selectors node.

In the Viewer pane, the Overview tab is active by default and all the selectors along with corresponding destinations that the WPS is currently using are listed in a table.

In the Investigator tree, all the selectors are listed under the Selectors node. All the components that a particular selector uses are listed under the selector.

2 In the Viewer pane, click a selector to view the Average Response Time metric in a graphical format.

3 Double-click a selector to view all the associated metrics in a graphical format.

4 Expand the Selectors node and click a selector.

5 In the Viewer pane, the Overview tab is active by default and all the components of the selector are listed in a table.

6 Click a component and a corresponding metric to view the data for that metric in a graphical format.

7 Double-click a component to view all the associated metrics in a graphical format.

You can also expand the Selectors node, expand one of the selectors, and click a component to view data for all associated metrics in a graphical format.

This figure shows the Investigator metrics for selectors.



WPS Faults

When a fault occurs in the WPS tier, an exception is thrown if the fault is not handled. The WPS Faults Per Interval metric shows the number of exceptions that have occurred in a 15-second time slice.

To view WPS Faults Per Interval metric:

1 In the Investigator tree, navigate to the WProcServer > WPSFaults node.

2 Expand the node to view the WPS Faults Per Interval metric.

This figure shows the WPS Faults Per Interval metric In the Investigator tree.


Viewing WESB tabs and metrics 269


Viewing WESB tabs and metrics» Note The Introscope SPM SOA Dependency Map displays only web services,

and does not represent process flows from WESB.

To view WESB tabs and metrics:


2 Click the WESB node.

In the Viewer pane, the Overview tab is active by default, and all mediation flow components along with there module names that are currently being used are listed in a table.

The WESB metric data appears under the WESB node in the Investigator tree.

3 Click a mediation flow component to view the Average Response Time metric in a graphical format.

4 Double-click a mediation flow component to view all the associated metrics in a graphical format.

5 Expand the WESB node.

Metrics for Mediation Flows and Primitives are displayed under the WESB node.



This figure shows the Investigator metrics for WESB.


Viewing WPS and WESB shared component metrics 271


Viewing WPS and WESB shared component metrics

Viewing Relationships metrics

To view Relationships metrics:

1 In the Investigator tree:

for WPS, click the WProcServer > Relationships node.

for WESB, click the WESB > Relationships node.

In the Viewer pane, the Overview tab is active by default and all the relationships that currently being used are listed in a table.

2 Click a relationship to view the Average Response time metric data in a graphical format.

3 Double-click a relationship to view all the associated metrics in a graphical format.

4 Expand the Relationships node.

You can see all the relationships listed under this node.

5 Expand all the relationships to see the metrics listed for each.

This figure shows the Investigator metrics for relationships.



Viewing Java Components metrics

To view the Java Components metrics:


for WPS, click the WProcServer > JavaComponents node.

for WESB, click the WESB > JavaComponents node.

In the Viewer pane, the Overview tab is active by default and all the Java components along with their operations that currently being used are listed in a table.

In the Investigator tree, all the Java components are listed under the JavaComponents node. All the operations that a particular Java component executes are listed under the Java component.

2 In the Viewer pane, click a Java component to view the Average Response time metric data in a graphical format.

3 Double-click a Java component to view all the associated metrics in a graphical format.

4 Expand the JavaComponents node and click a Java component.

5 In the Viewer pane, click an operation and a corresponding metric to view the data for that metric in a graphical format.

6 Double-click an operation to view all the associated metrics in a graphical format.

7 You can also expand the JavaComponents node, expand one of the Java components, and click an operation to view data for all associated metrics in a graphical format.

This figure shows the Investigator metrics for Java components.



Here’s the Java component name.

Here’s the method name of the Java component.



Viewing Business Objects Maps metrics

To view the Business Objects Maps metrics:


for WPS, click the WProcServer > BOMaps node.

for WESB, click the WESB > BOMaps node.

In the Viewer pane, the Overview tab is active by default and all the business object maps along with there target namespaces that currently being used are listed in a table.

In the Investigator tree, all the business object maps are listed under corresponding target namespaces under the BOMaps node.

2 In the Viewer pane, click a target namespace to view the Average Response time metric data in a graphical format.

3 Double-click a target namespace to view all the associated metrics in a graphical format.

4 Expand the BOMaps node and click a business object map target namespace.

5 In the Viewer pane, the Overview tab is active by default and all the business object maps of the target namespace are listed in a table.

6 Click a business object map to view the Average Response Time metric data in a graphical format.

7 Double-click a business object map to view all the associated metrics in a graphical format.

You can also expand the BOMaps node, expand one of the target namespaces, and click a business object map to view data for all associated metrics in a graphical format.



This figure shows the Investigator metrics for business object maps.

Here are the Business Object Map names.

Here’s the Business Object Maps target namespace.



Viewing Adapters metrics

To view the Adapters metrics:


for WPS, click the WProcServer > J2CA node.

for WESB, click the WESB > J2CA node.

In the Viewer pane, the Overview tab is active by default, and all the outbound interactions along with there record names and inbound event persistence that are currently being used are listed in their respective tables.

In the Investigator tree, you can see all inbound and outbound communications for the adapters listed under the J2CA node.

2 Click an outbound interaction or inbound event persistence to view the Average Response time metric data in a graphical format.

3 Double-click an outbound interaction or inbound event persistence to view all the associated metrics in a graphical format.

4 Expand all inbound and outbound communications to see the interactions and event persistence listed for each.

5 Expand the interactions to see the record names listed for each.

6 Expand all record names to see the metrics listed for each.

This figure shows the Investigator metrics for adapters.



Viewing Data Bindings metrics

To view the Data Bindings metrics:


for WPS, click the WProcServer > DataBindings node.

for WESB, click the WESB > DataBindings node.

In the Viewer pane, the Overview tab is active by default, and all the data bindings that are currently being used are listed in a table.

In the Investigator tree, you can see all inbound and outbound data conversion for the data bindings listed under the DataBindings node.

2 In the Viewer pane, click a data binding to view the Average Response time metric data in a graphical format.

3 Double-click a data binding to view all the associated metrics in a graphical format.

4 Expand the DataBindings node to see all the data bindings listed under this node.

5 Expand all the data bindings to see the metrics listed for each.



This figure shows the Investigator metrics for data bindings.



Viewing Mediation Flow and Primitives metrics

To view Mediation Flows and Primitives metrics:


for WPS, click the WProcServer >WESB > MediationFlows node

for WEBS, click the WESB > MediationFlows node.

In the Viewer pane, the Overview tab is active by default, and all mediation flow components and the associated modules that are currently being used are listed in a table.

In Investigator, you can see all the modules that have mediation flow components.

2 Click a mediation flow component to view the Average Response time metric data in a graphical format.

3 Double-click a mediation flow component to view all the associated metrics in a graphical format. The operations invoked for each mediation flow component are listed in a table.

4 Click an operation to view the Average Response Time metric data in a graphical format.

5 Double-click an operation.

You see all the associated request flows, response flows, event flows, and fault flows listed in a table. You also see mediation primitives listed in a separate table.

6 Click a request flow, response flow, event flow, fault flow, or mediation primitive to view the Average Response Time metric data in a graphical format.

7 Double-click a request flow, response flow, event flow, fault flow, or mediation primitive to view all the associated metric data in a graphical format.

8 To see more mediation flow and primitives data, expand more sub-nodes.

a Expand all modules to see the mediation flow components listed for each.

b Expand all the mediation flow components to see the operations invoked for each.

c Expand all the operations to see the flows and mediation primitives listed for each.

d Expand all the mediation primitives to see the metrics listed for each.



This figure shows the Investigator metrics for Mediation Flows and Primitives.

Here’s the name of the module that contains this Mediation Flow component.

Here’s the Mediation Flow component name.

Here’s the operation name of the Mediation Flow component that has been called.

Here are the mediation primitives that have been invoked.



About aggregated metrics for mediation flows

Introscope SPM calculates and displays in Investigator aggregated metrics at the mediation flow component and mediation flow component operation levels.

Investigator displays these metrics for each mediation flow component by aggregating metrics of all the operations of corresponding mediation flow components:

Average Response Time (ART)

Concurrent Invocations (CI)

Errors Per Interval (EPI)

Responses Per Interval (RPI)

Stall Count (SC)

Investigator displays these aggregated metrics for each mediation flow component operation:

The Average Response Time (ART) metric at operation level.

Introscope SPM calculates this metric using this equation:

((request flow ART x count value) + (response flow ART x count

value) + (fault flow ART x count value) + (event flow ART x

count value)) / Single largest count value across RequestFlow,

ResponseFlow, FaultFlow, and EventFlow

For example, if during this interval there is one request flow, one response flow, two fault flows, and three event flows, the single largest count value would be 3 for the three event flow counts.

The concurrent invocations (CI) metric value at the operation level.

Introscope SPM calculates this metric by adding the corresponding RequestFlow, ResponseFlow, FaultFlow, and EventFlow CI metrics data.

The Errors Per interval (EPI) metric value at operation level.

Introscope SPM calculates this metric by adding the corresponding RequestFlow, ResponseFlow, EventFlow EPI metrics data and the Responses Per interval (RPI) metrics data of the fault flow.

Fault flows are expected to occur when a fault occurs. So the RPI metric value for a fault flow is added to the EPI metric value at the operation level to represent that an error has occurred during that operation’s invocation.



The Responses Per interval (RPI) metric at operation level.

Introscope SPM provides this metric by displaying the maximum RPI of RequestFlow, ResponseFlow, FaultFlow, and EventFlow for that interval.

The stall count (SC) metric value at the operation level.

Introscope SPM calculates this metric by adding the corresponding RequestFlow, ResponseFlow, FaultFlow, and EventFlow SC metrics data.

This figure shows the aggregated metrics for Mediation Flows.

Here are the aggregated metrics at the Mediation Flow component level.

Here are the aggregated metrics at the Mediation Flow component operation level.

Viewing WPS and WESB Dashboards 283


Viewing WPS and WESB DashboardsWPS and WESB dashboards combine and present application metrics in views that you can use to monitor your application environment.

The WPS and WESB dashboards provide:

High-level application health and status views of the applications.

At-a-glance notification of problems in the production application environment.

Data that enables you to quickly identify the problems.

Pre-defined navigation between high-level and drill-down performance information.

The Introscope SPM WPS and WESB Management Modules provide nine pre-defined dashboards for WPS and seven pre-defined dashboards for WESB.

Dashboards are associated with alerts that show the overall health of the application. Each alert has a metric value:

Gray indicates that no data is available

Green indicates OK

Yellow indicates Caution

Red indicates Danger

To view dashboards:


2 Select a dashboard from the drop-down list.



Viewing WPS dashboardsHere are the dashboards you’ll see when you use Introscope SPM to monitor your WPS environment.

WPS Overview dashboard

When monitoring WPS, first view the WPS Overview dashboard. It shows an architectural overview of WebSphere Process Server and its components. Each component has alerts to show its overall health.


1 Double-click an alert associated with a component to open the component's dashboard.

For example, click the Data Bindings response times alert to go to the Data Bindings dashboard.

2 Double-click a tab to navigate to the associated dashboard.

Viewing WPS dashboards 285


WPS Business Processes & State Machines (Service Components I) dashboard


Overall health of business processes and business state machines.

A graph showing the Average Response Times for all business processes, as well as alerts for Errors Per Interval and Stall Counts.

A graph showing the Average Response Times for all business state machines, as well as alerts for Errors Per Interval and Stall Counts.

Top 10 slowest Business Processes.

Top 10 slowest Business State Machines.


Double-click a business process or business state machine in the chart that displays the Top 10 slowest Business Processes or Business State Machines, respectively, to view its details in the Investigator.

Right-click a graph or an alert, click Links, and navigate to the WPS Overview dashboard or the corresponding alert in the Management Module.



WPS Business Rules & Human Tasks (Service Components II) dashboard


Overall health of business rules and human tasks.

A graph showing the Average Response Times for all business rules, as well as alerts for Errors Per Interval and Stall Counts.

A graph showing the Average Response Times for all human tasks, as well as alerts for Errors Per Interval and Stall Counts.

Top 10 slowest Business Rules.

Top 10 slowest Human Tasks.


Double-click a business rule or human task in the chart that displays the Top 10 slowest Business Rules or Human Tasks, respectively, to view its details in the Investigator.




WPS Interface Maps, BO Maps, & Relationships dashboard


Overall health of interface maps, business object maps, and relationships.

A graph showing the Average Response Times for all interface maps, as well as alerts for Errors Per Interval and Stall Counts.

A graph showing the Average Response Times for all business object maps, as well as alerts for Errors Per Interval and Stall Counts.

A graph showing the Average Response Times for all relationships, as well as alerts for Errors Per Interval and Stall Counts.

Top 10 slowest Interface Maps.

Top 10 slowest Business Object Maps.

Top 10 slowest Relationships.


Double-click an interface object, a business object map, or relationship in the chart that displays the Top 10 slowest Interface Maps, Business Object Maps, or Relationships, respectively, to view its details in the Investigator.




WPS Selectors & Java Components dashboard


Overall health of selectors and Java components.

A graph showing the Average Response Times for all selectors, as well as alerts for Errors Per Interval and Stall Counts.

A graph showing the Average Response Times for all Java components, as well as alerts for Errors Per Interval and Stall Counts.

Top 10 slowest Selectors.

Top 10 slowest Java Components.


Double-click a selector or Java component in the chart that displays the Top 10 slowest Selectors or Java Components, respectively, to view its details in the Investigator.




WPS Data Bindings dashboard


Overall health of data bindings.

Graphs and alerts for Average Response Time, Errors Per Interval, and Stall Counts.

Top 10 slowest Data Bindings.


Double-click a data binding in the 10 Slowest Data Bindings chart to view its details in the Investigator.




WPS Adapters dashboard


Overall health of inbound and outbound adapters.

A graph showing the Average Response Times for all inbound adapters, as well as alerts for Errors Per Interval and Stall Counts.

A graph showing the Average Response Times for all outbound adapters, as well as alerts for Errors Per Interval and Stall Counts.

Top 10 slowest Inbound Adapters.

Top 10 slowest Outbound Adapters.


Double-click an inbound or outbound adapter in the chart that displays the Top 10 Inbound or Outbound Adapters, respectively, to view its details in the Investigator.




WESB Mediation Flows dashboard» Note Introscope SPM provides this dashboard for monitoring WESB within a

WPS environment.


Overall health of mediation flows, request flows, response flows, and fault flows. Mediation flows are aggregates of request, response, and fault flows.

A graph showing the Average Response Times for all mediation flows, as well as alerts for Errors Per Interval and Stall Counts.

A graph showing the Average Response Times for all request flows, as well as alerts for Errors Per Interval and Stall Counts.

A graph showing the Average Response Times for all response flows, as well as alerts for Errors Per Interval and Stall Counts.

A graph showing the Average Response Times for all fault flows, as well as alerts for Errors Per Interval and Stall Counts.

Top 10 slowest Mediation Flows.


Double-click a mediation flow in the 10 Slowest Mediations Flows chart to view its details in the Investigator.

Double-click a graph or an alert to navigate to the WESB- Mediation Primitives dashboard.



Right-click a graph or an alert, click Links, and navigate to WESB Mediation Primitives dashboard, WPS Overview dashboard, or the corresponding alert in the Management Module.



WESB Mediation Primitives dashboard» Note Introscope SPM provides this dashboard for monitoring WESB within a

WPS environment.


Overall health of mediation primitives, request flows, fault flows, and response flows.

Alerts for Average Response Times and Errors Per Interval for all mediation primitives.

Alerts for Average Response Times, Errors Per Interval, and Stall Counts for all request flows, fault flows, and response flows.


Right-click an alert for request flows, fault flows, or response flows, click Links, and navigate to the WESB Overview dashboard or the corresponding alert in the Management Module.

Right-click an alert for a mediation primitive, click Links, and navigate to the corresponding alert in the Management Module.



Viewing WESB dashboardsHere are the dashboards you’ll see when you use Introscope SPM to monitor your WESB environment.

» Note CA Wily provides these dashboards when Introscope SPM monitors WESB only, and not WPS and WESB together.

WESB Overview dashboard

When monitoring WESB, first view the WESB Overview dashboard. It consists of all major components of the WESB tier. Each component has alerts to show its overall health.


Double-click an alert associated with a component to open the component's dashboard. For example, click the Java Components response times alert to go to the Java Components dashboard.

Double-click a tab to navigate to the associated dashboard.

Viewing WESB dashboards 295


WESB Mediation Flows dashboard


Overall health of mediation flows, request flows, response flows, and fault flows. Mediation flows are aggregates of request, response, and fault flows.

A graph showing the Average Response Times for all mediation flows, as well as alerts for Errors Per Interval and Stall Counts.

A graph showing the Average Response Times for all request flows, as well as alerts for Errors Per Interval and Stall Counts.

A graph showing the Average Response Times for all response flows, as well as alerts for Errors Per Interval and Stall Counts.

A graph showing the Average Response Times for all fault flows, as well as alerts for Errors Per Interval and Stall Counts.

Top 10 slowest Mediation Flows


Double-click a mediation flow in the 10 Slowest Mediations Flows chart to view its details in the Investigator.

Double-click a graph or an alert to navigate to the WESB- Mediation Primitives dashboard.



Right-click a graph or an alert, click Links, and navigate to WESB Mediation Primitives dashboard, WPS Overview dashboard, or the corresponding alert in the Management Module.



WESB Mediation Primitives dashboard


Overall health of mediation primitives, request flows, fault flows, and response flows.

Alerts for Average Response Times and Errors Per Interval for all mediation primitives.

Alerts for Average Response Times, Errors Per Interval, and Stall Counts for all request flows, fault flows, and response flows.


Right-click an alert for request flows, fault flows, or response flows, click Links, and navigate to the WESB Overview dashboard or the corresponding alert in the Management Module.

Right-click an alert for a mediation primitive, click Links, and navigate to the corresponding alert in the Management Module.



WESB Adapters dashboard


Overall health of inbound and outbound adapters.

A graph showing the Average Response Times for all inbound adapters, as well as alerts for Errors Per Interval and Stall Counts.

A graph showing the Average Response Times for all outbound adapters, as well as alerts for Errors Per Interval and Stall Counts.

Top 10 slowest Inbound Adapters.

Top 10 slowest Outbound Adapters.


Double-click an inbound or outbound adapter in the chart that displays the Top 10 Inbound or Outbound Adapters, respectively, to view its details in the Investigator.

Right-click a graph or an alert, click Links, and navigate to the WESB Overview dashboard or the corresponding alert in the Management Module.



WESB BO Maps & Relationships dashboard


Overall health of business object maps and relationships.

A graph showing the Average Response Times for all business object maps, as well as alerts for Errors Per Interval and Stall Counts.

A graph showing the Average Response Times for all relationships, as well as alerts for Errors Per Interval and Stall Counts.

Top 10 slowest Business Object Maps.

Top 10 slowest Relationships.


Double-click a business object map or relationship in the chart that displays the Top 10 slowest Business Object Maps or Relationships, respectively, to view its details in the Investigator.




WESB Data Bindings dashboard


Overall health of data bindings.

Graphs and alerts for Average Response Time, Errors Per Interval, and Stall Counts.

Top 10 slowest Data Bindings.


Double-click a data binding in the 10 Slowest Data Bindings chart to view its details in the Investigator.




WESB Java Components dashboard


Overall health of Java components.

Alerts and graphs for Average Response Time, Errors Per Interval, and Stall Counts.

Top 10 slowest Java components.


Double-click a Java component in the 10 Slowest Java Components chart to view its details in the Investigator.

Right-click a graph or an alert, click Links, and navigate to the WESB Overview dashboard or the corresponding alert in the Management Module.



Viewing and creating WPS and WESB metric groupings

You can view and create the metric groupings for WPS and WESB using the Management Module Editor.

To view WPS metrics groupings across all agents:




a Super Domain.


c WPS_Management_Module <version>.

3 Expand the MetricGroupings node to view all metric groupings for WPS.


5 Click Elements > New Metric Grouping to create a new metric grouping based on the WPS management module.


This figure shows WPS metric groupings in the Management Module Editor.

Viewing and creating WPS and WESB metric groupings 303


To view WESB metrics groupings across all agents:




a Super Domain.


c WESB_Management_Module <version>.

3 Expand the MetricGroupings node to view all metric groupings for WESB.


5 Click Elements > New Metric Grouping to create a new metric grouping based on the WESB management module.


This figure shows WESB metric groupings in the Management Module Editor.



Viewing and creating WPS and WESB alertsYou can view and create the alerts for WPS and WESB using the Management Module Editor and the Investigator.

To view WPS alerts using Management Module Editor:



a Super Domain.


c WPS_Management_Module <version>.

3 Expand the Alerts node to view all alerts for WPS.




This figure shows WPS alerts in the Management Module Editor.

Viewing and creating WPS and WESB alerts 305


To view WPS alerts using Investigator:


a Super Domain.

b Custom Metric Host.

c Custom Metric Process.

d Custom Metric Agent.

e Alerts.

2 Expand the WPS_Management_Module <version> node to view all alerts for WPS.




1 indicates Normal

2 indicates Caution

3 indicates Danger

This figure shows WESB alerts in the Investigator.



To view WESB alerts using Management Module Editor:



a Super Domain.


c WESB_Management_Module <version>.

3 Expand the Alerts node to view all alerts for WESB.




This figure shows WESB alerts in the Management Module Editor.

Viewing and creating WPS and WESB alerts 307


To view WESB alerts using Investigator:


a Super Domain.

b Custom Metric Host.

c Custom Metric Process.

d Custom Metric Agent.

e Alerts.

2 Expand the WESB_Management_Module <version> node to view all alerts for WESB.




1 indicates Normal

2 indicates Caution

3 indicates Danger

This screenshot illustrates the alerts in the Investigator.



About WPS cross-process transaction tracingIntroscope SPM WPS/WESB expands Introscope SPM cross-process transaction tracing capability by correlating the transactions initiated outside of WPS/WESB with the short asynchronous transactions that are initiated in your WPS/WESB environment. This gives you the ability to drill down into the details of a transaction that is carried out in WPS/WESB down to the individual components level. Introscope SPM WPS/WESB cross-process transaction tracing is enabled at the HTTP, JMS, and SOAP levels.

» Note You can view activities executed as part of Business Processes in your WPS Transaction Traces. This helps you determine the performance of your Business Processes down to the activity level. In order to see the activities executed in the Business Process execution level, you must perform some configuration. See Optional: Configure the WPS.pbd to see the activities executed in the Business Process Execution. on page 77.

» Important There is a significant performance overhead involved in fetching the activities names, therefore activity tracing is off by default. Turn on activity tracing only when required.

When a transaction involves web services and WPS/WESB components, then whether your environment consists of a homogenous (for example, Java to Java) or heterogeneous (for example, Java to .NET) collection of platforms, a business transaction can be tracked across any combination of platforms as long as an WPS/WESB Agent extension and Introscope SPM are present at every node that needs to be traced. This gives you the ability to drill down into the details of a transaction not just within a single JVM or CLR, but into a transaction that goes into the JVM or CLR of a separate node.

About WPS cross-process transaction tracing 309


Following a WPS transaction

By using cross-process Transaction Trace, you can find out how a client call gets executed in WPS. You can also find out which WPS/WESB components are being called during a transaction.

The process of carrying out and viewing a typical WPS transaction monitored by Introscope SPM involves four steps:

Step 1 A business transaction includes calls to different JVMs or CLRs on a local or remote machine.

Step 2 Agents on the called JVMs or CLRs report the calls to the same Collector Enterprise Manager.

Step 3 You run a Transaction Trace and select the entire business transaction.

Step 4 In the Transaction Tracer Viewer Summary view, you can see the separate calls, including all the JVMs and CLRs.

» Note The following example uses simplified cross-process transactions and associated figures.

In this example, all calls are to and from a Java JVM, so this is a homogeneous Java to Java transaction trace.

Example: Java to Java WPS cross-process transaction

A web application client invokes the JMSInvokerProcess Business Process (exposed as SOAP over JMS service) and prints the result on the web page. When the business process receives the client call, it invokes a MPGConverterProcess child process (imported using JMS binding). The reply sent by the MPGConverterProcess child process is sent back to the client. The client displays the response on the web page.



In the first transaction in the figure below, the JMSInvokerProcess business process receives the web application’s client call.

2. Click the first trace.

3. You can view data for the Received business process activity associated with the called JmsInvokerProcess Business Process.

1. Start in the Transaction Trace Viewer’s Summary View.



By clicking another transaction in the Transaction Trace list, you can see more business process activities, as shown in this figure.

Prepare JMS call

Call Converter Process

Every trace gives information about the activities that are being executed as part of that trace, which helps you to understand the contribution of activities to the overall transaction.

1. Here’s the JMS and convertor process call, which is an activity responsible for calling the MPGConverterProcess child Business

2. Here are the two associated business process activities.



By clicking the subsequent transactions, you can see the calls executed by that particular transaction in the Summary View and the time taken by the transaction in the Trace View.

By clicking one of the next traces in the Transaction Trace list, you can see more business process activities of the child process. As shown in this figure, the Reply activity of the MPGConverterProcess Business Process returns the response to the JMSInvokerProcess parent Business Process.

1. Here are the child business process activities. 2. The reply child business process activity shows that the child process has been returned to the parent process.



By clicking the next trace in the Transaction Trace list, you can see more parent process activities.

As shown in this figure, the reply activity of the JMSInvokerProcess returns the response to the client.

Here the reply has been sent from the parent Business Process to the client.



When you click the Trace View tab, Workstation displays the traces for the whole business transaction, so we can understand the transaction flow.

The Trace View highlights the parent process transaction before it returns to the client as shown in this figure.

2. See the parent Business Process before returning to the client.

1. Click the Trace View tab.



By clicking the last transaction in the Trace View, you can see that all the transactions are correlated here in the execution order as shown in the following figure.

By using Introscope SPM to monitor WPS/WESB, you can trace the complete business transaction flow. In addition, you can find the various WPS/WESB entities that have been executed in this flow for a particular request. If you click the Duration column heading, Workstation sorts the transactions by time.

2. The transactions in the biggest box above represent the entire client transaction. In this case, the client transaction is a synchronous call, therefore the client waits to finish the transaction until the business process returns the reply.

1. All the transactions are correlated in the execution order.



Viewing correlated events using Transaction Trace

If you are reviewing details about a WPS transaction, you can view thecorrelated events. This shows you all the traces that are part of a single business transaction, which might include the following:

Traces collected from other nodes/servers that initiated a transaction in your WPS/WESB environment.

Traces collected from your WPS/WESB environment.

Traces related to other services that are invoked by WPS/WESB components.





3 In the Transaction Trace window, select Trace > Correlated Events.

The Historical Query Viewer opens listing the correlated events, which involve WPS/WESB components and web services on other processes or nodes that are part of the selected Transaction Trace.



Required configuration after Introscope .NET Agent install or upgrade 317

APPENDIX A

Required configuration after Introscope .NET Agent install or upgrade

Introscope SPM requires an installed Introscope .NET Agent version 8.1 at a minimum. You need to make the configuration changes described in this appendix each time you install or upgrade the .NET Agent to a version later than 8.1.

This appendix includes this topic:

Reconfiguring after installing or upgrading the Introscope .NET Agent version 318

318 Required configuration after Introscope .NET Agent install or upgrade


Reconfiguring after installing or upgrading the Introscope .NET Agent version

If you install or upgrade the Introscope .NET Agent to a version later than 8.1, in order for the .NET Agent extension to work you must make these configuration changes to redirect dll’s.

To redirect dll’s for Introscope .NET Agent versions later than 8.1:

1 Find the aspnet.config application server configuration file used by the IIS application server.

a In Windows, choose Start > Run to open the Run dialog box.

b In the Run dialog box Open field, type Microsoft.NET, then press OK.

c Go to the Framework\vx.x.xxxx directory, where vx.x.xxxx is the .NET version.


d Search for the aspnet.config file.

2 Modify the .NET Agent configuration in the aspnet.config file by adding the lines shown in bold below, where <upgradedAgentVersion> is the new Introscope .NET Agent version:

<runtime><assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

<dependentAssembly><assemblyIdentity name="wily.Agent"

publicKeyToken="2B41FDFB6CD662A5" /><bindingRedirect oldVersion="8.1.0.0"

newVersion="<upgradedAgentVersion>" /><codeBase version="<upgradedAgentVersion>" href="file:///

<Agent_Home>\\bin\\wily.Agent.dll"/></dependentAssembly>

</assemblyBinding></runtime>

» Note In order for the .NET Agent to work properly, the statement <assemblyBinding xmlns="urn:schemas-microsoft-

com:asm.v1"> must be inside <runtime>. In addition, <dependentAssembly> must be under <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">.

3 Restart the IIS application server.

Introscope SPM Agent extension configuration properties 319

APPENDIX B

Introscope SPM Agent extension configuration properties

This appendix includes the following topics:

Introscope SPM Agent extension configuration . . . . . . . . . 320

Introscope SPM Agent extension configuration properties . . . . . . 321

320 Introscope SPM Agent extension configuration properties


Introscope SPM Agent extension configuration» Note The application server for the Introscope SPM Agent extension must be

restarted before some properties changes can take effect.

The Introscope SPM Agent extension properties are stored in the agent profile, IntroscopeAgent.profile, which is a text properties file. The agent searches for the agent profile as follows:

1 The value of the Java system property com.wily.introscope.agentProfile is used as the configuration file name.

2 If the Java system property is com.wily.introscope.agentProfile, configuration file name of IntroscopeAgent.profile is used.

3 If configuration file name is relative, it resolves relative to the <Agent_Home> directory, which is typically called wily.

About Introscope SPM Agent extension properties

All Introscope SPM Agent extension property names start with com.wily.introscope.agent.

See Introscope SPM Agent extension configuration properties on page 321 for a list of all the Introscope SPM Agent extension configuration properties.



Introscope SPM Agent extension configuration properties

» Note The application server for the Introscope SPM Agent extension must be restarted before some property changes can take effect.

The following properties are defined in the IntroscopeAgent.profile file:

Property Definition/Default Notes

com.wily.introscope.agent.transactiontrace.boundaryTracing.enable

Enables or disables Transaction Trace boundary traces used to supply data needed to display the SOA Dependency Map.

If set to True:

The Introscope SPM Agent extension collects Transaction Trace bounder trace data required for the SOA Dependency Map and transmits it to the Enterprise Manager.

If set to False:

The Introscope SPM Agent extension does not collect Transaction Trace bounder trace data required for the SOA Dependency Map.

Default: True

Bounty traces are sent from the Introscope SPM Agent extension cache at a specific size to avoid overhead issues.

You must restart the managed application before changes to this property take effect.

com.wily.introscope.agent.transactiontrace.boundaryTracing.cacheFlushFrequency

Specifies the number of days that will pass before the Introscope agent memory cache next flushes all the dependency data.

Default: 30

Set this property to periodically flush idle threads to clear the Introscope agent cache. A cache flush results in the SOA Dependency Map dependency data being removed in the agent. The Introscope SPM agent then rediscovers the dependency data for display on the SOA Dependency Map.

When the agent fails over to a new Enterprise Manager in a non-clustered (no MOM) environment, set this property to 1 to flush the agent cache in one day.

Changes to this property take effect immediately and do not require the managed application to be restarted.



com.wily.introscope.agent.soapheaderinsertion.enabled

Enables or disables insertion of Introscope SPM SOAP header entries.

If set to True:

Introscope SPM adds client-side correlation and dependency information to the SOAP header.

If set to False:

Introscope SPM does not add client-side correlation and dependency information to the SOAP header.

The SOA Dependency Map does not display properly if this property is disabled and SOAP correlation information is added to the SOAP header (rather than added to the HTTP or JMS header).

Default: True

Set this property if your SOAP-based applications do not work properly due to unexpected header entries.





com.wily.introscope.agent.soa.metricNameFormatting

Replaces any denoted character or characters in Introscope SPM metric names with the underscore character [ _].

For example, setting com.wily.introscope.agent.soa.metricNameFormatting=/:

causes http://CheckingAccount/demobank.ca.com

to be displayed as

http_CheckingAccount_demobank.ca.com

If set to the character or characters to be replaced:

Introscope SPM metric name string characters are replaced with the underscore character.

If not set or has no value:

No Introscope SPM metric name string character substitution takes place.

Default: Not set

Set this property if you wish to substitute specified characters with '_' in the metric name.

You may want to make this substitution in order to display metric names in the format used in Web Services Manager 7.0. In this case, you must also replace namespace with servicename in the webservices.pbd file. These changes result in Introscope SPM metric names displaying in the Investigator tree and SOA Dependency Map using service name rather than namespace.

For more information, see Upgrading Web Services Manager to Introscope SPM on page 56.



Introscope SPM EM extension configuration properties 325

APPENDIX C

Introscope SPM EM extension configuration properties


Introscope SPM EM extension configuration . . . . . . . . . . 326

Introscope SPM EM extension properties . . . . . . . . . . . 327

326 Introscope SPM EM extension configuration properties


Introscope SPM EM extension configurationOut-of the-box, CA Wily SOA Performance Management provides the Introscope SPM EM extension properties with the default settings. Before you configure an Introscope SPM EM extension property, first you must add the property name to the IntroscopeEnterpriseManager.properties file.

» Note The Enterprise Manager must be restarted before some Introscope SPM EM extension property changes take effect.

To add an Introscope SPM EM extension property to IntroscopeEnterpriseManager.properties:

1 Open the IntroscopeEnterpriseManager.properties file in the <EM_Home>/config directory.

2 Add the property to the IntroscopeEnterpriseManager.properties file.

a Find the property in the table below that you want to add to the IntroscopeEnterpriseManager.properties file.

See Introscope SPM EM extension properties on page 327.

b Copy the Introscope SPM EM extension property name from the table and paste it into the IntroscopeEnterpriseManager.properties file.

c Add the default or updated property value.

For example here’s the default setting for this property:com.wily.introscope.soa.dashboard.typeviewer.mostcritical.count=10


The Introscope SPM EM extension property is added to IntroscopeEnterpriseManager.properties.

Once an Introscope SPM EM extension property has been added to the IntroscopeEnterpriseManager.propertiesfile already, you can configure the property as necessary.

To configure an Introscope SPM EM extension property:

1 Find the property in the table below that you want to configure.

See Introscope SPM EM extension configuration on page 326.

2 Configure the property in the IntroscopeEnterpriseManager.properties file.

a If necessary, open the IntroscopeEnterpriseManager.properties file in the <EM_Home>/config directory.

b Configure the Introscope SPM EM extension property as appropriate.

Introscope SPM EM extension configuration 327


For example, change the default setting for a property such as:com.wily.introscope.soa.dashboard.typeviewer.mostcritical.count=10

to a setting appropriate for your environment.

com.wily.introscope.soa.dashboard.typeviewer.mostcritical.count=15

» Note The example above is an explanation only and not a CA Wily SOA Performance Management setting recommendation.


The Introscope SPM EM extension property is configured

Introscope SPM EM extension properties

You can configure the following Introscope SPM EM extension properties by adding them to and updating the property values in the IntroscopeEnterpriseManager.properties file


com.wily.introscope.soa.dependencymap.aging.refresh.interval

Specifies the number of hours that will pass before the Enterprise Manager performs the next SOA Dependency Map dependency aging check.

The Enterprise Manager tracks the age of each discovered dependency, and periodically rediscovers dependencies to make sure they still exist. The age of a dependency is based in its most recent discovery.

During the SOA Dependency Map dependency aging check, the Enterprise Manager determines the age of each dependency across the SOA Dependency Map.

A SOA Dependency Map refresh interval is defined as 1 hour. Therefore, six SOA Dependency Map refresh intervals would last 6 hours.

Default: 6

This property works in conjunction with the com.wily.introscope.soa.dependencymap.aging.expire.interval property (see below).

Changes to this property take effect immediately and do not require the Enterprise Manager to be restarted.



com.wily.introscope.soa.dependencymap.aging.expire.interval

The maximum age, in days, of a dependency in the SOA Dependency Map. During the dependency aging check, the Enterprise Manager removes from the SOA Dependency Map all dependencies older than the specified value.

For example, if com.wily.introscope.soa.dependencymap.aging.expire.interval has a value of of 60 days, then an expired (and removed) dependency is one that has not been re-discovered during the previous 60 days.

Default: 60

This property works in conjunction with the com.wily.introscope.soa.dependencymap.aging.refresh.interval property (see above).

This property determines the criteria for removing a dependency which is then applied during the SOA Dependency Map dependency aging check.


com.wily.introscope.soa.dependencymap.heuristics.clientside.enable

Enables or disables the Introscope SPM client-side logical equivalence heuristics rule.

If set to True:

Enables the Introscope SPM client-side logical equivalence heuristics rule.

If set to False:

Disables the Introscope SPM client-side logical equivalence heuristics rule.

Default: True

The Introscope SPM client-side logical equivalence heuristics rule states that two physical web service operations of type client are considered logically equivalent, if and only if, both operations depend on the same physical web service operation of type server.

This can happen when two different applications make the same client-side web service operation call. This rule detects this logical equivalence when the two operations both do and do not have the same metric path (not including the agent specifier).

If this rule is changed, the change is not retrospectively applied to previously discovered dependencies. Therefore, changing the rule value may have unpredictable results unless the Enterprise Manager is stopped and both the previously saved SOA Dependency Map file types are deleted. For more information, see To delete, move, or rename the saved SOA Dependency Map file: on page 158.





com.wily.introscope.soa.dependencymap.heuristics.namematch.enable

Enables or disables the Introscope SPM logical equivalence heuristics name match rule.

If set to True:

Enables the Introscope SPM logical equivalence heuristics name match rule.

If set to False:

Disables the Introscope SPM logical equivalence heuristics name match rule.

Default: False

The Introscope SPM logical equivalence heuristics name match rule detects logical equivalence when the two operations have the same metric path (not including the agent specifier).

The Introscope SPM logical equivalence heuristics name match rule states that two physical web service operations with the same metric path after deletion of the agent specifier are considered as logically equivalent.


If you create a Virtual Agent in Introscope SPM, you should enable this property. See Configuring virtual agents for Introscope SPM on page 54.





com.wily.introscope.soa.dependencymap.heuristics.serverside.enable

Enables or disables the Introscope SPM server-side logical equivalence heuristics rule.

If set to True:

Enables the Introscope SPM server-side logical equivalence heuristics rule.

If set to False:

Disables the Introscope SPM server-side logical equivalence heuristics rule.

Default: True

The Introscope SPM server-side logical equivalence heuristics rule states that two physical web service operations of type server are considered logically equivalent, if and only if, there exists some physical web service operation of type client that depends on both operations.

Typically this will only happen when the SOA incorporates some kind of load-balancing mechanism such that a client-side web service operation call is dispatched to one of several available server-side web service operation implementations



com.wily.introscope.soa.deviation.enable

Enables or disables the deviation metrics, which are: Average Response Time Deviation, Errors Per Interval Deviation, and Responses Per Interval Deviation. Determines if the Introscope SPM deviation metrics are reported.

If set to True:

Introscope SPM performs calculations to provide deviation metric data.

If set to False:

None of the deviation metrics are reported.

Default: True

You must restart the Enterprise Manager before changes to this property take effect.




com.wily.introscope.soa.deviation.art.enable

Enables or disables the Average Response Time deviation metrics.

If set to True:

Introscope SPM performs calculations to provide Average Response Time Deviation metric data.

If set to False:

Introscope SPM does not perform the Average Response Time Deviation calculations.

Default: True

Each deviation metric (Average Response Time Deviation, Errors Per Interval Deviation, or Responses Per Interval Deviation) reported by the deviation metric service can be individually turned on (enabled) or off (disabled).


com.wily.introscope.soa.deviation.dependencymetric.enable

Enables or disables the dependency metrics, which are: Critical Direct, Critical Indirect, Dependency Direct, Dependency Indirect, Average Response Time Deviation, Errors Per Interval Deviation, and Responses Per Interval Deviation.

Determines if the Introscope SPM dependency metrics are reported.

If set to True:

Introscope SPM performs calculations to provide dependency metric data.

If set to False:

Introscope SPM does not perform dependency metric calculations.

Default: True


com.wily.introscope.soa.deviation.count.per.metric

The number of operations per deviation metric.

Use this property to limit the number of metrics created per deviation metric type.

Deviation metric types are Average Response Time Deviation, Errors Per Interval Deviation, and Responses Per Interval Deviation.

Default: 25





com.wily.introscope.soa.deviation.dependency.refreshrate

Frequency in hours that cached SOA Dependency Map dependency relationship data is refreshed.

The SOA Dependency Map data is cached by the deviation metric service. Critical, dependent, and deviation metrics are reported for these service and operations every 15 seconds.

The cached SOA Dependency Map data is periodically refreshed based on this property.

This map rarely changes and usually does so only if the deployment is changed.

Default: 1 hour


com.wily.introscope.soa.deviation.errors.enable

Enables or disables the errors deviation metrics. Determines if the Introscope SPM errors deviation metrics are reported.

If set to True:

Introscope SPM performs calculations to provide error deviation metric data.

If set to False:

None of the errors deviation metrics are reported.

Default: True

Each deviation metric (Average Response Time Deviation, Errors Per Interval Deviation, or Responses Per Interval Deviation) reported by the deviation metric service can be individually turned on (enabled) or off (disabled).


com.wily.introscope.soa.deviation.max.metric.count

Maximum number of total deviation metrics reported.

Default: 1000

» Important CA Wily Technology does not recommend changing the default value of this property. The default value reports enough metrics to provide useful information without affecting Enterprise Manager performance. If you change the default value, the Enterprise Manager may experience performance issues.





com.wily.introscope.soa.deviation.metric.expressionlist

Defines a list of names for deviation metric expressions. These names are user defined in a comma separated list.

Each name is used as a separate metric expression.

This property is referenced by the deviation.metric.calledbackends property to create user-defined deviation metrics.

Default: calledbackends

Example:deviation.metric.expressionlist=al

pha1, beta2, gama3


com.wily.introscope.soa.deviation.metric.calledbackends

Uses the names defined in the deviation.metric.expressionlist property (above) to form a new property.

The new property name has the following format:com.wily.introscope.soa.deviation.

metric.<user defined name from deviation.metric.expressionlist> = <user defined regular expression>

The value assigned to the deviation.metric.calledbackends property is the metric expression. For example:

Examples: com.wily.introscope.soa.deviation.metric.alpha1=Frontends|Called Backends

com.wily.introscope.soa.deviation.metric.calledbackends=Frontends|Frontends|FBApp$Frontend|Called Backends|FBApp$Backend





com.wily.introscope.soa.deviation.usage.enable

Enables or disables the Responses Per Interval deviation metrics.

Determines if the Introscope SPM Responses Per Interval deviation metrics are reported.

If set to True:

The Responses Per Interval deviation metrics are reported.

If set to False:

None of the Responses Per Interval deviation metrics are reported.

Default: True


com.wily.introscope.soa.dashboard.typeviewer.average.enable

Enables the data for a selected operation to display the Average Response Time Deviation graph in these Introscope SPM UI components: SOA Performance - Most Critical

Operations dashboard SOA Performance - Most Dependent

Operations dashboard Most Critical tab Most Dependent tab

If set to True:

The data for the selected operation displays in the Average Response Time Deviation graph.

If set to False:

The data for the selected operation in the Average Response Time Deviation graph does not display.

Default: True

Deviation data is available only if it is if reported by the agent to the Enterprise Manager, then displayed in the Investigator. See the definition of the Average Response Time Deviation metric on page 118.

If this property is also in the IntroscopeWorkstation.properties file, the IntroscopeWorkstation.properties property overrides this property.





com.wily.introscope.soa.dashboard.typeviewer.response.enable

Enables the data for a selected operation to display in the Responses Per Interval Deviation graph in these Introscope SPM UI components: SOA Performance - Most Critical



If set to True:

The data for the selected operation displays in the Responses Per Interval Deviation graph.

If set to False:

The data for the selected operation in the Responses Per Interval Deviation graph does not display.

Default: True




com.wily.introscope.soa.dashboard.typeviewer.errors.enable

Enables the data for a selected operation to display in the Errors Per Interval Deviation graph in these Introscope SPM UI components: SOA Performance - Most Critical



If set to True:

The data for the selected operation displays in the Errors Per Interval Deviation graph.

If set to False:

The data for the selected operation in the Errors Per Interval Deviation graph does not display.

Default: True







com.wily.introscope.soa.dashboard.typeviewer.mostcritical.enable

Displays the Most Critical Operations dashboard in the Console and the Most Critical tab in the Investigator.

If set to True:

The SOA Performance - Most Critical Operations dashboard option appears in the drop-down menu and the Most Critical tab appears in the Investigator.

If set to False:

The Most Critical Operations dashboard option displays in the drop-down menu, but no dashboard appears. Instead, an error message appears that states: This dashboard is not available.To view it, set the com.wily.introscope.soa.dashboard.typeviewer.mostcritical.enable property to true. Additionally, the Most Critical tab does not appear in the Investigator.

Default: True



com.wily.introscope.soa.dashboard.typeviewer.mostdependent.enable

Displays the Most Dependent Operations dashboard in the Console and the Most Dependent tab in the Investigator.

If set to True:

The SOA Performance - Most Dependent Operations dashboard option appears in the drop-down menu and the Most Dependent tab appears in the Investigator.

If set to False:

The Most Dependent Operations dashboard option displays in the drop-down menu, but no dashboard appears. Instead, an error message appears that states: This dashboard is not available.To view it, set the com.wily.introscope.soa.dashboard.typeviewer.mostdependent.enable property to true. Additionally, the Most Dependent tab does not appear in the Investigator.

Default: True






com.wily.introscope.soa.dashboard.typeviewer.mostcritical.count

Determines the total number of critical operations reported by all agents in the SOA Performance - Most Critical Operations dashboard and the Most Critical tab.

The minimum value is 0 and the maximum value should be less than or equal to the value of the com.wily.introscope.soa.deviation.count.per.metric property, which has a default value of 25.

Default: 10



com.wily.introscope.soa.dashboard.typeviewer.mostdependent.count

Determines the total number of most dependent operations reported by the agents in the SOA Performance - Most Dependent Operations dashboard and the Most Dependent tab. The minimum value is 0 and the maximum value should be less than or equal to the value of the com.wily.introscope.soa.deviation.count.per.metric property, which has a default value of 25.Default: 10




Introscope SPM Workstation configuration properties 339

APPENDIX D

Introscope SPM Workstation configuration properties


Introscope SPM Workstation configuration . . . . . . . . . . . 340

IntroscopeWorkstation.properties file properties . . . . . . . . . 342

340 Introscope SPM Workstation configuration properties


Introscope SPM Workstation configurationOut-of the-box, CA Wily SOA Performance Management provides the Introscope SPM Workstation extension properties with the default settings. Before you configure an Introscope SPM EM Workstation property, first you must add the property name to the IntroscopeWorkstation.properties file.

» Note The Workstation must be restarted before some Introscope SPM Workstation property changes take effect.

To add an Introscope SPM Workstation property to IntroscopeWorkstation.properties:

1 Open the IntroscopeWorkstation.properties file in the <EM_Home>/config directory.

2 Add the property to the IntroscopeWorkstation.properties file.

a Find the property in the table below that you want to add to the IntroscopeWorkstation.properties file.

See IntroscopeWorkstation.properties file properties on page 342.

b Copy the Introscope SPM Workstation property name from the table and paste it into the IntroscopeWorkstation.properties file.

c Add the default or updated property value.

For example here’s the default setting for this property:com.wily.introscope.soa.dashboard.typeviewer.mostcritical.count=

10

3 Save and close the IntroscopeWorkstation.properties file.

The Introscope SPM Workstation property is added to IntroscopeWorkstation.properties.

Once an Introscope SPM Workstation property has been added to the IntroscopeWorkstation.propertiesfile already, you can configure the property as necessary.

To configure an Introscope SPM Workstation property:

1 Find the property in the table below that you want to configure.

See Introscope SPM Workstation configuration on page 340.

2 Configure the property in the IntroscopeWorkstation.properties file.

a If necessary, open the IntroscopeWorkstation.properties file in the <EM_Home>/config directory.

b Configure the Introscope SPM Workstation property as appropriate.

Introscope SPM Workstation configuration 341


For example, change the default setting for a property such as:com.wily.introscope.soa.dashboard.typeviewer.mostcritical.count=

10

to a setting appropriate for your environment.

com.wily.introscope.soa.dashboard.typeviewer.mostcritical.count=

15

» Note The example above is an explanation only and not a CA Wily SOA Performance Management setting recommendation.

3 Save and close the IntroscopeWorkstation.properties file.

The Introscope SPM Workstation property is configured.



IntroscopeWorkstation.properties file properties

The following properties are defined in the IntroscopeWorkstation.properties file.


com.wily.introscope.soa.dependencymap.ui.view.nodecount

The maximum number of map nodes that display on the SOA Dependency Map.

If you select an Investigator node, and the number of Introscope SPM SOA Dependency Map nodes exceeds the com.wily.introscope.soa.dependencymap.ui.view.nodecount value, an error message displays, but no SOA Dependency Map displays.

If you go to a new view and the number of Introscope SPM SOA Dependency Map nodes exceeds the com.wily.introscope.soa.dependencymap.ui.view.nodecount value, an error message displays, but no SOA Dependency Map displays, and the SOA Dependency Map reverts back to the previous view.

For example, if you change from the Physical Agent to the Physical Services view, and the node count limit is exceeded, the SOA Dependency Map displays the error message and reverts back to the Physical Agent view.

However, if you expand the ShowAllOperations or ShowAllServices view and the node count value is exceeded, the SOA Dependency Map displays the error message and displays any recently-added SOA Dependency Map nodes.

Default: 500

You must restart the Workstation before changes to this property take effect.



com.wily.introscope.soa.dashboard.typeviewer.average.enable

Enables the data for a selected operation to display the Average Response Time Deviation graph in these Introscope SPM UI components: SOA Performance - Most Critical Operations

dashboard SOA Performance - Most Dependent


If set to True:

The data for the selected operation displays in the Average Response Time Deviation graph.

If set to False:

The data for the selected operation in the Average Response Time Deviation graph does not display.

Default: True

Deviation data is available only if it is if reported by the agent to the Enterprise Manager, then displayed in the Investigator. See Using the Deviations tab on page 118.

If this property is also in the IntroscopeEnterpriseManager.properties file, the IntroscopeWorkstation.properties property overrides the IntroscopeEnterpriseManager.properties property.


com.wily.introscope.soa.dashboard.typeviewer.response.enable

Enables the data for a selected operation to display in the Responses Per Interval Deviation graph in these Introscope SPM UI components: SOA Performance - Most Critical Operations



If set to True:

The data for the selected operation displays in the Responses Per Interval Deviation graph.

If set to False:

The data for the selected operation in the Responses Per Interval Deviation graph does not display.

Default: True







com.wily.introscope.soa.dashboard.typeviewer.errors.enable

Enables the data for a selected operation to display in the Errors Per Interval Deviation graph in these Introscope SPM UI components: SOA Performance - Most Critical Operations



If set to True:

The data for the selected operation displays in the Errors Per Interval Deviation graph.

If set to False:

The data for the selected operation in the Errors Per Interval Deviation graph does not display.

Default: True




com.wily.introscope.soa.dashboard.typeviewer.mostcritical.enable

Displays the Most Critical Operations dashboard in the Console and the Most Critical tab in the Investigator.

If set to True:

The SOA Performance - Most Critical Operations dashboard option appears in the drop-down menu and the Most Critical tab appears in the Investigator.

If set to False:

The Most Critical Operations dashboard option displays in the drop-down menu, but no dashboard appears. Instead, an error message appears that states: This dashboard is not available.To view it, set the com.wily.introscope.soa.dashboard.typeviewer.mostcritical.enable property to true. Additionally, the Most Critical tab does not appear in the Investigator.

Default: True






com.wily.introscope.soa.dashboard.typeviewer.mostdependent.enable

Displays the Most Dependent Operations dashboard in the Console and the Most Dependent tab in the Investigator.

If set to True:

The SOA Performance - Most Dependent Operations dashboard option appears in the drop-down menu and the Most Dependent tab appears in the Investigator.

If set to False:

The Most Dependent Operations dashboard option displays in the drop-down menu, but no dashboard appears. Instead, an error message appears that states: This dashboard is not available.To view it, set the com.wily.introscope.soa.dashboard.typeviewer.mostdependent.enable property to true. Additionally, the Most Dependent tab does not appear in the Investigator.

Default: True



com.wily.introscope.soa.dashboard.typeviewer.mostcritical.count

Determines the total number of critical operations reported by all agents in the SOA Performance - Most Critical Operations dashboard and the Most Critical tab.

The minimum value is 0 and the maximum value should be less than or equal to the value of the com.wily.introscope.soa.deviation.count.per.metric property, which has a default value of 25.

Default: 10






com.wily.introscope.soa.dashboard.typeviewer.mostdependent.count

Determines the total number of most dependent operations reported by the agents in the SOA Performance - Most Dependent Operations dashboard and the Most Dependent tab. The minimum value is 0 and the maximum value should be less than or equal to the value of the com.wily.introscope.soa.deviation.count.per.metric property, which has a default value of 25.Default: 10



introscope.workstation.soa.dependencymap.fetchmetrics

Controls the display of the metrics in the SOA Dependency Map.

If set to True:

The Workstation requests from the Enterprise Manager and displays on the SOA Dependency Map map nodes the metrics based on your selections in the Primary Map Metric and Tooltips dropdown lists.

If set to False:

The Workstation does not request from the Enterprise Manager and does not display on the SOA Dependency Map map nodes the metrics based on your selections in the Primary Map Metric and Tooltips dropdown lists.

Default: True



Index 347

INDEX

Index

Symbols.NET

Agentconfiguring for cross-process transaction

tracing 186required configuration after upgrade 317version required for ASP.NET 29, 60, 69version required for WCF 29, 60, 69

Agent extensionsconfiguring 42installing 41uninstalling 47

Aadding a filter 199Additional dependencies not found 169Agent extensions

.NETconfiguring 42installing 41uninstalling 47

about 34configuration propertiesIntroscopeAgent.pro-file, Java Agent extension configurationproperties 319

Javadeploying 38, 53, 64, 75, 79extracting 35, 63, 72uninstalling 39, 65, 78, 81

supported native SOAP engines 34agents

.NETconfiguring for cross-process transaction

tracing 186disconnected 158, 179greyed out 179

renaming 179requirements 26virtual, configuring for Introscope SPM 54

alert states, numerical meaning in Introscope138

applicationOverview tab 94servers, supported natively 34solving problems using cross-process transac-tion trace 188

applications 147asynchronous web service invocation response

times 98average response time

interpreting 98

Bback-ends 147Blame. See Boundary BlameBoundary Blame, about 128Busiest Operations

dashboard 104

Cchecklists, for installation 29, 60, 69client

Dependencies tab 116Deviations tab 122health

causes of slowness 97dashboard 99

nodeDependencies tab display 114Deviations tab display 119

Overview tab 94, 107web services, definition 17

348 Index


client-server dependency relationships 147CLR

boundaries and cross-process transactiontracing 186

relationship to web services client and server17

clustered Introscope environment 172Collectors 173complex filters 200components, seeing Blamed in Investigator tree

128configuring

Agent extension properties 319EM extension 325, 339

content typeServices 162

correlated eventsdefinition 201viewing 201

cross-process transactionJava to .NET 194Java to Java 191tracing

and JVM/CLR boundaries 186definition 186how to configure for .NET Agent 186

viewing to solve problems 188

Ddashboard

Busiest Operations 104Most Dependent

Operations 102dashboards

Client Health 99Most Critical

Operations 101Overview, interpreting 97Server Health 100, 102, 104SOA Performance Overview 96

debugging options 56Dependencies

tab 114, 115dependencies 147

SOA 156Dependency Direct 161dependency relationships 146dependencymap.bak 157

dependencymap.sav 157deployment, verifying 55Deviations

tab 120tabs 118

disconnected agents 158, 179discover web services 157documentation, Introscope 23

EEM extension

configuring 326, 340extracting 50, 66, 82, 85uninstalling 53, 68, 84, 87

endpoints, running Transaction Traces against203

Enterprise Architect 177Enterprise Manager 156, 157, 158, 159, 174,

179disconnected agent 158rediscover all SOA dependencies 157

environmentsheterogeneous, defined 186homogeneous, defined 186

errormessages

viewing for SOAP faults 206snapshot pane 206

ErrorDetectorerrors per interval metric 132required installed version 29viewing

errormessages 206

SOAP faults 204web service errors 204

errorsper interval metric 129, 130tab, viewing 126viewing 126viewing historical in Workstation

historical 206viewing live in Workstation

live 205

Index 349


Ffailures, reasons for in web service invocations

16faults 147filters

adding 199complex 200removing 199setting 200

front-ends 147

Hhardware requirements 26health, determining for web services 140heterogeneous environment, defined 186homogeneous environment, defined 186

Iillustration

sample SOA implementation 13, 14installation

checklists 29, 60, 69directory name conventions 27ErrorDetector prerequisite, version 29Introscope prerequisite, version 29, 60, 69overview 26prerequisites 29summary of steps 31

Introscope.NET Agent

upgrade configuration changes 317version required 40

Agent requirements 26documents you need 23Investigator WebServices node, defined 94metrics 159required installed version 29, 60, 69viewing web services metrics

in Investigator 128Workstation, starting 95

Introscope SPMAgent extension 156, 174management modules file name 51metrics 159OSB

management module filename 67uninstalling 59WPS

management module filename 83IntroscopeAgent.profile 179Investigator 161, 163, 164, 169, 175, 176

JJava Agent extensions, extracting 35, 63, 72Jump here in tree 171JVM, boundaries and cross-process transaction

tracing 186

Llogical

equivalence 184heuristics 157

view 166

Mmanagement modules

file name for Introscope SPM 51file name for Introscope SPM OSB 67file name for Introscope SPM WPS 83upgrading 57

managerSoapEndpoint, property defined 328,342

map. See SOA Dependency Mapmax metric count, parameter defined 332method Overview tab 94, 109metrics 159

errors per interval 129, 130SOAP faults per interval 128, 129, 131web services, viewing per agent 132

MOM 172SOA Dependency Map 172

Most CriticalOperations

dashboard 101tab 124, 125tabs 124

Most DependentOperations dashboard 102tab 125

350 Index


Nname conventions, for installation directories

27namespace node

Dependencies tab display 114Deviations tab display 119

namespacesDependencies tab 117Deviations tab 123

node, WebServices 94

Ooperation Overview tab 94, 109operations 147options, debugging 56OSB 146Overview

dashboard, SOA Performance 96tabs 105

Ppartial dependency map 156physical view 166prerequisites

.NET Agent extension 40, 56ErrorDetector version 29installation 29Introscope version 29, 60, 69Java agent extension 38, 64, 75

Primary metric 159setting 160

Rreal-time dependency relationships 146removing a filter 199renaming agent, and SOA Dependency map up-

dating 179requirements

hardware/software for installation 26Introscope Agent 26

response timesasynchronous web service invocations 98interpreting 98synchronous web service invocations 98

Sserver

causes of slowness 97

Dependencies tab 116Deviations tab 122health, dashboard 100, 102, 104node

Dependencies tab display 114Deviations tab display 119

Overview tab 94, 107web services, definition 17

service-oriented architecture. See SOAservices 147, 162setting a filter 200size, setting max SOAP size property 321SOA

about 12dependencies 156implementation, illustration 13, 14

SOA Dependency Map 146, 147, 148, 156Add Dependencies 156Additional dependencies not found 169changing the view 171choose a view 166choosing a content type 161choosing content 159components 151

Agent icon 154Agent name 153Arrow showing one web service item call-

ing another 153Client operation icon 152, 154Client operation name 152Client Service icon 154Client service icon 154Client service name 153Content type dropdown list 152Fit to tab 153Magnify a selected area 153Pan tool 153Primary Metric dropdown list 152Primary Metric value 152Roll up Dependencies button 153Save as image button 153Scroll bar 153Server operation icon 153, 154Server operation name 153Server Service icon 154Server service icon 153SOA Dependency Map tab 152Tooltips button 152

Index 351


Unroll Dependencies button 153View dropdown list 152Zoom in and out 153

content type 148agent 148Agents 162operation 148operations 155service 148Services 162, 164

defaults 155FAQs 180from map to Investigator 171hide dependencies 169Introscope node 149Investigator 148logical view 166map node 155MOM 172node aging and removal 159output images 177Physical Agent view 172Physical Services view 173Physical view 155physical view 166saving the map 157setting the content type 165Show All Operations 155show all operations for a service 170show all services for an agent 170Show Next Dependency 156tab 147tasks 150tooltips metrics 161Transaction Trace 180triage 176unroll dependencies levels 169View dropdown list 166

SOA Performance Overview dashboard 96SOAP

engines, native, supported 34faults

per interval metric 128, 129, 131viewing error messages 206viewing in ErrorDetector 204

messagessetting max size 321

soapMessageSize, property defined 321

softwaredownload site 26requirements 26

standalone map nodes 164synchronous web service invocations, response

times 98

Ttabs

application Overview 94Client Dependencies 116Client Deviations 122Client Overview 94, 107Dependencies 115Dependencies, about 114Deviations 120Deviations, about 118Errors 126method Overview 94, 109Most Critical 124, 125Most Dependent 125namespaces Dependencies 117namespaces Deviations 123operation Overview 94, 109Overview, about 105Server Dependencies 116Server Deviations 122Server Overview 94, 107web services Overview 94, 108

tooltips 159, 160, 161metrics 161

Transaction Trace 180definitions of cross-process 186viewing to solve problems 188

Transaction Tracer 203transactions 147

tracking web services business 186

Uuninstalling

.NET Agent extensions 47EM extension 53, 68, 84, 87Introscope SPM 59Java Agent extensions 39, 65, 78, 81

upgrading.NET Agent, required configuration after 317management module 57

using Errors tab 126

352 Index


Vvariables, used in this guide 27verifying, deployment 55virtual agents

configuring for Introscope SPM 54definition 54

Wweb services 146, 156, 161

business transactions, tracking 186causes of client/server slowness 97client, definition 17determining health 140discover 157endpoints, running Transaction Trace against

203invocations, reasons for failures 16metrics

aggregated 135, 137viewing per agent 132

name node in Investigator 134operation name node 135overview of managing 12Overview tab 94, 108seeing in Transaction Tracer 203server, definition 17viewing in Investigator 128

webservices nodedefined 94Dependencies tab displaying on 114Deviations tab displaying on 119

Wily software download site 26Workstation 156, 158, 174, 175

starting 95using to view errors

historical 206live 205

WPS/WESB 146

8.1 soaperformancemanagement

Documents