8.1 Soaperformancemanagement

CA Wily Introscope SOA Performance Management
Implementation Guide
Version 8.1
Date: 04-2009
Date: 04-2009
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 support@wilytech.com. 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 wily-techpubs@ca.com.
6000 Shoreline Court, Suite 300 South San Francisco, CA 94080
US Toll Free 888 GET WILY ext. 1 US +1 630 505 6966 Fax +1 650 534 9340 Europe +44 (0)870 351 6752 Asia-Pacific +81 3 6868 2300 Japan Toll Free 0120 974 580 Latin America +55 11 5503 6167 www.ca.com/apm
CONTENTS
Table of Contents
Chapter 1
Introducing CA Wily Introscope SOA Performance Management 11 About SOA and web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 13 16 17 18 21 21 21 23 How Introscope SPM helps you manage SOA-based applications About what Introscope SPM monitors . Introscope SPM components . . . . How Introscope SPM monitors SOA-based applications . Introscope SPM components for monitoring OSB . Capabilities of Introscope SPM by component . Additional Introscope documentation . . . . . . . . . .
Introscope SPM components for monitoring WPS and WESB .
Chapter 2
Installing and configuring Introscope SPM Introscope SPM installation overview . . . . . . Hardware and software requirements .
. 25 . . . . . . . . . . . . . . . . 26 26 27 27 29 29 31 32 34 34 35 38 39 40 42 47
Introscope SPM Agent extension requirements .
Installation machine and directory names with documentation conventions . . . . . . . . . . . . . . . . . . Introscope SPM install prerequisites Installation prerequisite checklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary of Introscope SPM installation steps About Agent extensions . . . . . . . . . . . .
Downloading and extracting the installation archives Categories of Agent extensions
Extracting Windows, Unix, and z/OS Java Agent extensions . Configuring Introscope SPM Java Agent extensions . Uninstalling Introscope SPM Java Agent extensions . Configuring Introscope SPM .NET Agent extensions Uninstalling Introscope SPM .NET Agent extensions .
Extracting and configuring Introscope SPM .NET Agent extensions .
Contents iii
SOA Performance Management
Extracting Introscope SPM EM extensions
. . . . . .
. . . . . . .
. . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
50 53 53 54 55 56 56 59
Configuring Introscope SPM EM extensions . Uninstalling Introscope SPM EM extensions . Verifying your deployment . . . . . . .
Configuring virtual agents for Introscope SPM . Agent and EM extension debugging options . Uninstalling Introscope SPM . . . . . .
Upgrading Web Services Manager to Introscope SPM
Installing and configuring Introscope SPM OSB Agent and EM extensions 60 Downloading and extracting the Introscope SPM OSB installation archive . . . . . . . . . . . . . . . . . . . . . Extracting Introscope SPM OSB Agent extensions . Configuring Introscope SPM OSB Agent extensions Uninstalling Introscope SPM OSB Agent extensions Extracting Introscope SPM OSB EM extensions . Uninstalling Introscope SPM OSB EM extensions Verifying your Introscope SPM OSB deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 63 64 65 66 68 68 69 70 72 75 78 79 81 82 84 85 87
Installing and configuring Introscope SPM WPS/WESB Agent and EM extensions . . . . . . . . . . . . . . . . . . . . . Downloading and extracting the Introscope SPM WPS/WESB installation archive . . . . . . . . . . . . . . . . Extracting Introscope SPM WPS/WESB Agent extensions Configuring Introscope SPM WPS Agent extensions Uninstalling Introscope SPM WPS Agent extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuring Introscope SPM WESB Agent extensions . Uninstalling Introscope SPM WESB Agent extensions . Extracting Introscope SPM WPS EM extensions . Uninstalling Introscope SPM WPS EM extensions . . . . .
Extracting and configuring Introscope SPM WESB EM extensions. Uninstalling Introscope SPM WESB EM extensions .
Extracting and configuring WPS and WESB EM extensions on the same Enterprise Manager or MOM . . . . . . . . . . . . . . 88 Verifying your Introscope SPM WPS deployment . . . . . . . . . . . . . 89 90 Verifying your Introscope SPM WESB deployment .
iv Contents
Chapter 3
Monitoring web services .
. .
. .
. . . . .
. . . . . .
. . . . . .
. . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. 93 . . . . . 94 95 95 96 99
Viewing web services data in Introscope SPM . Starting the Introscope Workstation . SOA Performance Management dashboards . Introscope SPM Client Health dashboard . Introscope SPM Server Health dashboard .
Introscope SPM Performance Overview dashboard .
. 100 . 101 . 102 . 104 . 105 . 105 . 110 . 114 . 118 . 124 . 125 . 126 . 128 . 128 . 129 . 132 . 134 . 135 . 138 . 138 . 140 145
Introscope SPM Most Critical Operations dashboard . Introscope SPM Busiest Operations dashboard . SOA Performance Management tabs Using the Overview tabs . . . . . . . . . . . . . . . Using the Dependencies tabs . About the Dependencies tab Using the Deviations tab . . Using the Most Critical tab . Using the Errors tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introscope SPM Most Dependent Operations dashboard .
Using the Most Dependent tab .
Viewing web service metrics in the Investigator About Introscope SPM metrics . About error and SOAP fault metrics . Viewing agent web service metrics . About the web service name node About the operation name node . Interpreting alert states . . . .
Viewing Introscope SPM metric groupings and alerts. Checking the health of your web services Chapter 4
Using SOA Dependency Map to triage web service problems Getting to know the SOA Dependency Map . SOA Dependency Map Concepts . SOA Dependency Map components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 146 . 147 . 150 . 151 . 156 . 157 . 159
What can I accomplish using SOA Dependency Map? .
How Investigator tree nodes relate to SOA Dependency Map nodes . 155 How Introscope SPM creates the SOA Dependency Map . About how the SOA Dependency Map is saved . . . . . About SOA Dependency Map node aging and removal
Contents v
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 Choosing a SOA Dependency Map view . . . . . . . . . . . . . . . . . . 161 . 166
Using SOA Dependency Map views and content types to solve your problems . . . . . . . . . . . . . . . . . . . . . 167 Navigating the SOA Dependency Map . Unrolling dependencies levels . . . . . Rolling up to hide dependencies . Showing all services for an agent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 . 169 . 169 . 170 . 170 . 171 . 171 . 172 . 174 . 176 . 177 . 179 . 179 . 180 . 180 . 184 185 . 186 . 190 . 196 . 198 . 201 . 203 . 204 209 . 210
Showing all operations for a service .
Jumping from a SOA Dependency Map node to the associated Investigator tree node . . . . . . . . . . . . . . Panning, zooming, and fitting the SOA Dependency Map MOM SOA Dependency Map. . . . . . . . . . . . . . .
Reloading SOA Dependency Map upon discovery of new services and operations . . . . . . . . . . . . . . . . . . Using the SOA Dependency Map for triage . Disconnected agents are grayed out. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outputting SOA Dependency Map images for sharing .
How renaming an agent updates the SOA Dependency Map SOA Dependency Map FAQs . . . . . . . . . . . . . . . . . . .
Starting a Transaction Trace session from SOA Dependency Map About Introscope SPM logical equivalence Chapter 5
Using Transaction Tracing to triage web service problems About Introscope SPM cross-process transaction tracing Following an Introscope SPM transaction . Introscope SPM filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using cross-process transaction tracing to solve difficult problems . 188 Filtering Introscope SPM Transaction Traces .
Viewing correlated events using Transaction Tracer . Viewing web service data with Transaction Tracer. Viewing web service faults in ErrorDetector . Chapter 6 Monitoring Oracle Service Bus (OSB) . Using Introscope SPM to monitor OSB . . . . . . . .
vi Contents
Viewing OSB metrics . About OSB metrics .
. .
. .
. .
. .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 211 . 213 . 213 . 215 . 216 . 217 . 220 . 227 . 229 . 230 . 231 . 232 . 233 . 234 . 235 . 236 . 237 . 238 . 239 . 240 . 241 . 242 . 244 . 245 . 248 . 249 251 . 252 . 253 . 254 . 255 . 256 . 257 . 259 . 262 . 263 . 264
Viewing OSB tabs and metrics . Viewing Pipelines metrics . . . . . . .
Viewing Business Services metrics . Viewing Proxy Services metrics Viewing Transports metrics . Viewing UDDI metrics . Viewing OSB dashboards OSB Home Dashboard . . . . . . . Viewing XQueries metrics
OSB Proxy Services - Overview dashboard OSB Proxy Services - Details dashboard . OSB Pipelines - Overview dashboard . .
OSB Business Services - Overview dashboard . OSB Transports I - Overview dashboard . OSB Transports II - Overview dashboard . OSB XQuery - Overview dashboard . OSB UDDI - Overview dashboard . Viewing and creating OSB alerts . Following an OSB transaction . . . . . . . . . . . . . . . .
OSB Transports Endpoints - Overview dashboard .
Viewing and creating OSB metric groupings . About OSB cross-process transaction tracing Viewing an OSB Transaction Trace .
Viewing correlated events using Transaction Tracer . Chapter 7 Monitoring WebSphere Process Server (WPS) Using Introscope SPM to monitor WPS and WESB . About WPS and WESB component metrics WPS and WESB shared components . WPS-specific components . . . . . . . . . . About WPS and WESB metrics Viewing WPS tabs and metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Business Processes metrics . Viewing Business Rules metrics Viewing Human Tasks metrics . . . . .
Viewing Business State Machines metrics .
Contents vii
Viewing Interface Maps metrics Viewing Selectors metrics WPS Faults . . . . . . . . .
. . . . .
. . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. 265 . 266 . 268 . 269 . 271 . 271 . 272 . 274 . 276 . 277 . 279 . 283 . 284 . 284
Viewing WESB tabs and metrics . Viewing Relationships metrics .
Viewing WPS and WESB shared component metrics . Viewing Java Components metrics Viewing Adapters metrics . . . .
Viewing Business Objects Maps metrics Viewing Data Bindings metrics.
Viewing Mediation Flow and Primitives metrics . Viewing WPS and WESB Dashboards . Viewing WPS dashboards . WPS Overview dashboard . . . . . . . .
WPS Business Processes & State Machines (Service Components I) dashboard . . . . . . . . . . . . . . . . . . . . . 285 WPS Business Rules & Human Tasks (Service Components II) dashboard . . . . . . . . . . . . . . . . . . . WPS Interface Maps, BO Maps, & Relationships dashboard . WPS Selectors & Java Components dashboard . WPS Data Bindings dashboard . WPS Adapters dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 . 287 . 288 . 289 . 290 . 291 . 293 . 294 . 294 . 295 . 297 . 298 . 299 . 300 . 301 . 302 . 304 . 308 . 309 . 316
WESB Mediation Flows dashboard Viewing WESB dashboards . . . . . .
WESB Mediation Primitives dashboard . WESB Overview dashboard .
WESB Mediation Flows dashboard WESB Adapters dashboard . . .
WESB Mediation Primitives dashboard .
WESB BO Maps & Relationships dashboard WESB Data Bindings dashboard . WESB Java Components dashboard .
Viewing and creating WPS and WESB metric groupings . Viewing and creating WPS and WESB alerts . Following a WPS transaction . . . . . About WPS cross-process transaction tracing .
Viewing correlated events using Transaction Trace
viii Contents
Appendix A
Required configuration after Introscope .NET Agent install or upgrade 317 Reconfiguring after installing or upgrading the Introscope .NET Agent version . . . . . . . . . . . . . . . . . . . . . . . . 318
Appendix B
Introscope SPM Agent extension configuration properties Introscope SPM Agent extension configuration . . . . . . . . . . . . . . . . Introscope SPM Agent extension configuration properties .
. . . . . . . . . .
319 . 320 . 321 325 . 326 . 327 339 . 340 . 342 347
Appendix C
Introscope SPM EM extension configuration properties . Introscope SPM EM extension configuration . Introscope SPM EM extension properties . . . . . . . . . . . . .
Appendix D
Introscope SPM Workstation configuration properties . Introscope SPM Workstation configuration . . . . . . . . . . . . . . . . IntroscopeWorkstation.properties file properties
Index .
Contents ix
x Contents
CHAPTER
Introducing CA Wily Introscope SOA Performance Management
This chapter includes these topics: About SOA and web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 13 16 17 18 21 21 21 23
How Introscope SPM helps you manage SOA-based applications . About what Introscope SPM monitors Introscope SPM components . . . How Introscope SPM monitors SOA-based applications .
See Monitoring WebSphere Process Server (WPS) on page 251. . Introscope SPM components for monitoring OSB . Additional Introscope documentation . . . . Introscope SPM components for monitoring WPS and WESB
Introducing CA Wily Introscope SOA Performance Management 11
About SOA and web services

Classic 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 applicationsit 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.
12 Introducing CA Wily Introscope SOA Performance Management
Here are the components of a sample SOA implementation.
CA Wilys 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 problemswithout 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.
How Introscope SPM helps you manage SOA-based applications 13
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.
Drill down on the end user experience.
Drill down on SOA infrastructure availability and performance.
Drill down on back-end availability and performance.
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.
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 organizations 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.
How Introscope SPM helps you manage SOA-based applications 15
When an incident occursfor example, the response time for a particular web service slows due to thread pool starvationan 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 monitors

SOA 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.
Introscope SPM provides broad and deep SOA performance management capabilities, including monitoring and reporting metrics about whats 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 thats 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 serverit provides the price for the stock-quote client. A client and server of a web service usually reside in separate processesthat is, in Java Virtual Machines (JVMs) or Microsofts 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.
How Introscope SPM monitors SOA-based applications 17
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 components

Introscope 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 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.
Introscope SPM components 19
This figure illustrates how Introscope SPM monitors web services in web applications deployed on J2EE or .NET servers.
Web Service Metrics and Alerts
Thin Client Interface
Introscope Workstation
Introscope SPM Administrator
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 component

Introscope 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.
Capabilities of Introscope SPM by component 21
This table describes these capabilities and the associated Introscope SPM component. Product Component
Application Overview tab
Capability
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 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
Out-of-the-box SOA Performance Management dashboards
Product Component
Agent extension
Capability
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. You extract this software component that provides Introscope SPM-specific Introscope dashboards and tabs. 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 entitys trace, and run Transaction Traces against a web service URL. 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.
EM extension Transaction Tracer
SOA Dependency Map tab
Agent and EM extensions for OSB Agent and EM extensions for WPS and standalone WESB
You extract these software components that provide Introscope SPM OSBspecific Introscope dashboards and tabs. You extract these software components that provide Introscope SPM WPS or WESB-specific Introscope dashboards and tabs.
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
Capabilities of Introscope SPM by component 23
CHAPTER
Installing and configuring Introscope SPM
This chapter includes these topics: Introscope SPM installation overview Introscope SPM install prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 29 31 32 32 35 40 50 53 53 54 55 59 60
Summary of Introscope SPM installation steps
Downloading and extracting the installation archives Downloading and extracting the installation archives
Extracting Windows, Unix, and z/OS Java Agent extensions Extracting Introscope SPM EM extensions . Configuring Introscope SPM EM extensions . Uninstalling Introscope SPM EM extensions. Verifying your deployment . Uninstalling Introscope SPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Extracting and configuring Introscope SPM .NET Agent extensions
Configuring virtual agents for Introscope SPM .
Installing and configuring Introscope SPM OSB Agent and EM extensions .
Installing and configuring Introscope SPM WPS/WESB Agent and EM extensions 69
Installing and configuring Introscope SPM 25
Introscope SPM installation overview

This 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
Java Agent .NET Agent Enterprise Manager
Minimum Version Supported

8.1.0.0 8.1.0.0 8.1.0.0
The Enterprise Manager version must be later than or equal to the Agent version.
ErrorDetector 8.1
26 Installing and configuring Introscope SPM
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...
The directory where the Introscope Agent is installed. This is typically a directory called wily. The directory where the Introscope Enterprise Manager is installed. The installation directory of a third party product or type of application. For example, <SAP_Home> is the installation directory of SAP NetWeaver.
<Agent_Home>
<EM_Home> <ProductName_Home> <ApplicationType_Home>
Introscope SPM installation overview 27
This name convention...

Path separators: / Environment variables: $
refers to...
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. Introscope or Introscope SPM file name that includes a version-specific identifier. Here are some examples. You might read in this guide:
FileName<version><operating system or other identifier>.FileType
IntroscopeSOAPerformanceManagement <version>windows.zip
and see this file on the CA Wily Software Download site:
IntroscopeSOAPerformanceManagement V8.1.0.0windows.zip
You might read in this guide: com.wily.introscope.soa.tracefilters.common _<version>.jar and see this file on your machine:
com.wily.introscope.soa.tracefilte rs.common_8.1.0.0.jar
You might read in this guide:
com.wily.powerpacks.osb.emext.calc ulator_<version>.jar
and see this file on your machine:
com.wily.powerpacks.osb.emext.calc ulator_8.1.0.jar
Introscope SPM install prerequisites

Before 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 youre installing the .NET Agent extension (ASP.NET), check that you have
installed the Introscope .NET Agent version 8.1.0.0 or later.
If youre 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 youre 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 youre 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 youre 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.
Introscope SPM install prerequisites 29
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 directoryHome directory of your application server.
<Agent_Home> Agent home directoryInstallation 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. Machine Name Component
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
Want to install?
Note If youre 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.
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 youre 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 youre upgrading from Web Services Manager 7.2

See Upgrading Web Services Manager to Introscope SPM on page 56.
If youre installing in an Introscope cluster

If youre 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.
Summary of Introscope SPM installation steps 31
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, youll 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. Operating System
Installation Archive File Name
IntroscopeSOAPerformanceManagementV<version>windows.zip IntroscopeSOAPerformanceManagementV<version>unix.tar IntroscopeSOAPerformanceManagementV<version>zOS.tar IntroscopeSOAPerformanceManagementV<version>DotNet.zip

b Download the installation archive to a temp directory. 3 Extract the installation archive into the temp directory. Note If youre extracting in a Unix or z/OS environment, use the appropriate command in this table.
Operating System
Installation Archive Extract Command
Unix (AIX, Linux, Solaris) tar -xvf
IntroscopeSOAPerformanceManagementV<version>unix.tar
z/OS
tar -xvfo IntroscopeSOAPerformanceManagementV<version>zOS.tar
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: Operating System
Windows Java
Files that extract from the installation archive
Description
IntroscopeSOAPerformanceManagement Introscope SPM Java Agent IntroscopeSOAPerformanceManagement EM extension
V<version>Agent.windows.zip <version>EM.windows.zip
extension
Unix (AIX, Linux, Solaris)
IntroscopeSOAPerformanceManagement Introscope SPM Java Agent IntroscopeSOAPerformanceManagement EM extension
V<version>Agent.unix.tar V<version>EM.unix.tar
extension
z/OS
IntroscopeSOAPerformanceManagement Introscope SPM Java Agent
extension V<version>Agent.zOS.tar EM extension IntroscopeSOAPerformanceManagement V<version>EM.zOS.tar Windows .NET
IntroscopeSOAPerformanceManagement Introscope SPM Agent
extension (ASP.NET) for V<version>Agent.windows.zip .NET Agent IntroscopeSOAPerformanceManagement Introscope SPM Agent V<version>Agent.windows.wcf.zip extension (WCF) for .NET IntroscopeSOAPerformanceManagement Agent V<version>EM.windows.zip
EM extension
4 Download from the Software Download Site the Introscope SPM documentation. Choose the documentation archive appropriate for your environment from this table. Operating System
Documentation Archive File Name
IntroscopeSOAPerformanceManagementV<version>Docs.windows .zip IntroscopeSOAPerformanceManagementV<version>Docs.unix.ta r IntroscopeSOAPerformanceManagementV<version>Docs.zOS.tar IntroscopeSOAPerformanceManagementV<version>Docs.windows .zip
Downloading and extracting the installation archives 33
5 Extract the documentation files. Note If youre extracting documentation in a Unix or z/OS environment, use the appropriate command in this table. Install Archive Package
Unix (AIX, Linux, Solaris) z/OS
Documentation Archive Extract Command
tar -xvf IntroscopeSOAPerformanceManagementV<version>Docs.unix.tar tar -xvfo IntroscopeSOAPerformanceManagementV<version>Docs.zOS.tar
The installation and documentation archives are downloaded and extracted.
About Agent extensions

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 invocations. Based on your environment, you will install either a Java or .NET Introscope SPM Agent extension. If youre 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
Based on your operating system, proceed to the appropriate installation topic. Operating System
Go to this topic next
Extracting Windows, Unix, and z/OS Java Agent extensions on

page 35

page 35

page 35
Extracting and configuring Introscope SPM .NET Agent extensions on page 40
Extracting Windows, Unix, and z/OS Java Agent extensions

After you extract the Introscope SPM Agent extensions, youll 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, its a best practice to copy IntroscopeAgent.profile to a backup directory.
Extracting Windows, Unix, and z/OS Java Agent extensions 35
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 youre 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. Operating System
Windows Java Unix (AIX, Linux, Solaris) z/OS
Introscope SPM Agent Extension Archive
IntroscopeSOAPerformanceManagementV<version>Agent.windows.zip IntroscopeSOAPerformanceManagementV<version>Agent.unix.tar IntroscopeSOAPerformanceManagementV<version>Agent.zOS.tar

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.
If youre extracting Introscope SPM Agent extensions in a Unix or z/OS environment, use the appropriate command in this table. Operating System Agent Extension Archive Extract Command
IntroscopeSOAPerformanceManagementV<version>Agent.unix.tar
z/OS
tar -xvfo IntroscopeSOAPerformanceManagementV<version>Agent.zOS.tar

The Introscope SPM Agent extension archive contains these files:
File
Description
The ProbeBuilder Directives file containing the tracers required to enable your application to collect web services metrics. Extension to the Introscope Agent required by Introscope SPM.
webservices.pbd WebServicesAgent.jar
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.
The Introscope SPM Agent Java extension is extracted. You now need to configure the Introscope SPM Java Agent extension.
Extracting Windows, Unix, and z/OS Java Agent extensions 37
Configuring Introscope SPM Java Agent extensions

Perform 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 youve 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 example
introscope.autoprobe.directivesFile=defaulttypical.pbl,webserv ices.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.
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 extensions

To uninstall Introscope SPM Java Agent extensions: 1 Stop the application server. 2 Unmodify the agent configuration properties. a Open the IntroscopeAgent.profile file in <Agent_Home>. 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.
Uninstalling Introscope SPM Java Agent extensions 39
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: File Description
IntroscopeSOAPerformanceManagementV<version> Introscope SPM Agent extension (ASP.NET) for .NET Agent Agent.windowsDotNet.zip IntroscopeSOAPerformanceManagementV<version> Introscope SPM Agent extension (WCF) for .NET Agent Agent.windows.wcf.zip
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 extension EM.windows.zip

After you download and extract the installation archive and the Introscope SPM .NET Agent extensions, youll 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.
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): 1 If needed, log in with the Operating System Administrator account. 2 If youre 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.
Extracting and configuring Introscope SPM .NET Agent extensions 41
The installation archive contains these files: File Description

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.
webservices.pbd
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.

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.
To modify the Introscope SPM .NET Agent configuration properties: 1 Modify the Introscope SPM agent configuration properties. a Open the IntroscopeAgent.profile file in <Agent_Home>. 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 example
introscope.autoprobe.directivesFile=defaulttypical.pbl,webserv ices.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.ObserverSoapExtensio n, WebServices.Observer, Version=<version>, Culture=neutral, PublicKeyToken=99330fac7173009e" group="0" priority="3" /> </soapExtensionTypes> </webServices>
For example,
<add type="com.wily.powerpack.webservices.extension.ObserverSoapExtensio n, WebServices.Observer, Version=8.1.0.0, Culture=neutral, PublicKeyToken=99330fac7173009e" group="0" priority="3" /> </soapExtensionTypes> </webServices>
When you are done, the machine.config file looks like this:
<webServices> <soapExtensionTypes> <add type="com.wily.powerpack.webservices.extension.ObserverSoapExtensio n, WebServices.Observer, Version=8.1.0.0, Culture=neutral, PublicKeyToken=99330fac7173009e" group="0" priority="3" /> </soapExtensionTypes> </webServices>
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 youre 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. File Name Directory Location
WebServices.Observer.dll wily.WebServicesAgent.ext.dll webservices.pbd wilyHttpCorrelationTracers.ext.dll wilyBoundaryOnlyTrace.ext.dll
<Agent_Home>\bin <Agent_Home>\ext <Agent_Home> <Agent_Home>\ext <Agent_Home>\ext
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.
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.
<webServices> <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,
<webServices> <soapExtensionTypes> <add type="com.wily.powerpack.webservices.extension.ObserverSoapExtension, WebServices.Observer, Version=8.1.0.0, Culture=neutral, PublicKeyToken=99330fac7173009e" group="0" priority="3" /> </soapExtensionTypes> </webServices>
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.
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 extensions

To 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.ObserverSoapExtensio n, WebServices.Observer, Version=<version>, Culture=neutral, PublicKeyToken=99330fac7173009e" group="0" priority="3" />
For example,
<add type="com.wily.powerpack.webservices.extension.ObserverSoapExtensio n, 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,
Uninstalling Introscope SPM .NET Agent extensions 47
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. File Name Delete from this Directory
WebServices.Observer.dll wily.WebServicesAgent.ext.dll webservices.pbd wilyHttpCorrelationTracers.ext.dll wilyBoundaryOnlyTrace.ext.dll
<Agent_Home>\bin <Agent_Home>\ext <Agent_Home> <Agent_Home>\ext <Agent_Home>\ext
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 youre 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. 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 the aspnet.config file.
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.
Uninstalling Introscope SPM .NET Agent extensions 49
Extracting Introscope SPM EM extensions

When 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 youre 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. Operating System
EM Extension Archive
IntroscopeSOAPerformanceManagementV<version>EM.windows.zip IntroscopeSOAPerformanceManagementV<version>EM.unix.tar IntroscopeSOAPerformanceManagementV<version>EM.zOS.tar IntroscopeSOAPerformanceManagementV<version>EM.windows.zip

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 youre extracting Introscope SPM EM extensions in a Unix or z/OS environment, use the appropriate command in this table.
Operating System
EM Extension Extract Command
IntroscopeSOAPerformanceManagementV<version>EM.unix.tar
z/OS
tar -xvfo IntroscopeSOAPerformanceManagementV<version>EM.zOS.tar
The Introscope SPM EM extension archive contains these files: File Description
Introscope SPM management module for viewing web services data in the Introscope Investigator. Contains preconfigured dashboards and alerts for viewing web services metrics.
SPM_ManagementModule.jar
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.tracefil Supports Introscope SPM Transaction Tracing capabilities. ters.common_<version>.jar 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.tracefil Supports Introscope SPM Transaction Tracing capabilities. ters.em_<version>.jar com.wily.introscope.soa.tracefilters.em_<vers ion>.jar automatically extracts to the <EM_Home>/ product/enterprisemanager/plugins directory.
Extracting Introscope SPM EM extensions 51
File
Description
com.wily.introscope.soa.dependen Supports Introscope SPM SOA Dependency Map capabilities. cymap.common_<version>.jar 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.dependen Supports Introscope SPM SOA Dependency Map capabilities. cymap_<version>.jar com.wily.introscope.soa.dependencymap_<versio n>.jar automatically extracts to the <EM_Home>/ product/enterprisemanager/plugins directory. com.wily.introscope.soa.deviatio Supports Introscope SPM deviation metrics capabilities. nmetrics_<version>.jar com.wily.introscope.soa.deviationmetrics_<ver sion>.jar automatically extracts to the <EM_Home>/ product/enterprisemanager/plugins directory. com.wily.introscope.soa.dependen Supports Introscope SPM SOA Dependency Map capabilities. cymap.ui_<version>.jar com.wily.introscope.soa.dependencymap.ui_<ver sion>.jar automatically extracts to the <EM_Home>/wsplugins directory. com.wily.introscope.soa.dependen Supports Introscope SPM dependency metrics capabilities cymetrics.typeviewer_<version>.j for displaying in the SOA Performance - Most Critical Operations and SOA Performance - Most Dependent ar
Operations dashboards as well as in the Most Critical and Most Dependent tabs.
com.wily.introscope.soa.dependencymetrics.typ eviewer_<version>.jar automatically extracts to the <EM_Home>/ws-plugins directory. com.wily.introscope.soa.tracefil Supports Introscope SPM Transaction Tracing capabilities. ters.workstation_<version>.jar com.wily.introscope.soa.tracefilters.workstat ion_<version>.jar automatically extracts to the <EM_Home>/ws-plugins directory. com.wily.introscope.ui.tomsawyer Supports Introscope SPM UI capabilities. _<version>.jar com.wily.introscope.ui.tomsawyer_<version>.ja r automatically extracts to the <EM_Home>/ws-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.
Configuring Introscope SPM EM extensions

Perform 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.
com.wily.introscope.soa.dependencymap.common_<version>.jar.
com.wily.introscope.soa.dependencymap_<version>.jar.
com.wily.introscope.soa.deviationmetrics_<version>.jar.
Configuring Introscope SPM EM extensions 53
11 Delete <EM_Home>/ws-plugins/
com.wily.introscope.soa.tracefilters.common_<version>.jar.
com.wily.introscope.soa.dependencymap.common_<version>.jar.
com.wily.introscope.soa.dependencymap.ui_<version>.jar.
com.wily.introscope.soa.dependencymetrics.typeviewer_<version>.j ar
com.wily.introscope.soa.tracefilters.workstation_<version>.jar.
com.wily.introscope.ui.tomsawyer_<version>.jar.
17 Start the Enterprise Manager. The Introscope SPM EM extension is uninstalled.
Configuring virtual agents for Introscope SPM

You 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</metricspecifier> <metric-specifier>WebServices\|Server\|(.*):Responses Per Interval</ metric-specifier>
<metric-specifier>WebServices\|Server\|(.*):Stall Count</metricspecifier> <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</metricspecifier> <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 deployment

To 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 youre 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 file loaded properly.
Verifying your deployment 55
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 options

Agent 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 SPM

Upgrading 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.
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:
Upgrading Web Services Manager to Introscope SPM 57
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 example
com.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

Follow 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. To uninstall this Agent extension
Axis WebLogic WebSphere SAP .NET
See these instructions

Configuring Introscope SPM Java Agent extensions on page 38 Configuring Introscope SPM Java Agent extensions on page 38 Configuring Introscope SPM Java Agent extensions on page 38 Configuring Introscope SPM Java Agent extensions on page 38 Configuring Introscope SPM .NET Agent extensions on page 42
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.
Uninstalling Introscope SPM 59
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 youre 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, youll download and extract the documentation archive. Then youll extract the Agent extensions, then the EM extensions. To download and extract the installation archives: 1 If needed, log in with the Operating System Administrator account. 2 Download from the Software Download Site the Introscope SPM OSB installation archive.
a Choose the installation archive appropriate for your environment from this table. OS
Windows
IntroscopeSOAExtensionforOracleServiceBusV<version>windows.zip
Unix (AIX, IntroscopeSOAExtensionforOracleServiceBusV<version>unix.tar Linux, Solaris)
b Download the installation archive to a temp directory. 3 Extract the installation archive into the temp directory. Note If youre extracting in a Unix environment, use the appropriate command in this table. OS
tar -xvf IntroscopeSOAExtensionforOracleServiceBusV<version>unix.tar
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: OS Files that extract from the installation archive Description
Windows IntroscopeSOAExtensionforOracleServiceBusV<version> Introscope SPM OSB Java Agent extension Agent.windows.zip EM extension IntroscopeSOAExtensionforOracleServiceBusV<version>
EM.windows.zip
IntroscopeSOAExtensionforOracleServiceBusV<version> Introscope SPM OSB IntroscopeSOAExtensionforOracleServiceBusV<version> EM extension
Agent.unix.tar EM.unix.tar
Unix Agent extension
The installation archives are downloaded and extracted. 4 Download from the Software Download Site the Introscope SPM OSB documentation.
Installing and configuring Introscope SPM OSB Agent and EM extensions 61
Choose the documentation archive appropriate for your environment from this table. Operating System
Windows Unix (AIX, Linux, Solaris)
IntroscopeSOAExtensionforOracleServiceBusV<version>Docs. windows.zip IntroscopeSOAExtensionforOracleServiceBusV<version>Docs. unix.tar
5 Extract the documentation file. Note If youre extracting documentation in a Unix environment, use the appropriate command in this table. Install Archive Package
tar -xvf IntroscopeSOAExtensionforOracleServiceBusV<version>Docs.unix. tar

The Introscope SPM OSB documentation archive contains a ReadMe file, as shown in this table:
OS
Files that extract from the documentation archive
Description
Windows IntroscopeSOAExtensionforOracleServiceBusV<version> Documentation
_ReadMe.txt
IntroscopeSOAExtensionforOracleServiceBusV<version> Documentation
_ReadMe.txt
The installation and documentation archives are downloaded and extracted. Now you will extract and configure the Introscope SPM OSB Agent extensions.
Extracting Introscope SPM OSB Agent extensions

After you extract the Introscope SPM OSB Agent extensions, youll 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). Tip Before extracting Java Agent extensions, its a best practice to copy IntroscopeAgent.profile to a backup directory.
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 youre 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. Operating System
Agent Extension Archive
IntroscopeSOAExtensionforOracleServiceBusV<version>Agent .windows.zip IntroscopeSOAExtensionforOracleServiceBusV<version>Agent .unix.tar
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.
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 youre extracting Introscope SPM OSB Agent extensions in a Unix environment, use the appropriate command in this table. Operating System Agent Extension Archive Extract Command
tar -xvf IntroscopeSOAExtensionforOracleServiceBusV<version>Agent.unix. tar
The Introscope SPM OSB Agent extension archive contains these files: File Description
The ProbeBuilder Directives file containing the tracers required to enable your application to collect OSB components metrics.
OSB.pbd
OSB.pbd automatically extracts to the <Agent_Home> directory. OSBAgent.jar

Extension to the Introscope Agent required by Introscope SPM OSB. directory.
OSBAgent.jar automatically extracts to the <Agent_Home>/ext
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 youve 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: 1 Modify the agent configuration properties. a Open the IntroscopeAgent.profile file in <Agent_Home>.
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,hotdeploy
d 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. a Open the IntroscopeAgent.profile file in <Agent_Home>. b Remove the OSB.pbd value from the
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 youre 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
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. Operating System
IntroscopeSOAExtensionforOracleServiceBusV<version>EM.windows.z ip IntroscopeSOAExtensionforOracleServiceBusV<version>EM.unix.tar
3 Extract all files in the Introscope SPM OSB EM extension archive file to the <EM_Home> directory. Note If youre extracting EM extensions in a Unix environment, use the appropriate command in this table. OS
tar -xvf IntroscopeSOAExtensionforOracleServiceBusV<version>EM.unix.tar
The Introscope SPM OSB EM extension archive contains these files: File Description
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
OSB.overview.tv.xml automatically extracts to the <EM_Home>/ext/xmltv directory. OSB_ManagementModuleV<version>.j Introscope SPM OSB Management Module component that ar 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.ca Calculator that aggregates: lculator_<version>.jar OSB Proxy Service's request and response metrics, then
Note: The version number in this file
name includes only three digits. For example, 8.1.0. posts those metrics under the respective Proxy Service node. OSB Transport metrics under the respective Transport Type.
com.wily.powerpacks.osb.emext.calculator_<ver sion>.jar automatically extracts to the <EM_Home>/ product/enterprisemanager/plugins directory.

4 Start the Enterprise Manager. 5 Verify your installation. See Verifying your Introscope SPM OSB deployment on page 68. The Introscope SPM OSB EM extension is installed.
Uninstalling Introscope SPM OSB EM extensions

To uninstall the Introscope SPM OSB EM extension: 1 Stop the Enterprise Manager. 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. 5 Start the Enterprise Manager. 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. a Choose Workstation > New Management Module Editor. 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
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, youll download and extract the documentation archive. After you download and extract the installation archive, youll Then youll extract the Introscope SPM WPS/WESB Agent extensions, then the Introscope SPM WPS/WESB 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 WPS/WESB installation archive. a Choose the installation archive appropriate for your environment from this table. OS
Windows Unix (AIX, Linux, Solaris) z/OS
IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version> windows.zip IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version> unix.tar IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version> zOS.tar

b Download the installation archive to a temp directory. 3 Extract the installation archive into the temp directory. Note If youre extracting in a Unix or z/OS environment, use the appropriate command in this table.
OS
tar -xvf IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version> unix.tar 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: OS Files that extract from the installation archive Description
Windows IntroscopeSOAExtensionforIBMWebSphereProcessServer Introscope SPM WPS/ WESB Windows Agent andWESBV<version>Agent.windows.zip extension IntroscopeSOAExtensionforIBMWebSphereProcessServer EM extension andWESBV<version>EM.windows.zip Unix (AIX, Linux, Solaris) z/OS
IntroscopeSOAExtensionforIBMWebSphereProcessServer Introscope SPM WPS/
andWESBV<version>Agent.unix.tar
IntroscopeSOAExtensionforIBMWebSphereProcessServer
andWESBV<version>EM.unix.tar andWESBV<version>Agent.zOS.tar
IntroscopeSOAExtensionforIBMWebSphereProcessServer
WESB Unix Agent extension EM extension
IntroscopeSOAExtensionforIBMWebSphereProcessServer Introscope SPM WPS/
andWESBV<version>EM.zOS.tar
WESB z/OS Agent extension EM extension
4 Download from the Software Download Site the Introscope SPM WPS/WESB documentation. Choose the documentation archive appropriate for your environment from this table. Operating System
IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV <version>Docs.windows.zip IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV <version>Docs.unix.tar IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV <version>Docs.zOS.tar
5 Extract the documentation file. Note If youre extracting documentation in a Unix or z/OS environment, use the appropriate command in this table. Install Archive Package
tar -xvf IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV <version>Docs.unix.tar tar -xvfo IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV <version>Docs.zOS.tar
z/OS
The Introscope SPM WPS/WESB documentation archive contains a ReadMe file, as shown in this table: OS
Windows
Files that extract from the documentation archive

IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV <version>_ReadMe.txt
Description
Documentation Documentation
IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV Unix (AIX, Linux, <version>_ReadMe.txt Solaris) z/OS IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV <version>_ReadMe.txt
Documentation
The installation and documentation archives are downloaded and extracted. 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, youll perform some configuration tasks.
Prerequisites

SPM Agent extensions.

SPM EM extension.
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). Tip Before extracting Java Agent extensions, its a best practice to copy
IntroscopeAgent.profile to a backup directory.

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. Operating System
Agent Extension Archive
IntroscopeSOAExtensionforIBMWebSphereProcessServerand WESB<version>Agent.windows.zip IntroscopeSOAExtensionforIBMWebSphereProcessServerand WESB<version>Agent.unix.tar IntroscopeSOAExtensionforIBMWebSphereProcessServerand WESB<version>Agent.zOS.tar

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 youre 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 Extract Command
tar -xvf IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESB <version>Agent.unix.tar tar -xvfo IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESB <version>Agent.zOS.tar
z/OS
The Introscope SPM WPS/WESB Agent extension archive contains these files: File Description
The ProbeBuilder Directives file containing the tracers required to enable your application to collect WPS components-related metrics.
WPS.pbd
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. directory.
WPSAgentExt.jar automatically extracts to the <Agent_Home>\ext
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. Platform
WPS WESB
Go to this topic next
Configuring Introscope SPM WPS Agent extensions on page 75 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 youve 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: 1 Modify the agent configuration properties. a Open the IntroscopeAgent.profile file in <Agent_Home>. b Search for the introscope.autoprobe.directivesFile property. 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. a Open the IntroscopeAgent.profile file in <Agent_Home>. 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. 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
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.
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. a Open the IntroscopeAgent.profile file in <Agent_Home>. b Remove the WPS.pbd value from the
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. d Save and close the IntroscopeAgent.profile file. 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: 1 Modify the agent configuration properties. a Open the IntroscopeAgent.profile file in <Agent_Home>. b Search for the introscope.autoprobe.directivesFile property. 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 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 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. a Open the IntroscopeAgent.profile file in <Agent_Home>.
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. 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
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.
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. a Open the IntroscopeAgent.profile file in <Agent_Home>. b Remove the WESB.pbd value from the
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. d Save and close the IntroscopeAgent.profile file. 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 youre 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. Operating System
Windows
IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV <version>EM.windows.zip <version>EM.unix.tar
Unix (AIX, Linux, Solaris) IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV z/OS

IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESB
V<version>EM.zOS.tar
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.
4 Extract all files in the Introscope SPM WPS EM extension archive file to the <EM_Home> directory. Note If youre extracting Introscope SPM WPS EM extensions in a Unix or z/OS environment, use the appropriate command in this table. OS
tar -xvf IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV <version>EM.unix.tar tar -xvfo IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV <version>EM.zOS.tar
The Introscope SPM WPS EM extension archive contains these files: File Description
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
wps.overview.tv.xml automatically extracts to the <EM_Home>/ext/xmltv directory. WPS_Management_ModuleV<version>.j ar

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 groupings and alerts.
directory. When the Enterprise Manager is started, WESB_Management_ModuleV<version>.jar is automatically moved to the <EM_Home>/config/ modules directory.
WESB_Management_ModuleV<version>.jar automatically extracts to the <EM_Home>/deploy
File
Description
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.websphereprocs erver.em.ext_<version>.jar
Note: The version number in this file name
includes only three digits. For example, 8.1.0.
directory.
com.wily.powerpack.websphereprocserver.em.ex t_<version>.jar automatically extracts to the <EM_Home>/product/enterprisemanager/plugins
5 Delete the WESB_Management_ModuleV<version>.jar file from the <EM_Home>/deploy directory. 6 Start the Enterprise Manager. 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: 1 Stop the Enterprise Manager. 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.
Note The version number in this file name includes only three digits. For example, 8.1.0. 5 Start the Enterprise Manager. The Introscope SPM WPS EM extension is uninstalled.
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 youre 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. Operating System
IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV <version>EM.windows.zip IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV <version>EM.unix.tar IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV <version>EM.zOS.tar

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.
4 Extract all files in the Introscope SPM WESB EM extension archive file to the <EM_Home> directory. Note If youre extracting Introscope SPM WESB EM extensions in a Unix or z/OS environment, use the appropriate command in this table. OS
tar -xvf IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version> EM.unix.tar tar -xvfo IntroscopeSOAExtensionforIBMWebSphereProcessServerandWESBV<version> EM.zOS.tar

The Introscope SPM WESB EM extension archive contains these files:
File
Description
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
wps.overview.tv.xml automatically extracts to the <EM_Home>/ext/xmltv directory. WPS_Management_ModuleV<version>.j ar

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.
File
Description
Introscope SPM WESB management module that Enables the Workstation to show WESB health in dashboards. Contains pre-configured WESB dashboards, metrics groupings and alerts.
WESB_Management_ModuleV<version>. jar
directory. When the Enterprise Manager is started, WESB_Management_ModuleV<version>.jar is automatically moved to the <EM_Home>/config/ modules directory.
WESB_Management_ModuleV<version>.jar automatically extracts to the <EM_Home>/deploy
com.wily.powerpack.websphereprocs erver.em.ext_<version>.jar
Note: The version number in this file name
includes only three digits. For example, 8.1.0.
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.ex t_<version>.jar automatically extracts to the <EM_Home>/product/enterprisemanager/plugins

directory.
5 Delete the WPS_Management_ModuleV<version>.jar file from the <EM_Home>/ deploy directory. 6 Start the Enterprise Manager. 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: 1 Stop the Enterprise Manager. 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.
Note The version number in this file name includes only three digits. For example, 8.1.0. 4 Start the Enterprise Manager. The Introscope SPM WESB EM extension is uninstalled.
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

3 Start the Enterprise Manager. 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

3 Start the Enterprise Manager. 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. a Choose Workstation > New Management Module Editor. 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:
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. a Choose Workstation > New Management Module Editor. 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:
CHAPTER
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 . SOA Performance Management dashboards SOA Performance Management tabs . Viewing agent web service metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 95 105 128 132 138 140
Viewing web service metrics in the Investigator
Viewing Introscope SPM metric groupings and alerts Checking the health of your web services .
Monitoring web services 93
Viewing web services data in Introscope SPM

When 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
Agent application
What you see in the associated Overview tab

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. Overview tables listing the client and server web service namespaces that belong to the selected agent application. Overview table listing the web service namespaces that belong to the selected agent application client or server. Overview table listing the operations that belong to the selected web service.
WebServices
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. 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
94 Monitoring web services
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 dashboards

Introscope 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 clients performance. For more
information, see Introscope SPM Client Health dashboard on page 99.

Introscope SPM Server Health: Shows the servers 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.
SOA Performance Management dashboards 95
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 hasnt 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 JMS File systems EJBs JDBC 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.
Double-click an operation to see it in the Investigator.
Use the SOA Performance Client Health dashboard to see:

Top 10 Slowest Client Operations
Client Operations Average Response Timeeach metric represents the
average response time for one method or operation

Client Services SOAP Faults Per Intervaltotal 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 Intervaltotal responses for all web services
To get more information:

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 Timeeach metric represents the
average response time for one method or operation

Server Services SOAP Faults Per Intervaltotal 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 Intervaltotal responses for all web services
To get more information:

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 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. To get more information:
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. To get more information:
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 Intervaltotal responses for all web
services
Busiest Server Operations Responses Per Intervaltotal responses for all web
services To get more information:

Double-click one of the top 10 busiest 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.
SOA Performance Management tabs

In 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.
SOA Performance Management tabs 105
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 agents 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.
Client node. Server node. Namespaces label.
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.
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.
This is an operation node.
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.
Using the Dependencies tabs

Introscope SPM provides metrics for monitoring web service operation health. T in the Dependencies tab. These metrics list the most critical They can be viewed 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.
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

Lets 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.
1. SayHello client 1 is a critical operation in this dependency chain. 2. Introscope SPM displays these metrics for Test server: Critical Direct: 0 Critical Indirect: 0 Dependency Direct: 4
3. Introscope SPM displays these metrics for SayHello server 5: Critical Direct: 1 Critical Indirect: 2 Dependency Direct: 0 Dependency Indirect: 0
Heres what the Introscope SPM metric values would be for the two operations shown above. Operation name in figure Test Server Associated metrics Direct Critical to none Indirect Critical to none Metric value for Critical Direct = 0 Metric value for Critical Indirect = 0 Direct Dependency on Hello Clients 1, 2, 3, 4 Indirect Dependency on Hello Servers 5, 6, 7, 8 Metric value for Dependency Direct = 4 Metric value for Dependency Indirect = 8 Direct Critical to Say Hello Client 1 Indirect Critical to Test Server Metric value for Critical Direct = 1 Metric value for Critical Indirect = 2 Direct Dependency on none Indirect Dependency on none Metric value for Dependency Direct = 0 Metric value for Dependency Indirect = 0
SayHello Server 5
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: Investigator tree node name
WebServices
What you see in the Dependencies tab

Dependencies tables listing the client and server web service namespaces, operations, and dependencies metrics that belong to the selected Agent application. Dependencies table listing the client or server web service namespaces, operations, and dependencies metrics that belong to the selected Agent application.
Client or Server
namespace
Note:
Dependencies table listing the operations and its associated dependency metrics that belong The node name displayed is to the selected web service. the name of web service in use by the Agent application client or server.
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.
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.
Heres the WebServices node.
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.
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.
Heres 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 DeviationThe 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 DeviationThe 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 DeviationThe 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: Investigator tree node name
WebServices
What you see in the Deviations tab

Deviations tables listing the client and server web service namespaces and deviations metrics that belong to the selected Agent application. Deviations table listing the client and server web service namespaces and deviations metrics that belong to the selected Agent application.
Client or Server
namespaces
Note:
Deviations table listing the operations and its deviation metrics that belong to the selected The node name displayed is web service. the name of web service in use by the Agent application client or server.
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.
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.
This table displays the Agent client web service namespace metrics. Heres the Deviations tab.
Notice the deviations metrics that display for these namespaces.
Heres the WebServices node.
This table displays the Agent server web service namespace metrics.
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.
Heres 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.
Heres a namespace node. Heres 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 clientand 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.
This is the Server node. This is the Errors tab.
3.
Notice that SOAP fault error messages include SOAP Fault at the beginning of the error message.
Viewing web service metrics in the Investigator

You 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 metrics

Introscope supplies these five basic metrics for each monitored method or class:
Average Response Time (ms) Concurrent Invocations Errors Per Interval Responses 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)
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
Errors Per Interval
Is monitored by
Introscope Java or .NET Agent
To monitor and display

All Java and .NET exceptions generated by the monitored application See Errors Per Interval metric on page 130.
Reported here
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.
SOAP Faults Per Interval
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 ErrorDetector Live or Historical Error Viewer .NET Framework resources. See ErrorDetector Errors Per See Viewing web Interval metric on page 132. service faults in ErrorDetector on page 204.
Viewing web service metrics in the Investigator 129
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. Heres the SOAP Faults Per Interval metric.
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, lets 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.
Viewing web service metrics in the Investigator 131
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 metrics

Once 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.
2 Expand the Introscope Agent node youre interested in. Web service metric data appears in the Investigator tree under the agents WebServices node. Under the WebServices node is a Client node and a Server node.
Agent node WebServices node
Client node
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.
Viewing agent web service metrics 133
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 name node. Web service method (called the operation 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) Concurrent Invocations Errors Per Interval Responses Per Interval SOAP Faults 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. Heres 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 alerts

You 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.
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
Viewing Introscope SPM metric groupings and alerts 139
Checking the health of your web services

Looking 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.
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.
Checking the health of your web services 141
Step 3 From the SOA Performance Management Client Health dashboard, doubleclick 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.
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.
Checking the health of your web services 143
CHAPTER
Using SOA Dependency Map to triage web service problems
This chapter includes these topics: Getting to know the SOA Dependency Map . SOA Dependency Map components . Setting up the SOA Dependency Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 151 159 161 166 169 176 180
Choosing a SOA Dependency Map content type Choosing a SOA Dependency Map view . Navigating the SOA Dependency Map SOA Dependency Map FAQs . . . . .
Using the SOA Dependency Map for triage .
Using SOA Dependency Map to triage web service problems 145
Getting to know the SOA Dependency Map

The 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 youre 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 missioncritical 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 mannerpreferably in real-time or close to real-time. Introscope SPM allows you to fulfill your mission.
146 Using SOA Dependency Map to triage web service problems
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, youll 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.
Getting to know the SOA Dependency Map 147
Knowing where I am on the SOA Dependency Map

While the SOA Dependency Map is a map, its different from a paper map because what you see depends on two factors, in this order: the SOA Dependency Map content type youve chosen, then the Investigator tree node youve 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. Its 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. Lets 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, youll 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.
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 Japans largest city, Tokyo, and its trains to other major cities. If you decided to zoom out to a view of earths major cities connected by train, then back in to a map of Japan, youd see a map of all of Japans 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, lets 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.
Getting to know the SOA Dependency Map 149
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
Become aware of services in my SOA environment as deployed, not as designed
To help me
Get current accurate services information about my environment
To learn more see

Getting to know the SOA Dependency Map on page 146 Using the SOA Dependency Map for triage on page 176
Visually assess the global impact of Research and resolve my SOA problem services and drill down into environment problems the details of the problem within three to four mouse clicks
Work with IT architects by viewing Plan and carry out enterprise-wide Choosing a SOA Dependency Map view on page 166 both the physical and logical view of SOA initiatives my enterprise SOA environment 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 dont use Introscope SPM Understand what is going on in my SOA environment without needing an expert to interpret the service performance data Understand which agents, services, and operations are dependent on each other Reorient myself on the Investigator tree and the SOA Dependency Map based on my current map node location Outputting SOA Dependency Map images for sharing on page 177
View my SOA environment agents, services, and operations in the SOA Dependency Map View the dependency relationships of my monitored agents, services, and operations in the SOA Dependency Map Click on a map node and go to that component in the Investigator tree
Using the SOA Dependency Map for triage on page 176
Unrolling dependencies levels on page 169
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
Starting a Transaction Trace See all the Transaction Traces session from SOA Dependency associated with that problem service without needing to set up a Map on page 180 manual Transaction Trace
SOA Dependency Map components

Becoming 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 5 2 3 4 6 7 8 9 10 11 12 13 14 15
22
16 17
19
20
21
28
18
23
24
25
26
27
SOA Dependency Map components 151
This legend table describes the SOA Dependency Map components and shows their associated icons. Icon or Image Map Component or Button Name
1. SOA Dependency Map tab
Description
Click to display the SOA Dependency Map associated with the node selected on the Investigator tree. Choose either a Physical or Logical representation of your web services environment.
2. View dropdown list
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 nodefor 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 Client-side operation icon that displays on the SOA Dependency Map when youve chosen the Physical view. Operation name of the displayed client. 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. Select Introscope SPM metrics to display in tooltips in addition to displaying the Primary Metric data.
5. Client operation icon
6. Client operation name 7. Primary Metric value
8. Tooltips button
Icon or Image
Map Component or Button Name

9. Unroll Dependencies button
Description
Add a dependency (if one exists) for every lowestlevel 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. Server-side operation icon that displays on the SOA Dependency Map when youve chosen the Physical view.
16. Server operation icon
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 youve chosen the Physical view.
22. Scroll bar
Icon or Image
Map Component or Button Name

23. Client Service icon
Description
Client-side service icon that displays on the SOA Dependency Map when youve chosen the Physical view. Server-side service icon that displays on the SOA Dependency Map when youve chosen the Logical view. Client-side service icon that displays on the SOA Dependency Map when youve chosen the Logical view.
24. Server Service icon
25. Client service icon
26. Client operation icon
Client-side operation icon that displays on the SOA Dependency Map when youve chosen the Logical view. Server-side operation icon that displays on the SOA Dependency Map when youve chosen the Logical view. Agent icon that displays on the SOA Dependency Map when youve chosen the Physical view Agent content type.
27. Server operation icon
28. Agent icon
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 youll 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. Youll 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 SPM and when you add a new web application to your environment. In these cases and others when data is not available, youll see a status message. For more informations, see Im experiencing a problem viewing the SOA Dependency Map. Whats 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 doesnt have to rediscover the previously discovered dependencies. If the the dependencymap.sav file doesnt 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: 1 Stop the Enterprise Manager. 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. 5 Start the Enterprise Manager. Introscope SPM discovers all the current dependencies in the monitored SOAPbased applications and creates a new SOA Dependency Map.
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 Map

Out-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. To change this SOA Dependency Map content
Introscope basic metric set at the SOA Dependency Maps Primary metric Tooltips metrics The level to view your SOA environment: agent or services or operations The representation of your SOA environment: physical or logical
See this topic

Setting Introscope SPM metrics to display on the SOA Dependency Map on page 159 Setting Introscope SPM metrics to display on the SOA Dependency Map on page 159 Choosing a SOA Dependency Map content type on page 161 Choosing a SOA Dependency Map view on page 166
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.
Setting up the SOA Dependency Map 159
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 Responses Per Interval Errors per Interval Concurrent Invocations 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 youve 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.
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 youve 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 dont 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 type

The 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.
Choosing a SOA Dependency Map content type 161
Its important to understand that the SOA Dependency Map displays first based on the content type youve chosen and then second based on the Investigator tree node youve chosen. If you choose a content typefor example Servicesthen 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 typefor example Agentsthe 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 services 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 view

SOA 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 its 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 youve 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.
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
Physical
And choose this content type

Agents
To view this on the SOA Dependency Map

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 agents node. 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
Services
Choosing a SOA Dependency Map view 167
Choose this view

Physical or Logical
And choose this content type

Operations
To view this on the SOA Dependency Map

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.
Navigating the SOA Dependency Map

This 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, youll 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.
Navigating the SOA Dependency Map 169
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 youve 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 Map

If 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.
Heres the MOM connected to 3 Collectors. Heres Collector 1. Heres an agent on Collector 1 calling an agent on Collector 2. Heres Collector 2. Heres the agent on Collector 2 being called.
Heres Collector 3.
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.
Heres the MOM.
Heres Collector 1.
Heres Collector 2.
Here is a service from a Collector 2 agent calling a service 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.
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.
The SOA Dependency Map is displaying three sets of discovered client and server services when the Available data has changed message appears. When you click the Click here link, the SOA Dependency Map reloads and displays the newly discovered services and operations.
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, it displays four sets of discovered client and server services. 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, the view changes to the default SOA Dependency Map view associated with the Investigator tree node you clicked last. For example, lets 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.
However, if you had clicked the WebServices tree node, and then clicked an Agent1 tree node, youd 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 triage

Here 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.
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 whats 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, arent Introscope experts. They cant 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 cant 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.
Using the SOA Dependency Map for triage 177
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 dont 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
Type Filename Image Content
To set this
The output file type. Save as JPEG, GIF, PDF, PNG, or SVG. The destination path and file name for the output image file. The part of the SOA Dependency Map you choose to save in the image file. Visible WindowSaves 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 GridThis choice is not enabled. Selected Objects OnlySaves 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.
Choose this
Image Characteristics
To set this
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 LevelIf 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 SizeThe 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 CanvasThe 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. CustomYou choose the image width and height settings in pixels.
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, youll 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
Using the SOA Dependency Map for triage 179
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, lets 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, its 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 FAQs

Here are some frequently-asked questions about the SOA Dependency Map. FAQ
Can I go back to a previous SOA Dependency Map?
Answer
No. The SOA Dependency Map always reflects the current dependencies between the monitored web services. However, because its likely your organization will deploy, modify, or remove applications in a production environment only occasionally, the SOA Dependency Map structure should remain fairly static. 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.
Where does the SOA Dependency Map get its information?
FAQ
What problems can I find and fix using the SOA Dependency Map?
Answer
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. 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 wont 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.
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?
SOA Dependency Map FAQs 181
FAQ
Can I bookmark a SOA Dependency Map?
Answer
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. No. However, you can save a current map as an image. See Outputting SOA Dependency Map images for sharing on page 177. 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.
Can I save a live map and return to it later?
I couldnt find an agent, service, or operation that I was looking for. How do I find it?
FAQ
Im experiencing a problem viewing the SOA Dependency Map. Whats wrong?
Answer
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 havent 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.transac tiontrace.boundaryTracing.enable and it is not set to False.

If the SOA Dependency Map is present but incompletethat is, it contains some web services but not allit 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.
SOA Dependency Map FAQs 183
About Introscope SPM logical equivalence

Introscope 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.
CHAPTER
Using Transaction Tracing to triage web service problems
Introscope SPM enables you to monitor web services by viewing web servicerelated metrics in Introscope. This chapter discusses using the Introscope dashboards and Investigator to view and interpret web service metrics. This chapter includes these topics: About Introscope SPM cross-process transaction tracing Viewing correlated events using Transaction Tracer . Viewing web service data with Transaction Tracer Viewing web service faults in ErrorDetector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 201 203 204
Using Transaction Tracing to triage web service problems 185
About Introscope SPM cross-process transaction tracing

In Introscope, cross-process transaction tracing is Transaction Tracers 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.
186 Using Transaction Tracing to triage web service problems
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.
About Introscope SPM cross-process transaction tracing 187
Using cross-process transaction tracing to solve difficult problems

Heres 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 thats 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. Heres Web Service A making calls to Web Service B. Notice that all the calls in the entire transaction that includes Web Service A take 6000 ms or six seconds.
Web Service A
Web Service B
2. Heres the duration of Web Service Bs invocations to the CICS back-end (end point of transaction not shown in the trace because its not instrumented). This transaction takes 5000 ms or five seconds, and is the source of the problem.
3. Here are all of Web Service Bs many invocations to the CICS backend.
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.
1. Start in the Transaction Trace Viewers Summary View. 2. Heres the HotelEnquiry web service called in a sample travel application.
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. Heres the ClearingHouseService making calls from a WebLogic 9.0 host machine (oct6506al-w2s-1). 2. Here are the CheckingAccountService and CreditManagmentService on another WebLogic host machine (mokap01-xp) being called by the WebLogic 9.0 hosted ClearingHouseService.
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).
By clicking the Trace View tab, Workstation displays the traces and trace times making up the ClearingHouseService business process.
1. Heres 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. Heres 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 Heres 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.
1. Here the WASBookingService on a WebSphere 6.1 machine (UNI6506-XP-1) is calling the LoginSite on a .NET machine (mokap01-xp).
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).
By clicking the Trace View tab, Workstation displays the traces and trace times making up WASBookingService business process.
1. Heres the WasBookingService transaction shown in the Trace View.
2. Here are the two transactions called by the WasBookingService web service (all shown in the red trace list box above).
3. Heres the sum of the transactions comprising the WasBookingService web service.
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, its 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 filters 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 filters

The 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 casesensitive 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 casesensitive and must reflect the exact spelling of the expected incoming field names.
Here is the Introscope SPM Transaction Trace filter filtering on a namespace.
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.
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 filters 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.
For example, you can filter on both operation name and namespace at the same time, as shown in this figure.
Here is the Introscope SPM Transaction Trace filter filtering on both a namespace and an operation.
Viewing correlated events using Transaction Tracer

If 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.
Viewing correlated events using Transaction Tracer 201
Heres a transaction highlighted in the Trace View.
Heres the Historical Query Viewer displaying the correlated events related to the transaction shown in the Trace View.
Viewing web service data with Transaction Tracer

Using 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 data with Transaction Tracer 203
Viewing web service faults in ErrorDetector

Before learning how to view errors and faults using the ErrorDetector Live or Historical Error Viewer in Introscope SPM, its 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.
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.
Viewing web service faults in ErrorDetector 205
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.
Notice that SOAP fault error messages include SOAP Fault in the error message content.
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.
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.
Viewing web service faults in ErrorDetector 207
CHAPTER
Monitoring Oracle Service Bus (OSB)
Introscope SPM enables you to monitor OSB components and view the servicerelated 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 Viewing OSB metrics . . . . . . . . . . . Viewing OSB dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 211 230 241 242 244
Viewing and creating OSB metric groupings Viewing and creating OSB alerts .
About OSB cross-process transaction tracing .
Monitoring Oracle Service Bus (OSB) 209
Using Introscope SPM to monitor OSB

You 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.
210 Monitoring Oracle Service Bus (OSB)
Viewing OSB metrics

Introscope 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 services services or other
that the service bus implements and hosts locally. The bus uses proxy to route messages between business services such as enterprise web and databases, and service clients such as presentation applications 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.
Viewing OSB metrics 211
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.
Heres the Request node for the LoanGateway1 proxy service.
Heres 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. This term in the equation ART CI EPI RPI SC Count Req Res Means this Average Response Time Concurrent Invocations Errors Per Interval Responses Per Interval Stall Count Data count shown for each metric in the investigator Request node Response node
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.
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. This method is responsible for... sending messages to OutboundMessageContext. sending messages to an outside service. sending the response back to the client. getting the request message payload. getting the response message payload.
sendMessageAsync send close getRequestPayload getResponsePayload
6 Double-click a method or expand a sub-node for the transport type InboundMessageContext, OutboundMessageContext, or TransportProvider, and then click a method.
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:
HTTP/HTTPS JMS EJB FTP Email SFTP Tuxedo MQ WS JPD SB DSP File Local
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.
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 aggregated metrics for the HTTP transport type.
Here are the metrics used in the aggregation for the HTTP transport type.
Here are the equations used for generating the aggregated metric calculations. This term in the equation ART CI EPI RPI SC Count Class1, Class2 Means this Average Response Time Concurrent Invocations Errors Per Interval Responses Per Interval Stall Count Data count shown for each metric in the investigator. Correspond to HttpInboundMessageContext, HttpOutboundMessageContext, HttpTransportProvider and so on. Correspond to getRequestPayload, sendMessageAsync, getResponsePayload and so on. The transport type, for example HTTP, JMS, FTP, or SFTP
Method1, Method2
Type1
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)
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 dashboards

OSB 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: 1 Start the Introscope Workstation Console. 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
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.
Viewing OSB dashboards 231
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.
To view more information:

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. To view more information:

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. To view more information:
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. To view more information:

corresponding alert in the Management Module. Note Graphs for Parse do not have any associated alerts, so when you rightclick 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 To view more information:
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 metric groupings 241
Viewing and creating OSB alerts

You 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. 2 Expand the following nodes: a *SuperDomain*. b Management Modules. 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.
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.
Viewing and creating OSB alerts 243
About OSB cross-process transaction tracing

Introscope 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.
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.
About OSB cross-process transaction tracing 245
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).
Heres the proxy service (loan gateway2) when looking at the Trace View tab.
Note A service callout is an action that you can configure in the OSB Console to call business services.
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.
1. Heres the proxy service (loan gateway2) in the Summary View.
2. Here are the largeSimplebean and creditSimplebean external services called by the proxy service.
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. Heres the CreditRatingService business service in the Trace View. The Duration column shows it took 922 ms to execute. 2. Heres the CreditRatingServices 922 ms transaction time.
3. Heres the loanSalesProcesss 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. 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.
CHAPTER
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 . About WPS and WESB component metrics . About WPS and WESB metrics . Viewing WPS tabs and metrics . Viewing WESB tabs and metrics Viewing WPS dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 253 256 257 269 271 284 294 302 304 308
Viewing WPS and WESB shared component metrics . Viewing WESB dashboards .
Viewing and creating WPS and WESB metric groupings . Viewing and creating WPS and WESB alerts About WPS cross-process transaction tracing .
Monitoring WebSphere Process Server (WPS) 251
Using Introscope SPM to monitor WPS and WESB

You 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.
The WProcServer node represents the WPS server. If you are monitoring a standalone WESB environment, youll see the WESB node here.
Here are the WPS components.
5 Navigate to the Introscope Workstation Console.
252 Monitoring WebSphere Process Server (WPS)
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 metrics

Introscope 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.
About WPS and WESB component metrics 253
This table shows the metrics and dashboards Introscope SPM provides for each of these environments: This Introscope SPM metric & dashboard Business Processes Business State Machines Business Rules Human Tasks Interface Maps Selectors Mediation Flows Mediation Primitives Java Components BO Maps Relationships J2CA (Adapters) Data Binding are displayed in this environment WPS Only WPS Only WPS Only WPS Only WPS Only WPS Only WPS and WESB WPS and WESB WPS and WESB WPS and WESB WPS and WESB WPS and WESB WPS and WESB
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.
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 EISspecific 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.
About WPS and WESB component metrics 255
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 metrics

The 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

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: 1 Open an Introscope Investigator window. 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.
Viewing WPS tabs and metrics 257
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.
Heres 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

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: 1 Open an Introscope Investigator window. 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.
Viewing WESB tabs and metrics 269
This figure shows the Investigator metrics for WESB.
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 WPS and WESB shared component metrics 271
Viewing Java Components metrics

To view the Java Components metrics: 1 In the Investigator tree:
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.
Heres the Java component name.
Heres the method name of the Java component.
Viewing Business Objects Maps metrics

To view the Business Objects Maps metrics: 1 In the Investigator tree:
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.
Heres the Business Object Maps target namespace. Here are the Business Object Map names.
Viewing Adapters metrics

To view the Adapters metrics: 1 In the Investigator tree:
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: 1 In the Investigator tree:
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: 1 In the Investigator tree:
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.
Heres the name of the module that contains this Mediation Flow component.
Heres the Mediation Flow component name.
Heres 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 operations 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

WPS 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 predefined 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: 1 Start the Introscope Workstation Console. 2 Select a dashboard from the drop-down list.
Viewing WPS and WESB Dashboards 283
Viewing WPS dashboards

Here are the dashboards youll 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. To view more information: 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.
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.
Viewing WPS dashboards 285
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

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

A graph showing the Average Response Times for all relationships, as well as

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

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

WPS Adapters dashboard

Overall health of inbound and outbound adapters. A graph showing the Average Response Times for all inbound adapters, as well

A graph showing the Average Response Times for all outbound adapters, as

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. The dashboard shows:
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

A graph showing the Average Response Times for all request flows, as well as

A graph showing the Average Response Times for all response flows, as well

A graph showing the Average Response Times for all fault flows, as well as

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. The dashboard shows:
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. To view more information:
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
Viewing WESB dashboards

Here are the dashboards youll 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. To view more information:
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.
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

A graph showing the Average Response Times for all request flows, as well as

A graph showing the Average Response Times for all response flows, as well

A graph showing the Average Response Times for all fault flows, as well as

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.
Viewing WESB dashboards 295
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. To view more information:
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
WESB Adapters dashboard

Overall health of inbound and outbound adapters. A graph showing the Average Response Times for all inbound adapters, as well

A graph showing the Average Response Times for all outbound adapters, as

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
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

A graph showing the Average Response Times for all relationships, as well as

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

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
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: 1 In the Investigator, click Workstation > New Management Module Editor. The Management Module Editor opens. 2 Expand the following nodes: a Super Domain. b Management Modules. c WPS_Management_Module <version>. 3 Expand the MetricGroupings node to view all metric groupings for WPS. 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 WPS management module. For information about creating and defining metric groupings, see the Introscope Configuration and Administration Guide. This figure shows WPS metric groupings in the Management Module Editor.
To view WESB 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 Super Domain. b Management Modules. c WESB_Management_Module <version>. 3 Expand the MetricGroupings node to view all metric groupings for WESB. 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 WESB management module. For information about creating and defining metric groupings, see the Introscope Configuration and Administration Guide. This figure shows WESB metric groupings in the Management Module Editor.
Viewing and creating WPS and WESB metric groupings 303
Viewing and creating WPS and WESB alerts

You 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: 1 In the Investigator, click Workstation > New Management Module Editor. The Management Module Editor opens. 2 Expand the following nodes: a Super Domain. b Management Modules. c WPS_Management_Module <version>. 3 Expand the Alerts node to view all alerts for WPS. 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 WPS alerts in the Management Module Editor.
To view WPS alerts using Investigator: 1 In the Investigator, expand the following nodes: 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. 3 Click an alert to view its current status in the Viewer pane. Each alert has a metric value:
This figure shows WESB alerts in the Investigator.
Viewing and creating WPS and WESB alerts 305
To view WESB alerts using Management Module Editor: 1 In the Investigator, click Workstation > New Management Module Editor. The Management Module Editor opens. 2 Expand the following nodes: a Super Domain. b Management Modules. c WESB_Management_Module <version>. 3 Expand the Alerts node to view all alerts for WESB. 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 WESB alerts in the Management Module Editor.
To view WESB alerts using Investigator: 1 In the Investigator, expand the following nodes: 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. 3 Click an alert to view its current status in the Viewer pane. Each alert has a metric value:
This screenshot illustrates the alerts in the Investigator.
Viewing and creating WPS and WESB alerts 307
About WPS cross-process transaction tracing

Introscope 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.
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.
About WPS cross-process transaction tracing 309
In the first transaction in the figure below, the JMSInvokerProcess business process receives the web applications client call.
1. Start in the Transaction Trace Viewers Summary View. 2. Click the first trace.
3. You can view data for the Received business process activity associated with the called JmsInvokerProcess Business Process.
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. Heres 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.
1. Click the Trace View tab.
2. See the parent Business Process before returning to the client.
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.
1. All the transactions are correlated in the execution order.
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.
Viewing correlated events using Transaction Trace

If you are reviewing details about a WPS transaction, you can view the correlated 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.
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 involve WPS/WESB components and web services on other processes or nodes that are part of the selected Transaction Trace.
APPENDIX
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
Required configuration after Introscope .NET Agent install or upgrade 317
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 dlls. To redirect dlls 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. 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. 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-microsoftcom: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.
318 Required configuration after Introscope .NET Agent install or upgrade
APPENDIX
Introscope SPM Agent extension configuration properties
This appendix includes the following topics: Introscope SPM Agent extension configuration . . . . . . . . . . . . . . 320 321
Introscope SPM Agent extension configuration properties .
Introscope SPM Agent extension configuration properties 319
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.
320 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
Bounty traces are sent from the
com.wily.introscope.agent.transac Enables or disables tiontrace.boundaryTracing.enable 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 com.wily.introscope.agent.transac Specifies the number of days tiontrace.boundaryTracing.cacheFl that will pass before the Introscope agent memory ushFrequency cache next flushes all the dependency data. Default: 30
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.
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 nonclustered (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.
Property
com.wily.introscope.agent.soaphe aderinsertion.enabled
Definition/Default
Enables or disables insertion of Introscope SPM SOAP header entries. If set to True: Introscope SPM adds clientside 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
Notes
Set this property if your SOAP-
based applications do not work properly due to unexpected header entries. You must restart the managed application before changes to this property take effect.
Property
com.wily.introscope.agent.soa. metricNameFormatting
Definition/Default
Replaces any denoted character or characters in Introscope SPM metric names with the underscore character [ _]. For example, setting
Notes
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.
You must restart the managed
com.wily.introscope. agent.soa.metricNameFo rmatting=/:

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
application before changes to this property take effect.
APPENDIX
Introscope SPM EM extension configuration properties
This appendix includes the following topics: Introscope SPM EM extension configuration Introscope SPM EM extension properties . . . . . . . . . . . . . . . . . . . . . 326 327
Introscope SPM EM extension configuration properties 325
Introscope SPM EM extension configuration

Out-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 heres the default setting for this property:
com.wily.introscope.soa.dashboard.typeviewer.mostcritical.count
=10 3 Save and close the IntroscopeEnterpriseManager.properties file. 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.
326 Introscope SPM EM extension configuration properties
For example, change the default setting for a property such as:
=10 to a setting appropriate for your environment.
=15 Note The example above is an explanation only and not a CA Wily SOA Performance Management setting recommendation. 3 Save and close the IntroscopeEnterpriseManager.properties file. 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 Property Definition/Default Notes
This property works in
com.wily.introscope.soa.dependenc Specifies the number of hours that will ymap.aging.refresh.interval 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
conjunction with the com.wily.introscope.so a.dependencymap.agin g.expire.interval property (see below). Changes to this property take effect immediately and do not require the Enterprise Manager to be restarted.
Introscope SPM EM extension configuration 327
Property
Definition/Default
Notes
com.wily.introscope.soa.dependenc The maximum age, in days, of a This property works in ymap.aging.expire.interval dependency in the SOA Dependency conjunction with the Map. During the dependency aging com.wily.introscope.so check, the Enterprise Manager removes a.dependencymap.agin from the SOA Dependency Map all g.refresh.interval dependencies older than the specified property (see above). value. This property determines the criteria For example, if for removing a com.wily.introscope.soa.dependencym dependency which is ap.aging.expire.interval has a value of then applied during the of 60 days, then an expired (and SOA Dependency Map removed) dependency is one that has dependency aging not been re-discovered during the check. previous 60 days. Changes to this property take effect Default: 60 immediately and do not require the Enterprise Manager to be restarted. com.wily.introscope.soa.dependenc Enables or disables the Introscope SPM ymap.heuristics.clientside.enable 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. Changes to this property take effect immediately and do not require the Enterprise Manager to be restarted.
Property
Definition/Default
Notes
com.wily.introscope.soa.dependenc Enables or disables the Introscope SPM ymap.heuristics.namematch.enable 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.
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. If you create a Virtual Agent in Introscope SPM, you should enable this property. See Configuring virtual agents for Introscope SPM on page 54. Changes to this property take effect immediately and do not require the Enterprise Manager to be restarted.
Property
Definition/Default
Notes
com.wily.introscope.soa.dependenc Enables or disables the Introscope SPM ymap.heuristics.serverside.enable server-side logical equivalence heuristics rule.
the change is not retrospectively applied to previously If set to True: discovered Enables the Introscope SPM server-side dependencies. logical equivalence heuristics rule. Therefore, changing the If set to False: rule value may have unpredictable results Disables the Introscope SPM serverunless the Enterprise side logical equivalence heuristics rule. Manager is stopped and Default: True both the previously The Introscope SPM server-side logical saved SOA Dependency equivalence heuristics rule states that Map file types are two physical web service operations of deleted. For more type server are considered logically information, see To equivalent, if and only if, there exists delete, move, or rename some physical web service operation of the saved SOA type client that depends on both Dependency Map file: on operations. page 158. Typically this will only happen when the Changes to this SOA incorporates some kind of loadproperty take effect balancing mechanism such that a immediately and do not client-side web service operation call is require the Enterprise dispatched to one of several available Manager to be server-side web service operation restarted. implementations
You must restart the
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
Enterprise Manager before changes to this property take effect.
Property
com.wily.introscope.soa.deviation. art.enable
Definition/Default
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
Notes
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). You must restart the Enterprise Manager before changes to this property take effect.
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.c The number of operations per deviation ount.per.metric 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
Property
com.wily.introscope.soa.deviation. dependency.refreshrate
Definition/Default
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
Notes
com.wily.introscope.soa.deviation. errors.enable
Enables or disables the errors deviation metrics. Determines if the Introscope SPM errors deviation metrics are reported.
Each deviation metric
(Average Response Time Deviation, Errors Per Interval Deviation, or Responses Per If set to True: Interval Deviation) Introscope SPM performs calculations reported by the to provide error deviation metric data. deviation metric service If set to False: can be individually turned on (enabled) or None of the errors deviation metrics are off (disabled). reported. You must restart the Default: True Enterprise Manager before changes to this property take effect. Maximum number of total deviation metrics reported. Default: 1000
com.wily.introscope.soa.deviation. max.metric.count
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.
Property
com.wily.introscope.soa.deviation. metric.expressionlist
Definition/Default
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
Notes
Example:
deviation.metric.expressionlist=al pha1, beta2, gama3 com.wily.introscope.soa.deviation. metric.calledbackends Uses the names defined in the deviation.metric.expression list 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.deviatio
n.metric.alpha1=Frontends|Calle d Backends com.wily.introscope.soa.deviatio n.metric.calledbackends=Fronten ds|Frontends|FBApp$Frontend|Cal led Backends|FBApp$Backend
Property
com.wily.introscope.soa.deviation. usage.enable
Definition/Default
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
Notes
com.wily.introscope.soa.dashboard Enables the data for a selected .typeviewer.average.enable 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
the IntroscopeWorkstation. properties property overrides this property. You must restart the Enterprise Manager before changes to this property take effect.
IntroscopeWorkstat ion.properties file,
Property
Definition/Default
Notes
Deviation data is
com.wily.introscope.soa.dashboard Enables the data for a selected .typeviewer.response.enable operation to display in the Responses Per Interval 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 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
the
IntroscopeWorkstat ion.properties file, IntroscopeWorkstat ion.properties
property overrides this property. You must restart the Enterprise Manager before changes to this property take effect.
Deviation data is
com.wily.introscope.soa.dashboard Enables the data for a selected .typeviewer.errors.enable operation to display in the Errors Per Interval 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 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
the
Property
Definition/Default
Notes
If this property is also in
com.wily.introscope.soa.dashboard Displays the Most Critical Operations .typeviewer.mostcritical.enable 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.
the
the
property overrides this property. If set to False: You must restart the The Most Critical Operations dashboard Enterprise Manager option displays in the drop-down menu, before changes to this but no dashboard appears. Instead, an property take effect. error message appears that states: This dashboard is not available.To view it, set the com.wily.introscope.soa.dashboard.type viewer.mostcritical.enable property to true. Additionally, the Most Critical tab does not appear in the Investigator. Default: True com.wily.introscope.soa.dashboard Displays the Most Dependent .typeviewer.mostdependent.enable 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 dropdown 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.type viewer.mostdependent.enable property to true. Additionally, the Most Dependent tab does not appear in the Investigator. Default: True
the
the
Property
Definition/Default
Notes
com.wily.introscope.soa.dashboard Determines the total number of critical .typeviewer.mostcritical.count 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
the
com.wily.introscope.soa.devia tion.count.per.metric property,

which has a default value of 25. Default: 10 com.wily.introscope.soa.dashboard Determines the total number of most .typeviewer.mostdependent.count 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
the
com.wily.introscope.soa.devia tion.count.per.metric property,

which has a default value of 25. Default: 10
APPENDIX
Introscope SPM Workstation configuration properties
This appendix includes the following topics: Introscope SPM Workstation configuration . . . . . . . . . . . . . . . . . . . 340 342
IntroscopeWorkstation.properties file properties .
Introscope SPM Workstation configuration properties 339
Introscope SPM Workstation configuration

Out-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 heres 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.
340 Introscope SPM Workstation configuration properties
For example, change the default setting for a property such as:
to a setting appropriate for your environment.
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.
Introscope SPM Workstation configuration 341
IntroscopeWorkstation.properties file properties

The following properties are defined in the IntroscopeWorkstation.properties file. Property Definition/Default Notes
com.wily.introscope.soa.depe The maximum number of map nodes that ndencymap.ui.view.nodecount display on the SOA Dependency Map. If you select an Investigator node, and the number of Introscope SPM SOA Dependency Map nodes exceeds the
Workstation before changes to this property take effect.
com.wily.introscope.soa.dependencym ap.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.dependencym ap.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
Property
Definition/Default
Notes
com.wily.introscope.soa.dash Enables the data for a selected operation to Deviation data is board.typeviewer.average.ena display the Average Response Time Deviation available only if it is if graph in these Introscope SPM UI components: ble reported by the agent to the Enterprise SOA Performance - Most Critical Operations Manager, then dashboard displayed in the SOA Performance - Most Dependent Investigator. See Operations dashboard Using the Deviations Most Critical tab tab on page 118. Most Dependent tab If this property is also If set to True: in the The data for the selected operation displays in IntroscopeEnterpr the Average Response Time Deviation graph. iseManager.proper If set to False: The data for the selected operation in the Average Response Time Deviation graph does not display. Default: True
ties file, the IntroscopeWorksta tion.properties

property overrides the
IntroscopeEnterpr iseManager.proper ties property.

Workstation before changes to this property take effect. com.wily.introscope.soa.dash Enables the data for a selected operation to Deviation data is board.typeviewer.response.en display in the Responses Per Interval Deviation available only if it is if graph in these Introscope SPM UI components: able reported by the agent to the Enterprise SOA Performance - Most Critical Operations Manager, then dashboard displayed in the SOA Performance - Most Dependent Investigator. See Operations dashboard Using the Deviations Most Critical tab tab on page 118. Most Dependent tab If this property is also If set to True: in the The data for the selected operation displays in IntroscopeEnterpr the Responses Per Interval Deviation graph. iseManager.proper If set to False: The data for the selected operation in the Responses Per Interval Deviation graph does not display. Default: True


Property
Definition/Default
Notes
com.wily.introscope.soa.dash Enables the data for a selected operation to Deviation data is board.typeviewer.errors.enabl display in the Errors Per Interval Deviation available only if it is if graph in these Introscope SPM UI components: e reported by the agent to the Enterprise SOA Performance - Most Critical Operations Manager, then dashboard displayed in the SOA Performance - Most Dependent Investigator. See Operations dashboard Using the Deviations Most Critical tab tab on page 118. Most Dependent tab If this property is also If set to True: in the The data for the selected operation displays in IntroscopeEnterpr the Errors Per Interval Deviation graph. iseManager.proper If set to False: The data for the selected operation in the Errors Per Interval Deviation graph does not display. Default: True


Workstation before changes to this property take effect. com.wily.introscope.soa.dash Displays the Most Critical Operations board.typeviewer.mostcritical. dashboard in the Console and the Most Critical tab in the Investigator. enable 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
If this property is also
in the
IntroscopeEnterpr iseManager.proper ties file, the IntroscopeWorksta tion.properties


Property
Definition/Default
Notes
com.wily.introscope.soa.dash Displays the Most Dependent Operations board.typeviewer.mostdepend dashboard in the Console and the Most Dependent tab in the Investigator. ent.enable 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
in the


com.wily.introscope.soa.dash Determines the total number of critical board.typeviewer.mostcritical. operations reported by all agents in the SOA Performance - Most Critical Operations count 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
in the
com.wily.introscope.soa.deviation.c ount.per.metric property, which has a

default value of 25. Default: 10


Property
Definition/Default
Notes
com.wily.introscope.soa.dash Determines the total number of most If this property is also board.typeviewer.mostdepend dependent operations reported by the agents in the in the SOA Performance - Most Dependent ent.count IntroscopeEnterpr Operations dashboard and the Most Dependent iseManager.proper tab. ties file, the The minimum value is 0 and the maximum IntroscopeWorksta value should be less than or equal to the value tion.properties of the property overrides the
com.wily.introscope.soa.deviation.c ount.per.metric property, which has a

default value of 25. Default: 10

Workstation before changes to this property take effect. introscope.workstation.soa.de Controls the display of the metrics in the SOA pendencymap.fetchmetrics 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
I ND E X
Index
Symbols
.NET Agent configuring for cross-process transaction tracing 186 required configuration after upgrade 317 version required for ASP.NET 29, 60, 69 version required for WCF 29, 60, 69 Agent extensions configuring 42 installing 41 uninstalling 47
A
adding a filter 199 Additional dependencies not found 169 Agent extensions .NET configuring 42 installing 41 uninstalling 47 about 34 configuration propertiesIntroscopeAgent.profile, Java Agent extension configuration properties 319 Java deploying 38, 53, 64, 75, 79 extracting 35, 63, 72 uninstalling 39, 65, 78, 81 supported native SOAP engines 34 agents .NET configuring for cross-process transaction tracing 186 disconnected 158, 179 greyed out 179
renaming 179 requirements 26 virtual, configuring for Introscope SPM 54 alert states, numerical meaning in Introscope 138 application Overview tab 94 servers, supported natively 34 solving problems using cross-process transaction trace 188 applications 147 asynchronous web service invocation response times 98 average response time interpreting 98
B
back-ends 147 Blame. See Boundary Blame Boundary Blame, about 128 Busiest Operations dashboard 104
C
checklists, for installation 29, 60, 69 client Dependencies tab 116 Deviations tab 122 health causes of slowness 97 dashboard 99 node Dependencies tab display 114 Deviations tab display 119 Overview tab 94, 107 web services, definition 17
Index 347
client-server dependency relationships 147 CLR boundaries and cross-process transaction tracing 186 relationship to web services client and server 17 clustered Introscope environment 172 Collectors 173 complex filters 200 components, seeing Blamed in Investigator tree 128 configuring Agent extension properties 319 EM extension 325, 339 content type Services 162 correlated events definition 201 viewing 201 cross-process transaction Java to .NET 194 Java to Java 191 tracing and JVM/CLR boundaries 186 definition 186 how to configure for .NET Agent 186 viewing to solve problems 188
dependencymap.sav 157 deployment, verifying 55 Deviations tab 120 tabs 118 disconnected agents 158, 179 discover web services 157 documentation, Introscope 23
E
EM extension configuring 326, 340 extracting 50, 66, 82, 85 uninstalling 53, 68, 84, 87 endpoints, running Transaction Traces against 203 Enterprise Architect 177 Enterprise Manager 156, 157, 158, 159, 174, 179 disconnected agent 158 rediscover all SOA dependencies 157 environments heterogeneous, defined 186 homogeneous, defined 186 error messages viewing for SOAP faults 206 snapshot pane 206 ErrorDetector errors per interval metric 132 required installed version 29 viewing error messages 206 SOAP faults 204 web service errors 204 errors per interval metric 129, 130 tab, viewing 126 viewing 126 viewing historical in Workstation historical 206 viewing live in Workstation live 205
D
dashboard Busiest Operations 104 Most Dependent Operations 102 dashboards Client Health 99 Most Critical Operations 101 Overview, interpreting 97 Server Health 100, 102, 104 SOA Performance Overview 96 debugging options 56 Dependencies tab 114, 115 dependencies 147 SOA 156 Dependency Direct 161 dependency relationships 146 dependencymap.bak 157
348 Index
F
failures, reasons for in web service invocations 16 faults 147 filters adding 199 complex 200 removing 199 setting 200 front-ends 147
management module filename 83 IntroscopeAgent.profile 179 Investigator 161, 163, 164, 169, 175, 176
J
Java Agent extensions, extracting 35, 63, 72 Jump here in tree 171 JVM, boundaries and cross-process transaction tracing 186
L
logical equivalence 184 heuristics 157 view 166
H
hardware requirements 26 health, determining for web services 140 heterogeneous environment, defined 186 homogeneous environment, defined 186
M
management modules file name for Introscope SPM 51 file name for Introscope SPM OSB 67 file name for Introscope SPM WPS 83 upgrading 57 managerSoapEndpoint, property defined 328, 342 map. See SOA Dependency Map max metric count, parameter defined 332 method Overview tab 94, 109 metrics 159 errors per interval 129, 130 SOAP faults per interval 128, 129, 131 web services, viewing per agent 132 MOM 172 SOA Dependency Map 172 Most Critical Operations dashboard 101 tab 124, 125 tabs 124 Most Dependent Operations dashboard 102 tab 125
I
illustration sample SOA implementation 13, 14 installation checklists 29, 60, 69 directory name conventions 27 ErrorDetector prerequisite, version 29 Introscope prerequisite, version 29, 60, 69 overview 26 prerequisites 29 summary of steps 31 Introscope .NET Agent upgrade configuration changes 317 version required 40 Agent requirements 26 documents you need 23 Investigator WebServices node, defined 94 metrics 159 required installed version 29, 60, 69 viewing web services metrics in Investigator 128 Workstation, starting 95 Introscope SPM Agent extension 156, 174 management modules file name 51 metrics 159 OSB management module filename 67 uninstalling 59 WPS
Index 349
N
name conventions, for installation directories 27 namespace node Dependencies tab display 114 Deviations tab display 119 namespaces Dependencies tab 117 Deviations tab 123 node, WebServices 94
O
operation Overview tab 94, 109 operations 147 options, debugging 56 OSB 146 Overview dashboard, SOA Performance 96 tabs 105
P
partial dependency map 156 physical view 166 prerequisites .NET Agent extension 40, 56 ErrorDetector version 29 installation 29 Introscope version 29, 60, 69 Java agent extension 38, 64, 75 Primary metric 159 setting 160
R
real-time dependency relationships 146 removing a filter 199 renaming agent, and SOA Dependency map updating 179 requirements hardware/software for installation 26 Introscope Agent 26 response times asynchronous web service invocations 98 interpreting 98 synchronous web service invocations 98
S
server causes of slowness 97
Dependencies tab 116 Deviations tab 122 health, dashboard 100, 102, 104 node Dependencies tab display 114 Deviations tab display 119 Overview tab 94, 107 web services, definition 17 service-oriented architecture. See SOA services 147, 162 setting a filter 200 size, setting max SOAP size property 321 SOA about 12 dependencies 156 implementation, illustration 13, 14 SOA Dependency Map 146, 147, 148, 156 Add Dependencies 156 Additional dependencies not found 169 changing the view 171 choose a view 166 choosing a content type 161 choosing content 159 components 151 Agent icon 154 Agent name 153 Arrow showing one web service item calling another 153 Client operation icon 152, 154 Client operation name 152 Client Service icon 154 Client service icon 154 Client service name 153 Content type dropdown list 152 Fit to tab 153 Magnify a selected area 153 Pan tool 153 Primary Metric dropdown list 152 Primary Metric value 152 Roll up Dependencies button 153 Save as image button 153 Scroll bar 153 Server operation icon 153, 154 Server operation name 153 Server Service icon 154 Server service icon 153 SOA Dependency Map tab 152 Tooltips button 152
350 Index
Unroll Dependencies button 153 View dropdown list 152 Zoom in and out 153 content type 148 agent 148 Agents 162 operation 148 operations 155 service 148 Services 162, 164 defaults 155 FAQs 180 from map to Investigator 171 hide dependencies 169 Introscope node 149 Investigator 148 logical view 166 map node 155 MOM 172 node aging and removal 159 output images 177 Physical Agent view 172 Physical Services view 173 Physical view 155 physical view 166 saving the map 157 setting the content type 165 Show All Operations 155 show all operations for a service 170 show all services for an agent 170 Show Next Dependency 156 tab 147 tasks 150 tooltips metrics 161 Transaction Trace 180 triage 176 unroll dependencies levels 169 View dropdown list 166 SOA Performance Overview dashboard 96 SOAP engines, native, supported 34 faults per interval metric 128, 129, 131 viewing error messages 206 viewing in ErrorDetector 204 messages setting max size 321 soapMessageSize, property defined 321
software download site 26 requirements 26 standalone map nodes 164 synchronous web service invocations, response times 98
T
tabs application Overview 94 Client Dependencies 116 Client Deviations 122 Client Overview 94, 107 Dependencies 115 Dependencies, about 114 Deviations 120 Deviations, about 118 Errors 126 method Overview 94, 109 Most Critical 124, 125 Most Dependent 125 namespaces Dependencies 117 namespaces Deviations 123 operation Overview 94, 109 Overview, about 105 Server Dependencies 116 Server Deviations 122 Server Overview 94, 107 web services Overview 94, 108 tooltips 159, 160, 161 metrics 161 Transaction Trace 180 definitions of cross-process 186 viewing to solve problems 188 Transaction Tracer 203 transactions 147 tracking web services business 186
U
uninstalling .NET Agent extensions 47 EM extension 53, 68, 84, 87 Introscope SPM 59 Java Agent extensions 39, 65, 78, 81 upgrading .NET Agent, required configuration after management module 57 using Errors tab 126
317
Index 351
V
variables, used in this guide 27 verifying, deployment 55 virtual agents configuring for Introscope SPM definition 54
54
W
web services 146, 156, 161 business transactions, tracking 186 causes of client/server slowness 97 client, definition 17 determining health 140 discover 157 endpoints, running Transaction Trace against 203 invocations, reasons for failures 16 metrics aggregated 135, 137 viewing per agent 132 name node in Investigator 134 operation name node 135 overview of managing 12 Overview tab 94, 108 seeing in Transaction Tracer 203 server, definition 17 viewing in Investigator 128 webservices node defined 94 Dependencies tab displaying on 114 Deviations tab displaying on 119 Wily software download site 26 Workstation 156, 158, 174, 175 starting 95 using to view errors historical 206 live 205 WPS/WESB 146
352 Index

8.1 Soaperformancemanagement

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

8.1 Soaperformancemanagement

Diunggah oleh

Hak Cipta:

Format Tersedia

CA Wily Introscope SOA Performance Management

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

Introscope SPM components for monitoring WPS and WESB .

Introscope SPM Agent extension requirements .

Summary of Introscope SPM installation steps About Agent extensions . . . . . . . . . . . .

Downloading and extracting the installation archives Categories of Agent extensions

Extracting and configuring Introscope SPM .NET Agent extensions .

SOA Performance Management

Extracting Introscope SPM EM extensions

Upgrading Web Services Manager to Introscope SPM

Monitoring web services .

Introscope SPM Performance Overview dashboard .

Introscope SPM Most Dependent Operations dashboard .

Using the Most Dependent tab .

. 146 . 147 . 150 . 151 . 156 . 157 . 159

What can I accomplish using SOA Dependency Map? .

SOA Performance Management

Setting up the SOA Dependency Map .

Showing all operations for a service .

Viewing OSB metrics . About OSB metrics .

Viewing OSB tabs and metrics . Viewing Pipelines metrics . . . . . . .

OSB Transports Endpoints - Overview dashboard .

Viewing Business State Machines metrics .

SOA Performance Management

Viewing Interface Maps metrics Viewing Selectors metrics WPS Faults . . . . . . . . .

Viewing WESB tabs and metrics . Viewing Relationships metrics .

Viewing Business Objects Maps metrics Viewing Data Bindings metrics.

WESB Mediation Flows dashboard Viewing WESB dashboards . . . . . .

WESB Mediation Primitives dashboard . WESB Overview dashboard .

WESB Mediation Flows dashboard WESB Adapters dashboard . . .

WESB Mediation Primitives dashboard .

Viewing correlated events using Transaction Trace

SOA Performance Management

Introducing CA Wily Introscope SOA Performance Management

Introducing CA Wily Introscope SOA Performance Management 11

SOA Performance Management

About SOA and web services

12 Introducing CA Wily Introscope SOA Performance Management

Here are the components of a sample SOA implementation.

How Introscope SPM helps you manage SOA-based applications

How Introscope SPM helps you manage SOA-based applications 13

SOA Performance Management

Drill down on the end user experience.

Drill down on SOA infrastructure availability and performance.

Drill down on back-end availability and performance.

14 Introducing CA Wily Introscope SOA Performance Management

How Introscope SPM helps you manage SOA-based applications 15

SOA Performance Management

(faulty application logic)

About what Introscope SPM monitors

16 Introducing CA Wily Introscope SOA Performance Management

SOA infrastructure, especially the ESB and BPMS.

How Introscope SPM monitors SOA-based applications

How Introscope SPM monitors SOA-based applications 17

SOA Performance Management

By using Introscope SPM and Introscope together you can:

and reporting on web service faults and errors

exceeding response time, transaction volume, and/or error thresholds

About SOA dependencies types

Introscope SPM components

18 Introducing CA Wily Introscope SOA Performance Management

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

Introscope SPM components 19