APM - 9.5 Transaction Definition Guide

Transaction Definition Guide
Release 9.5
CA Application Performance
Management

This Documentation, which includes embedded help systems and electronically distributed materials, (hereinafter referred to
as the Documentation) is for your informational purposes only and is subject to change or withdrawal by CA at any time.
This Documentation may not be copied, transferred, reproduced, disclosed, modified or duplicated, in whole or in part, without
the prior written consent of CA. This Documentation is confidential and proprietary information of CA and may not be disclosed
by you or used for any purpose other than as may be permitted in (i) a separate agreement between you and CA governing
your use of the CA software to which the Documentation relates; or (ii) a separate confidentiality agreement between you and
CA.
Notwithstanding the foregoing, if you are a licensed user of the software product(s) addressed in the Documentation, you may
print or otherwise make available a reasonable number of copies of the Documentation for internal use by you and your
employees in connection with that software, provided that all CA copyright notices and legends are affixed to each reproduced
copy.
The right to print or otherwise make available copies of the Documentation is limited to the period during which the applicable
license for such software remains in full force and effect. Should the license terminate for any reason, it is your responsibility to
certify in writing to CA that all copies and partial copies of the Documentation have been returned to CA or destroyed.
TO THE EXTENT PERMITTED BY APPLICABLE LAW, CA PROVIDES THIS DOCUMENTATION AS IS WITHOUT WARRANTY OF ANY
KIND, INCLUDING WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, OR NONINFRINGEMENT. IN NO EVENT WILL CA BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY LOSS OR DAMAGE,
DIRECT OR INDIRECT, FROM THE USE OF THIS DOCUMENTATION, INCLUDING WITHOUT LIMITATION, LOST PROFITS, LOST
INVESTMENT, BUSINESS INTERRUPTION, GOODWILL, OR LOST DATA, EVEN IF CA IS EXPRESSLY ADVISED IN ADVANCE OF THE
POSSIBILITY OF SUCH LOSS OR DAMAGE.
The use of any software product referenced in the Documentation is governed by the applicable license agreement and such
license agreement is not modified in any way by the terms of this notice.
The manufacturer of this Documentation is CA.
Provided with Restricted Rights. Use, duplication or disclosure by the United States Government is subject to the restrictions
set forth in FAR Sections 12.212, 52.227-14, and 52.227-19(c)(1) - (2) and DFARS Section 252.227-7014(b)(3), as applicable, or
their successors.
Copyright 2013 CA. All rights reserved. All trademarks, trade names, service marks, and logos referenced herein belong to
their respective companies.

CA Technologies Product References
This document references the following CA Technologies products and features:
CA Application Performance Management (CA APM)
CA Application Performance Management ChangeDetector (CA APM
ChangeDetector)
CA Application Performance Management ErrorDetector (CA APM ErrorDetector)
CA Application Performance Management for CA Database Performance (CA APM
for CA Database Performance)
CA Application Performance Management for CA SiteMinder (CA APM for CA
SiteMinder)
CA Application Performance Management for CA SiteMinder Application Server
Agents (CA APM for CA SiteMinder ASA)
CA Application Performance Management for IBM CICS Transaction Gateway (CA
APM for IBM CICS Transaction Gateway)
CA Application Performance Management for IBM WebSphere Application Server
(CA APM for IBM WebSphere Application Server)
CA Application Performance Management for IBM WebSphere Distributed
Environments (CA APM for IBM WebSphere Distributed Environments)
CA Application Performance Management for IBM WebSphere MQ (CA APM for
IBM WebSphere MQ)
CA Application Performance Management for IBM WebSphere Portal (CA APM for
IBM WebSphere Portal)
CA Application Performance Management for IBM WebSphere Process Server (CA
APM for IBM WebSphere Process Server)
CA Application Performance Management for IBM z/OS (CA APM for IBM z/OS)
CA Application Performance Management for Microsoft SharePoint (CA APM for
Microsoft SharePoint)
CA Application Performance Management for Oracle Databases (CA APM for Oracle
Databases)
CA Application Performance Management for Oracle Service Bus (CA APM for
Oracle Service Bus)
CA Application Performance Management for Oracle WebLogic Portal (CA APM for
Oracle WebLogic Portal)
CA Application Performance Management for Oracle WebLogic Server (CA APM for
Oracle WebLogic Server)
CA Application Performance Management for SOA (CA APM for SOA)

CA Application Performance Management for TIBCO BusinessWorks (CA APM for
TIBCO BusinessWorks)
CA Application Performance Management for TIBCO Enterprise Message Service
(CA APM for TIBCO Enterprise Message Service)
CA Application Performance Management for Web Servers (CA APM for Web
Servers)
CA Application Performance Management for webMethods Broker (CA APM for
webMethods Broker)
CA Application Performance Management for webMethods Integration Server (CA
APM for webMethods Integration Server)
CA Application Performance Management Integration for CA CMDB (CA APM
Integration for CA CMDB)
CA Application Performance Management Integration for CA NSM (CA APM
Integration for CA NSM)
CA Application Performance Management LeakHunter (CA APM LeakHunter)
CA Application Performance Management Transaction Generator (CA APM TG)
CA Cross-Enterprise Application Performance Management
CA Customer Experience Manager (CA CEM)
CA Embedded Entitlements Manager (CA EEM)
CA eHealth Performance Manager (CA eHealth)
CA Insight Database Performance Monitor for DB2 for z/OS
CA Introscope
CA SiteMinder
CA Spectrum Infrastructure Manager (CA Spectrum)
CA SYSVIEW Performance Management (CA SYSVIEW)

Contact CA Technologies
Contact CA Support
For your convenience, CA Technologies provides one site where you can access the
information that you need for your Home Office, Small Business, and Enterprise CA
Technologies products. At http://ca.com/support, you can access the following
resources:
Online and telephone contact information for technical assistance and customer
services
Information about user communities and forums
Product and documentation downloads
CA Support policies and guidelines
Other helpful resources appropriate for your product
Providing Feedback About Product Documentation
If you have comments or questions about CA Technologies product documentation, you
can send a message to techpubs@ca.com.
To provide feedback about CA Technologies product documentation, complete our
short customer survey which is available on the CA Support website at
http://ca.com/docs.

Contents 7

Contents

Chapter 1: Introducing the transaction definition process 13
About this Guide ........................................................................................................................................................ 13
What you need to know ...................................................................................................................................... 14
About transaction identification ................................................................................................................................ 14
HTTP request parameter types ........................................................................................................................... 14
Response-based transactions ............................................................................................................................. 16
HTTP and HTML Response parameter types ....................................................................................................... 17
Monitoring Flex applications ............................................................................................................................... 18
Flex parameter types .......................................................................................................................................... 19
Transaction hierarchy ......................................................................................................................................... 19
About creating transaction definitions ............................................................................................................... 22
Identifying transactions based on the response ................................................................................................. 23
Transaction signature promotion process .......................................................................................................... 24
Process for creating transaction definitions .............................................................................................................. 24
Access the CEM Console ............................................................................................................................................ 25
Troubleshooting Login to CA CEM .............................................................................................................................. 26
Chapter 2: Defining business applications and services 27
Business application hierarchy ................................................................................................................................... 27
Defining a business application .................................................................................................................................. 28
Troubleshooting case sensitivity for login names ............................................................................................... 31
About defining business application identifiers ......................................................................................................... 31
Defining session identifiers ........................................................................................................................................ 32
Defining user identifiers ............................................................................................................................................. 34
Using the client IP address to identify users .............................................................................................................. 36
Identify users by client IP address and user group by IP subnet or by user group by IP subnet alone? .................... 38
Defining interim session identifiers ............................................................................................................................ 39
Example interim session identification using Location Query ............................................................................ 40
Defining user group identifiers................................................................................................................................... 41
Offset and Length examples ....................................................................................................................................... 42
Using XML to identify sessions, users, and user groups ............................................................................................. 42
Defining identifiers for NTLM authentication ............................................................................................................ 44
Using path parameters to identify sessions ............................................................................................................... 44
Setting the global delimiter for path parameters ...................................................................................................... 46
Defining business services .......................................................................................................................................... 47

8 Transaction Definition Guide

Chapter 3: Recording transaction signatures 49
CA CEM recorder types .............................................................................................................................................. 50
Turning off web page caching .................................................................................................................................... 50
Setting up for recording with a proxy server ............................................................................................................. 51
Monitoring traffic behind a proxy server ............................................................................................................ 52
Deactivate traffic monitoring on your client computer ...................................................................................... 53
Using the TIM recorder .............................................................................................................................................. 53
About content-types for recording sessions ....................................................................................................... 54
About unrecognized transaction components .................................................................................................... 54
Enabling transaction recording ........................................................................................................................... 55
Starting a Recording ............................................................................................................................................ 55
Stopping a TIM recorder session ......................................................................................................................... 60
Using the script recorder ............................................................................................................................................ 61
Installing the script recorder ............................................................................................................................... 61
Input script file types .......................................................................................................................................... 61
VuGen trace files ................................................................................................................................................. 61
Pcap files ............................................................................................................................................................. 62
Command line instructions ................................................................................................................................. 63
Viewing recording sessions ........................................................................................................................................ 63
Viewing the recording session transactions ........................................................................................................ 64
Viewing the recording session parameter map .................................................................................................. 65
Viewing the recording session transaction components .................................................................................... 67
Editing recording sessions .......................................................................................................................................... 67
Troubleshooting transaction recording ...................................................................................................................... 68
Chapter 4: Introscope agent recording 69
About recording with the Introscope agent ............................................................................................................... 69
About upgrading to CA APM 9.x ................................................................................................................................. 70
Process for recording transactions ............................................................................................................................. 70
Enable agent recording .............................................................................................................................................. 71
Enabling agent recording in the agent profile..................................................................................................... 72
Turning off web page caching ............................................................................................................................. 72
Accessing the CEM console ................................................................................................................................. 73
Setting up a business application ............................................................................................................................... 73
Setting up a business service...................................................................................................................................... 74
Setting up an agent filter ............................................................................................................................................ 75
Recording a business transaction ............................................................................................................................... 76
Known limitations ............................................................................................................................................... 77
Starting an agent recording session ........................................................................................................................... 79
Agent recording and proxy servers ............................................................................................................................ 82
Recording with an agent (no proxy server) ......................................................................................................... 83

Contents 9

Recording with an agent through a proxy server ................................................................................................ 83
Viewing recording sessions ........................................................................................................................................ 85
Viewing the recording session transactions ........................................................................................................ 85
Viewing the recording session parameter map .................................................................................................. 86
Editing recording sessions .......................................................................................................................................... 87
Promoting transactions to definitions ........................................................................................................................ 88
Chapter 5: Automatically discovering transactions 91
About automatic transaction discovery ..................................................................................................................... 92
Creating a template and parameters ......................................................................................................................... 93
URL Path Filter examples .................................................................................................................................... 95
Any type example................................................................................................................................................ 95
Multiple transactions discovered from one template ........................................................................................ 96
Transaction naming example .............................................................................................................................. 96
Path parameter example .................................................................................................................................... 97
A catchall example .............................................................................................................................................. 97
The order in which templates are created .......................................................................................................... 98
Enabling templates ..................................................................................................................................................... 98
Editing templates ....................................................................................................................................................... 98
Selecting the TIMs for automatic transaction discovery ............................................................................................ 99
Starting automatic transaction discovery ................................................................................................................ 100
Stopping automatic transaction discovery ............................................................................................................... 101
Stopping the Transaction Discovery Collection Service .................................................................................... 101
Stopping automatic transaction discovery, but not stopping the service ........................................................ 101
Viewing discovered transactions .............................................................................................................................. 102
Monitoring discovered transactions ........................................................................................................................ 103
Automatically discovering components ................................................................................................................... 103
Troubleshooting automatic transaction discovery .................................................................................................. 105
Chapter 6: Defining transactions 109
About transaction definitions and identifiers .......................................................................................................... 109
About edits to request and response identifiers...................................................................................................... 110
Promoting transaction signatures to definitions...................................................................................................... 110
Creating Business Transactions ................................................................................................................................ 111
Editing transactions .................................................................................................................................................. 113
Editing transaction components .............................................................................................................................. 116
Wildcarding parameter names ................................................................................................................................. 119
Using XML to identify transactions .......................................................................................................................... 120
Adding and deleting parameters .............................................................................................................................. 122
About defining defects ............................................................................................................................................. 124
Defining business transaction defects...................................................................................................................... 125


Locate business transaction defect conditions ................................................................................................. 125
Modify a Defect Type Condition ....................................................................................................................... 125
Lock or Unlock a Defect Type Condition ........................................................................................................... 126
Set the baseline for a defect condition ............................................................................................................. 126
Defining transaction defects .................................................................................................................................... 127
Defining component defects .................................................................................................................................... 128
Viewing access policies for business services .......................................................................................................... 130
Adding access policies for business services ............................................................................................................ 131
Monitoring transactions ........................................................................................................................................... 134
Enabling transaction definitions ....................................................................................................................... 134
Enabling transaction monitoring ....................................................................................................................... 135
Synchronizing to TIMs, agents, WebView, and Workstation ............................................................................ 135
Chapter 7: Managing your transactions 137
About reviewing your transactions .......................................................................................................................... 137
Verifying transactions with CA CEM performance reports ...................................................................................... 138
Troubleshooting tips for transactions ...................................................................................................................... 139
Transactions were being recognized but suddenly stopped ............................................................................. 140
Observe the transactions being monitored by the TIM .................................................................................... 140
Too many missing response defects ................................................................................................................. 142
Problems with transactions that contain path parameters .............................................................................. 143
Troubleshooting response-based transactions ................................................................................................. 143
Troubleshooting Flex transactions .................................................................................................................... 143
Managing transaction settings with CA CEM ........................................................................................................... 144
Modifying business service and transaction settings ........................................................................................ 144
Modifying behavioral defect settings ............................................................................................................... 146
Modifying SLA success settings ......................................................................................................................... 148
Managing transaction settings with bulk editing ..................................................................................................... 148
Modifying business transaction settings ........................................................................................................... 149
Modifying defect conditions ............................................................................................................................. 150
Modifying user settings ..................................................................................................................................... 150
Exporting and importing business transaction definitions ....................................................................................... 151
Additional information about exporting and importing business transaction definitions ............................... 152
Moving business transactions between business services ...................................................................................... 152
Managing transaction definitions ............................................................................................................................ 153
Usage example: TIM performance .................................................................................................................... 155
Usage example: Troubleshooting...................................................................................................................... 155
Usage example: Transaction statistics .............................................................................................................. 155
Replacing existing business transaction definitions ................................................................................................. 156

Contents 11

Chapter 8: Identifying transactions using the HTTP analyzer plug-in 157
About the HTTP analyzer plug-in .............................................................................................................................. 158
HTTP analyzer plug-in overview ............................................................................................................................... 158
About using the HTTP analyzer plug-in .................................................................................................................... 160
Important cautions when deploying the HTTP analyzer plug-in ....................................................................... 161
Best practices when deploying the HTTP analyzer plug-in ............................................................................... 161
Deploying multiple HTTP analyzer plug-ins ....................................................................................................... 162
Handling XML data using the HTTP analyzer plug-in......................................................................................... 162
Process for deploying the HTTP analyzer plug-in ..................................................................................................... 163
Downloading the HTTP analyzer plug-in SDK ........................................................................................................... 164
Using the SDK to create an HTTP analyzer plug-in ................................................................................................... 165
Configuring an HTTP analyzer plug-in ...................................................................................................................... 166
Modifying an HTTP analyzer plug-in ......................................................................................................................... 168
Enabling an HTTP analyzer plug-in ........................................................................................................................... 170
Enabling and disabling TIM monitors ....................................................................................................................... 170
Testing an HTTP analyzer plug-in ............................................................................................................................. 170
Verifying an HTTP analyzer plug-in in the CEM console ........................................................................................... 173
Verifying an HTTP analyzer plug-in on the TIM ........................................................................................................ 174
Disabling an HTTP analyzer plug-in .......................................................................................................................... 177
Troubleshooting the HTTP analyzer plug-in SDK ...................................................................................................... 177
Events and logs ................................................................................................................................................. 177
TIM status ......................................................................................................................................................... 179
Transaction identification ................................................................................................................................. 181
User interface .................................................................................................................................................... 182
Code and compiler ............................................................................................................................................ 182
Chapter 9: Monitoring multibyte transactions 185
Process for using multibyte with CA CEM ................................................................................................................ 185
About using multibyte character sets with CA CEM ................................................................................................. 186
Before using multibyte with CA CEM ....................................................................................................................... 187
Configuring applications for multibyte characters ................................................................................................... 187
Recording multibyte transactions ............................................................................................................................ 189
Promoting multibyte transactions ........................................................................................................................... 190
Moving multibyte business transactions.................................................................................................................. 191
Special considerations for multibyte transaction monitoring .................................................................................. 192
CA CEM limitations for multibyte support ........................................................................................................ 192
Using export with multibyte business transactions .......................................................................................... 192
Using Save to CSV with multibyte business transactions .................................................................................. 193
Using regular expressions with multibyte transactions .................................................................................... 193
Using offsets with multibyte business transactions .......................................................................................... 193
Using automatic transaction discovery with multibyte applications ................................................................ 193


Using the HTTP analyzer plug-in with multibyte applications........................................................................... 194
Troubleshooting multibyte with CA CEM ................................................................................................................. 194
Appendix A: HTTP status codes 197
100 series: informational status codes .................................................................................................................... 197
200 series: success status codes .............................................................................................................................. 197
300 series: redirection status codes ......................................................................................................................... 198
400 series: client error status codes ........................................................................................................................ 198
500 series: server error status codes ....................................................................................................................... 199
Appendix B: Regular expressions in CA CEM 201
BizTrxHttpTracer ...................................................................................................................................................... 201
CEMTracer ................................................................................................................................................................ 201
CA CEM TIM .............................................................................................................................................................. 202
CA CEM ..................................................................................................................................................................... 202
CA CEM NSM bridge ................................................................................................................................................. 202
Regular expressions resources ................................................................................................................................. 202
Jakarta-ORO ...................................................................................................................................................... 203
PCRE Perl-compatible regular expressions ................................................................................................... 203
Java .................................................................................................................................................................... 203
Appendix C: Transaction Definition Troubleshooting 205
Index 207


Chapter 1: Introducing the transaction
definition process

CA CEM provides real-time visibility into your users (internal and external) transactions,
and monitors your users transactions to isolate the causes of problems in the data
center. CA CEM measures the performance and quality of transactions, identifies
defects and variance, and quantifies the impact on users and the business. By
proactively detecting trends in degraded transaction response times and providing
various actionable reports, CA CEM enables you to act before a problem occurs or
Service Level Agreements (SLAs) are out of compliance.
This chapter provides an overview of how IT organizations can use CA CEM to define
user transactions in IT production environments.
This section contains the following topics:
About this Guide (see page 13)
About transaction identification (see page 14)
Process for creating transaction definitions (see page 24)
Access the CEM Console (see page 25)
Troubleshooting Login to CA CEM (see page 26)
About this Guide
This guide is intended for the person who is responsible for creating transaction
definitions.
The final chapter is an exception: the audience for Identifying transactions using the
HTTP analyzer plug-in is primarily Java developers who are designing and testing their
own Java code for the HTTP analyzer plug-in.
The purpose of this guide is to help administrators establish and maintain business
applications, business services, and transaction definitions.
This guide assumes that:
CA APM has been installed according to the information in the CA APM Installation
and Upgrade Guide.
You have a basic understanding of CA APM and CA CEM as described in the CA APM
Overview Guide.
About transaction identification


What you need to know
To use this guide, you need a working knowledge of CA CEM administration and the user
transactions that you record, define, verify, and maintain for CA CEM.
We assume that you already have a working understanding of HTTP and Flex
transactions.
For information about configuring and administering CA CEM, see the CA APM
Configuration and Administration Guide.
Transaction identification is the process of defining unique transactions that can be
distinguished from other transactions.
The transaction definition process provides a way to refine unique transaction
signatures. For example, a user logs on to your site and submits a form to the HR
department. Correctly specified transaction definitions enable CA APM to identify the
user login transaction and the HR form submission transaction as two distinct
transactions.
HTTP request parameter types
CA CEM identifies transactions based on HTTP name/value pairs observed in traffic
between the client browser and the web server. These HTTP name/value pairs are
named HTTP parameters. HTTP parameters consist of a type, a name, and a value. These
parameters appear in the header and body of an HTTP request.
An HTTP Request contains a method, a URL, request headers, and optionally a request
body.
To identify a transaction based on the HTTP request parameters, you can specify any of
the following:
HTTP parameters in the HTTP Request
Flex properties in the HTTP Request body


For example, following are some of the common HTTP parameters to identify
transactions based on the request:
Cookie
Cookie parameters are name/value pairs that appear in the Cookie: request-header.
Post
Post parameters are name/value pairs that appear in the HTTP Post request-body
when a POST method is used.
Query
Query parameters are name/value pairs that appear in the URL after the first ?
character.
URL
URL parameters are the host name, path, and port number values that appear in
the URL before the first ? character.
HTTP Request
HTTP Request parameters can be used to match fields in the HTTP header that the
client sends to the server.
HTTP Request Header
HTTP Header parameters are name/value pairs that appear in the HTTP Header.
Following is a simple example of an HTTP Request header, and the corresponding
parameters you would use to identify the transaction.
Example HTTP request:
POST /dir/file.html?P1=V1&P2=V2 HTTP/1.1
Host: www.company.com
Cookie: P3=V3; P4=V4
Content-Type: application/www-form-urlencoded
P5=V5&P6=V6
Accept-Language: en-us
Corresponding HTTP parameters:
URL Host=www.company.com
URL Path=/dir/file.html
Query P1=V1
Query P2=V2
Cookie P3=V3
Cookie P4=V4
POST P5=V5
POST P6=V6
name=Accept-Language value=en-us


Note: CA CEM can also identify transactions that are not based directly on HTTP. For
example, CA CEM can identify transactions based on XML strings and on values returned
by a custom-coded plug-in (the HTTP analyzer plug-in).
Response-based transactions
You can now record, define, and monitor transactions and also capture response
parameters in addition to the request.
For example, some web applications display different page elements according to the
end user's access authorization or what tasks the user has already performed. In this
case, a single request can generate multiple responses.
You can identify response-based transactions according to any of the following:
HTTP Response header
HTTP Response status
HTML response tag in the HTTP response body
Adobe Flex request and response parameters
If you use the HTTP Analyzer plug-in, be aware that now CA CEM passes both request
and response data to the plug-in. Previously, CA CEM passed only the request data. If
you do not want the plug-in to process the extra overhead, use version 1 of the plug-in
API.
More information
HTTP and HTML Response parameter types (see page 17)
Best practices when deploying the HTTP analyzer plug-in (see page 161)
Troubleshooting response-based transactions (see page 143)
About content-types for recording sessions (see page 54)
Flex parameter types (see page 19)



HTTP and HTML Response parameter types
An HTTP Response contains a status code, response headers, and typically a response
body. The only way to create a response-based transaction definition is to do so from a
request-based transaction.
To identify transactions based on the response, you can specify any of the following:
HTTP response status code
HTTP parameters that appear in the HTTP Response
HTML tags that appear in the HTTP Response body.
Flex response properties that appear in the HTTP Response body.
HTTP Response
The first line of an HTTP response contains the HTTP Response status code (in
addition to the HTTP version and HTTP Response status description).
HTTP Response Header
The HTTP Response header information can include information such as server
version, date last modified, content type, or data your applications need.
HTML Response Tag
You can also identify transactions based on a unique value for an HTML tag in the
response body. For example, you can identify transactions that have a specific value
for the <title> tag. Although technically you can specify any HTML tag, be sure to
use a tag that uniquely identifies the transaction.
Following are examples of how to use each of these parameter types.
Example HTTP Response status lines:
HTTP/1.1 - 404 Not Found
HTTP/1.1 - 200 OK
Example HTTP response parameters:
Status Matches "200"
Status Matches "4*"
Example HTTP Response Header:
HTTP/1.1 200 OK
Date: Tue, 12 Apr 2011 23:09:08 GMT
Server: Apache/2.2.16
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Type: text/html
Content-Length: 159796
Proxy-Connection: Keep-Alive
Connection: Keep-Alive


Corresponding HTTP Response parameters:
Status Matches "200"
Server Matches "Apache*"
Content-Type matches "text/*"
Additional notes about HTML tags
Following are some additional things to know about using HTML tags to define
transactions in CA CEM:
Do not use < or > when defining an HTML tag parameter.
TIM searches transactions for response tag based on the MaxResponseBodySize
setting on the TIM. The default is 2000 and the maximum is 10000.
If an HTML tag in a transaction is either not well formed or the end tag is
undetermined, TIM matches 200 characters from the start of the tag.
Empty tags can be matched for non-existence so that you can make sure
transactions do not have empty HTML tags.
If there are multiple instances of the same HTML tag in an HTML response body,
TIM matches on the first instance in the transaction.
To specify HTML comment tags, specify !-- in the transaction definition. HTML
comment tags begin with .
Monitoring Flex applications
You can now record, identify, and monitor transactions in Adobe Flex applications that
use AMF 3. These applications communicate between the web browser Adobe Flash
plug-in and the web server.


Flex parameter types
If your web applications use Adobe Flex objects or Adobe Flash, you can monitor
parameters that are unique to these types of applications. Adobe Flash or Flex
applications use binary or XML objects to pass data between the client and server. CA
CEM can parse the data in the Flex-specific properties that accompany the Flex
application data.
You can specify Flex properties to identify transactions based on the request or
response. Flex information is in the body of the HTTP request or response.
You can specify any of the following to identify transactions:
Flex HTTP Request Header to identify transactions based on the request
Flex Request Properties to identify transactions based on the request
Flex Response Properties to identify transactions based on the response
Flex HTTP Request Headers
The Flex HTTP Request Header is the header information for the Flex data and
appears in the HTTP body. Flex HTTP Request Headers are similar to HTTP Headers,
but are within the Flex data.
Flex Request Properties
messagetype, destination, source, operation, contenttype, method, url
Flex Response Properties
messageType, destination
Transaction hierarchy
Each CA CEM system has one domain, and business services and transactions are
associated with that domain. (Business applications are associated with business
services.)
Business Service group of business transactions within CA CEM.
Business Transaction set of transactions
Transaction set of transaction components
Transaction component URL retrieval
- Transaction parameter a name/value pair
Note: In Introscope, transactions are sometimes called Business Transaction
Components. For example, in the application triage map display in Workstation,
transactions are displayed as Business Transaction Components.


Hierarchy example:
Local Domain Domain
Siebel Call Center Business Service:
ExecuteLogin Business Transaction
Execute Login (SWE) Transaction
rtcEditor.js Transaction Component
jctrls.css Transaction Component
wait.html Transaction
GCF_swe Transaction
GCF_sweapp Transaction
GCF_swecdawksp Transaction
GCF_sweattachment Transaction
GotoPostedAction Transaction


Avitek Financial Business Service:
Buy Business Transaction
Buy Transaction (identifying)
Submit Buy Transaction Component (identifying)
main.css Transaction Component
portal_header.gif Transaction Component
customize.gif Transaction Component
setpassword.gif Transaction Component
logout.gif Transaction Component
transparent.gif Transaction Component
v_home.gif Transaction Component
web.gif Transaction Component
quote.gif Transaction Component
portlet_unedit.gif Transaction Component
up.gif Transaction Component
down.gif Transaction Component
buy.gif Transaction Component
sell.gif Transaction Component
portal_footer.gif Transaction Component
Other non-identifying transactions Transaction


Corresponding response-based transaction:
Buy_Response Business Transaction
Buy_Response Transaction (Identifying)
Buy_Response Transaction Component (Identifying)
main.css Transaction Component
portal_header.gif Transaction Component
customize.gif Transaction Component
setpassword.gif Transaction Component
logout.gif Transaction Component
transparent.gif Transaction Component
v_home.gif Transaction Component
web.gif Transaction Component
quote.gif Transaction Component
portlet_unedit.gif Transaction Component
up.gif Transaction Component
down.gif Transaction Component
buy.gif Transaction Component
sell.gif Transaction Component
portal_footer.gif Transaction Component

About creating transaction definitions
You identify transactions based on the request transaction, or based on the request and
the associated response. The CA CEM recorders analyze the transaction and extracts
HTTP/HTTPS identification parameters from the request and response headers and
content.
When you have uniquely identified a transaction, you can create transaction definitions
to analyze your traffic. You can create a transaction definition by:
Using the agent recorder to record transaction signatures, identifying transaction
information only, as monitored by the agents you specify.
Using CA APM TG scripts, which are built in CA APM TG, to generate CA CEM
business transaction definitions.


Using automatic transaction discovery to have CA CEM discover transactions for
you, based on bounding parameters that you configure.
Using the TIM recorder to record transaction signatures, and then promoting
transaction signatures to transaction definitions.
Using the script recorder, importing transaction definitions from other products.
Using business transaction export and import to copy a business transaction
definition from one CA CEM system to another.
Creating your own transaction definition manually, without recording.
Creating a response-based business transaction based on a request transaction.
For more information about CA APM TG scripts, see the CA APM Transaction Generator
Implementation Guide.
Identifying transactions based on the response
When identifying transactions to monitor, you first identify the request transaction.
Then you select the request transaction definition and create a response transaction
that extends from that request.
Often people customize applications so that the response page is slightly different,
depending on the requesting user. Following are some examples of cases when
response-based transaction identification is useful:
Some users qualify for a special promotion. Response pages for this subset of users
include an additional section of promotional content. In this case, you have multiple
response transactions based on a single request transaction.
Some users have restricted access and some content does not display for these
users. For example, the response page for these users does not display an
additional page frame.
Based on the user and the session, the application displays different content. For
example, different users of a portal may have configured it to display different
widgets.
Identify transactions based on the response status codes so that defects are
generated when the HTTP defect status codes occur (these defect codes are the 4xx
and 5xx HTTP status codes).
Note: You do not record or discover response-based transactions directly. You need to
discover or record a request-based transaction and then extend the request-based
transaction to create a response-based transaction.
Process for creating transaction definitions


Transaction signature promotion process
Transaction definitions can be created easily from user activity that CA CEM observes.
Recordings of user activity can be used as a means to discover generalized transaction
signatures.
After you have collected transaction signatures through a CA CEM recording session,
you can promote the signatures to transaction definitions, which you can use in your
transaction analysis. For example, when a user submits an HR form, the transaction
recorded by CA CEM is saved as a transaction signature.
Signature promotion makes creating transaction definitions easy.
After you promote the signatures to definitions, you can edit the definition components
to specify further which types of transactions to capture. For example, you can
generalize from the transaction signature so that transactions of all users submitting HR
forms are captured rather than just the one from the transaction recording.
Process for creating transaction definitions
Following is an overview of the tasks you perform when creating transaction definitions.
Follow these steps:
1. Define the domain. See the CA APM Configuration and Administration Guide.
2. Define a business application and user identifiers within the business application.
(see page 28)
3. Define a business service associated with the business application. (see page 47)
4. Create transaction definitions. Use automatic transaction discovery (see page 91) to
find transactions performed by your web application users and then create
transaction definitions based on these actual transactions.
Alternatives for step 4:
You can perform step 4 in a less automated way:
Record transactions (see page 49) from a particular browser.
Take a transaction signature you recorded and promote it as a transaction
definition (see page 110) in the business service you created.
Edit the specific transaction definition (see page 113) to a generalized
transaction definition using pattern matching, defect specifications, and
component specifications.
If you have Introscope without CA APM, then you can only do agent recording
(see page 69).
Access the CEM Console


5. If desired, create (see page 111) a response-based transaction definition that
extends from a request-based transaction definition.
6. Specify what transactions are considered defective at each level. (see page 124)
Business transaction defects
Transaction defects
Component defects
7. Enable the transaction definition for monitoring. (see page 134)
8. Verify that the transactions are being monitored correctly. (see page 137)
Access the CEM Console
You can set up and administer business applications, business services, and transaction
definitions from any computer that has a web browser.
The CEM console is the main user interface of CA CEM. Administrators use it to set up
and configure CA CEM, including transaction recording and creating transaction
definitions. Analysts use it to produce and view reports.
If you are an administrator, the CEM console will have additional menu options.
Additionally, if no TIMs are enabled, certain CA CEM links do not appear.
(If no TIMs are enabled, the Tools and CA CEM links do not appear.)
Unless otherwise indicated, this guide assumes that you are using the CEM console as
an administrator.
Troubleshooting Login to CA CEM


In a clustered environment, the CEM console is on the Manager of Managers (MOM).
Follow these steps:
1. Open a web browser and type the address:
http://<IP_Address>:8081/wily
where <IP_Address> is the IP address or DNS name for the MOM or a standalone
Enterprise Manager. For example:
http://192.168.1.54:8081/wily
http://cem.company.com:8081/wily
To use a DNS name, your DNS administrator must have configured it.
Note: The default port is 8081. It is defined in the
IntroscopeEnterpriseManager.properties file as
introscope.enterprisemanager.webserver.port=8081
and can be changed.
2. Enter the user name and password.
The default user name for the CA CEM administrator is cemadmin.
The CEM console appears.
For information about security and logins, see the CA APM Security Guide.
Troubleshooting Login to CA CEM
Symptom:
If you are unable to log in to CA CEM, verify that Active Scripting is enabled on your
browser.
If Active Scripting is disabled, when you click Log In on the CA CEM login page, you are
redirected to a CEM Console / Back page. This happens even when your User Name and
Password have been entered correctly.
Solution:
To enable Active Scripting, see the user documentation for your browser. For example,
in Internet Explorer 8, the setting is under Internet Options > Security > Custom level >
Scripting > Active scripting.


Chapter 2: Defining business applications
and services

Business applications are used to store application-specific information such as session
identification and user identification. Business services include transaction definitions.
Before you define transactions, you must first create a business application and a
business service associated with the business application to store the transactions.
This process describes the order in which you should define the CA CEM domain,
business applications, and business services.
Follow these steps:
1. Define the CA CEM domain. This is usually done as a part of CA CEM setup. (See the
CA APM Configuration and Administration Guide.)
2. Define a business application (see page 28).
3. Define user (see page 34), session (see page 32), and interim session (see page 39)
identifiers for the business application; identify user groups (see page 41).
4. Define the business service associated with the business application (see page 47).
Business application hierarchy
Each organization has one domain, and business services and business applications are
associated with it.
Business application is an attribute of a business service. Each business service is
associated with one business application. The business application might be a
financial or product ordering application (for example, Siebel).
Business Service consists of groups of business transactions.
Defining a business application


About the default application
CA CEM comes with a default business application. You cannot delete or rename the
default application. When you select Ignore Applications in User Recognition (Setup >
Domain), then the case sensitivity for login names is determined by the Default
Application and the value set for this check box in other business applications is ignored.

Note: If you renamed the default application in a previous version of CA CEM and want
to change it back to "Default Application," contact CA Support.
To gain the highest value from CA CEM, describe fundamental characteristics of the
application. These parameters affect the way CA CEM identifies users and monitors
business application statistics.
Follow these steps:
1. Select Administration, Business Applications.
2. Click New to create a business application.
3. Complete the required information and click Save.
Name
Give a meaningful name to the business application. The business application name
is not case-sensitive.
Description
Add a comment about the business application.


Type
Select Generic or Siebel.
Authentication Type
Select the appropriate type for your business application.
Application Specific
If your business application provides its own authentication mechanism (For
example, through a cookie, post, query, or URL parameter).
Basic Authentication
If your organization or your business application does not provide authentication,
then CA CEM uses a standard HTTP protocol for prompting the user for a user name
and password.
SiteMinder
Select SiteMinder if your organization is using CA SiteMinder to manage sessions.
NTLM Authentication
Select if your organization is using the Windows NT LAN Manager
challenge-response mechanism for authentication. (See Defining identifiers for
NTLM authentication (see page 44) for more information.)
Case-Sensitive URL Path
Select this check box if you want the URL to be treated as case-sensitive. For web
servers running on Windows, clear this check box. For web servers running on other
operating systems, select this check box.
Case-Sensitive Login Names
Select this check box if you want User Names to be treated as case-sensitive. For
web servers running on Windows, clear this check box. For web servers running on
other operating systems, select this check box.
Note: If you select case-sensitive login names, you cannot change later to case
insensitive login names if it will result in a user name conflict. For example, if the
business application has users named CA_user and ca_User and you clear the Case
Sensitive Login Names check box, an internal application error "duplicate key
violates unique constraint" appears. For information about deleting users, see the
CA APM Configuration and Administration Guide.
Note: If you selected Ignore Applications in User Recognition when you set up your
domain (Setup > Domain), then case sensitivity is determined by the default
applications Case Sensitive Login Names option.


Session Timeout
Enter the business applications timeout length. Once the timeout has been
reached, CA CEM discards the session ID information. If this value is not set
correctly, per-user defects and statistics might not be accurate.
If the session timeout is shorter than the business application's session timeout, the
defects and statistics will be associated with the unspecified user.
If the session timeout is longer than the business applications session timeout, the
defects and statistics for multiple users might be attributed to one user. (Session
IDs can be reused.)
User Processing Type
E-Commerce or Enterprise:
For e-Commerce business applications, detailed per-transaction type statistics are
stored per hour and per transaction definition. This setting provides maximum
scalability for high volume e-Commerce business applications. Significant savings in
the disk storage usage are possible with this setting.
For enterprise business applications, detailed per-user statistics are stored per
hour, per transaction definition, and per user. Because the setting provides the
most detailed statistics about individual users, there is a significant increase in the
disk storage usage for business applications with high user counts. Select Enterprise
only if you have a compelling need for per-user statistics.
Character Encoding
Select the appropriate character encoding for your business application:
ISO-8859-1
The default character encoding for CA CEM; the HTTP and MIME text
default.
UTF-8
The standard for encoding Unicode on UNIX / Linux; the preferred
standard for multilingual web sites.
EUC-JP
Japanese character encoding for UNIX / Linux.
Shift-JIS
Japanese character encoding for Microsoft Windows.
ISO-2022-JP
Double-byte coded Kanji (Chinese characters used in Japanese writing).
Windows-31J
Microsoft Windows extension to Shift-JIS to accommodate NEC special
characters and IBM extensions.
About defining business application identifiers


GB2312
Character encoding for Chinese, simplified.
Big5
Character encoding for Chinese, traditional.
EUC-KR
Character encoding for Korean.
See Monitoring multibyte transactions (see page 185) for more information.
Now you are ready to create business application identifiers.
Troubleshooting case sensitivity for login names
Symptom:
The case sensitivity setting for recognizing login names does not work for the business
application.
For example, users are not appearing in their assigned groups. Or, case sensitivity is
being ignored when users are assigned to groups.
Solution:
Ensure one of the following:
That Ignore Applications in User Recognition (Setup > Domain) is not selected and that
Case Sensitive Login Names (Administration > Business Applications > business
application) is set correctly for the behavior you want.
Or
If Ignore Applications in User Recognition (Setup > Domain) is selected, then Case
Sensitive Login Names (Administration > Business Applications > Default Application) is
set correctly for the behavior you want for all your business applications.
For more information, see About the default application (see page 27).
About defining business application identifiers
Web applications have various ways of differentiating one interactive user session from
another. For example, session ID is often used to keep track of a specific user
performing one transaction, or set of transactionsfrom start to finish.
You need to define business application identifiers so CA CEM can determine which
particular user is executing a particular transaction. These identifiers are defined at the
business application level, which means that multiple business services can use the
same identifiers.
Defining session identifiers


You might also want to define business application identifiers to track users within
groups, based on the content of their transactions.
You can identify sessions, users, and user groups for a business application via:
Session identification defines the session identifiers used to define where a
session starts and stops.
User identification if you do not specify user identifiers, transactions are assigned
to the generic unspecified user. You must specify user identifiers to bind the user
identity (for example, login ID) to a particular session (for example, session ID).
Interim session identification in some cases, such as a two-phase login
authentication process, the user identification and session identification cannot be
found in the same HTTP component. Interim session identification parameters can
be defined to link the two HTTP components.
User group identification identifies and groups users (and their associated
statistics) by the content within the request they are making.
Web applications usually include a session ID for differentiating between interactive
user sessions. You configure CA CEM to specify which transaction parameter contains
the application session ID. CA CEM uses session identifiers for these functions:
Binding, or associating, transaction components into transactions
Binding transactions into business transactions
Identifying the user that executes a transaction or a business transaction
Session identifiers are defined at the business application level, which means that
multiple business services can use the same session identifiers.
The TIM recorder simplifies the definition process by automatically extracting
transaction signatures from live transactions passing through your network. You can
analyze these signatures to determine the transaction parameter that contains the
application session ID.
If you do not yet know the session identifier, you can come back to this step after you
define the transaction.


For information about determining transaction identification parameters, see Viewing
the recording session parameter map (see page 65).
To specify a business application session identifier:
1. Select Administration > Business Applications. Select the name of your business
application (for example, Siebel Call Center).
2. Select Session Identification. Click New Parameter Group.
The Session Identification Parameter page appears.

3. Define the session identifier by choosing a parameter Type.
4. Enter a parameter Name that contains the session ID.
5. To specify a wildcard in the parameter Name, see Wildcarding parameter names
(see page 119).
6. To specify a substring within a parameter, click the Advanced button.
Offset is the number of characters to skip before examining the substring. Use
a value of 0 to specify the entire string.
Length is the number of characters to include in the identifier. Use the value of
-1 to specify the entire string.
See Offset and Length examples (see page 42).
7. Click Save to save the session identification parameter. To define more parameters,
see the procedure below.
To specify additional session identification parameters:
1. Verify that you have created at least one session identification parameter (as
described in the procedure above).
2. Decide if you want the new parameter to be ANDed or ORed with the existing
parameters.
ANDed means that all identifiers must be present to identify the session.
ORed means that if any of the identifiers in the parameter group are present,
the session is identified.
Defining user identifiers


3. To create an ANDed parameter, click New and complete the fields.
4. To create an ORed parameter, click New Parameter Group and complete the fields.
Example session identifiers

Application Parameter Type Parameter Name
Siebel Cookie _sn
J2EE Cookie JSESSIONID
Avitek Financial (WebLogic
application)
Cookie JSESSIONID_
SAMPLEPORTAL
various Cookie ASPSESSIONID*
CA SiteMinder see note SiteMinder SessionId
Note: Consult the CA SiteMinder documentation before enabling the CA SiteMinder
plug-in. SessionId is accessible through a SiteMinder cookie, usually named SMSESSION.
To enable CA SiteMinder or to change the cookie name, go to Setup > Plug-ins and
select CA SiteMinder. See the CA APM Configuration and Administration Guide for more
information.
A combination of user identification parameters and session identification parameters
enables CA CEM to assign the correct user for each monitored transaction. Verify that
the session identifiers are clearly defined before specifying the user identifiers.
User identifiers are defined at the business application level, which means that multiple
business services can use the same user identifiers.
CA CEM identifies users of login transactions by their login name. Users of other
transactions are identified by session ID and the login name of the login transaction for
that session.
Important: If you do not specify user identifiers, transactions are assigned to the
unspecified user and you do not collect statistics on a per-user basis.
If you do not yet know the user identifier, you can come back to this step after you
define the transaction.


Note: After you define the User Identification parameter, for defects to be associated to
a user (instead of an unspecified user), do the following:
Define the Session Identification parameter.
Define a Login business transaction definition that contains the parameter defined
in User Identification parameter.
When users start their sessions by logging in, the login transaction picks up the user
name. Thereafter, any other transactions during the same session and the defects
they may produce can be linked by the Session Identification parameter to the user
name.
To specify a business application user identifier:
application (for example, Siebel Call Center).
2. Select User Identification. Click New Parameter Group.
The User Identification Parameter page appears.
3. Define the user identifier by choosing a parameter Type and entering the
parameter Name that contains the User Name. (Multiple parameters are allowed.)
4. If you want to examine a specific substring within a parameter, click the Advanced
button.
Offset is the number of characters to skip before examining the substring. Use
a value of 0 to specify the entire string.
Length is the number of characters to include in the user identifier. Use the
value of -1 to specify the entire string.
5. Click Save to save the user identification parameter. To define more parameters,
see the procedure below.
To specify additional user identification parameters:
1. Verify that you have created at least one user identification parameter (as
described in the procedure above).
2. Decide if you want the new parameter to be ANDed or ORed with the existing
parameters.
ANDed means that all identifiers must be present to identify the user.
ORed means that if any of the identifiers in the parameter group are present,
the user is identified.
Using the client IP address to identify users


3. To create an ANDed parameter, click New and complete the fields.
4. To create an ORed parameter, click New Parameter Group and complete the fields.
Example user identification parameters

Application Parameter Type Parameter Name
Siebel Post SWEUserName
J2EE Post j_username
Avitek Financial
(WebLogic application)
Post j_username
CA SiteMinder see
note
SiteMinder UserName
DistinguishedName
Note: Consult the CA SiteMinder documentation before enabling the CA SiteMinder
plug-in. To enable CA SiteMinder, go to Setup > Plug-ins and select CA SiteMinder. See
the CA APM Configuration and Administration Guide for more information.
Typically users are identified by login name, obtained by setting a user identification
parameter as described above in Defining user identifiers (see page 34).
However, the client IP address can be used instead of a login name.


If you choose to do this, the client IP address appears in the User and Login Name fields
throughout the business application; for example, in the User Groups > User Search
page and the Incident Management > Defect details page, as shown.

Using the client IP address to identify users is a good choice when:
You need to triage transaction performance based on network segments.
The identity of individual users is not important (although the users experience
from that client machine is important).
For example, the web application being monitored is a kiosk application. In most cases,
users do not log in. They perform some transactions but do not need to identify
themselves. If an incident occurs, you want to be able to identify the kiosk, not the user
who experienced the defect.
Using the client IP address to identify users lets you set correlational SLAs based on the
kiosk's IP address. For example, a 1-second transaction in the head-office lobby could be
flagged as unacceptable, but an 8-second transaction time in a kiosk at a shopping mall
on a different continent could be acceptable.
Important: If users are behind a proxy server, they are identified and grouped according
to IP address of their proxy servers and not of their client machines. If the request traffic
includes an HTTP header that contains the client IP address, you can configure CA CEM
so that the client IP address is reported. See the CA APM Configuration and
Administration Guide for how to identify users behind proxy servers.
Identify users by client IP address and user group by IP subnet or by user group by IP subnet alone?


To identify and display client IP address as the login name:
Important: Do not use this procedure for e-commerce or very large enterprise sites. The
number of users and user groups created can become unmanageable.
1. Follow the procedure described in Defining user identifiers (see page 34). When you
set the parameter, select Type URL and Name Client IP.

2. When you set up user groups for this business application, make sure that you
create the groups based on IP subnet (Setup > Domain). See the CA APM
Configuration and Administration Guide for information on automatically assigning
new users to subnet user groups.

Important: Do not set user group identification parameters because doing this can
cause the same user to appear in different groups.
Identify users by client IP address and user group by IP subnet
or by user group by IP subnet alone?
Even if you choose to create user groups based on IP subnet, there is a significant
difference between identifying users by user attributes or by client IP address.
If you identify users by parameters such as userid, the first time that users log in, they
are assigned to the group based on the IP subnet at that first log in. If users
subsequently log in from a different subnet, they are still associated with the user group
for the original subnet. If your users always log in from the same subnet, this is not an
issue. However, if your users are mobile, then their user groups do not reflect the
subnets that they actually log in from.
If you choose to identify users by client IP address and to create user groups based on IP
subnet, then data associated with a user group always originates from that IP subnet.
Defining interim session identifiers


This table gives an example of the difference between identifying by client IP address
and by another user attribute (for example, userid). In both cases, user groups are based
on the IP subnet.

Login details If login name is set by the
userid
If login name is the client IP
address
First login:
userid = DrJones
IP_address =
172.16.1.1
Login Name = DrJones
User Group =
Usergroup-172.16.1.0
Login Name = 172.16.1.1
User Group =
Second login:
userid = DrJones
IP_address =
192.168.9.1
Login Name = DrJones
User Group =
Login Name = 192.168.9.1
User Group =

Interim session identifiers are used in conjunction with session identifiers and user
identifiers. The interim session identifier provides the link between the two, in the cases
where an applications identifying information is found across two separate HTTP
components, rather than one HTTP component (for example, containing both login ID
and session ID).
Before you specify an interim session identifier:
Define the corresponding session identifier; see Defining session identifiers (see
page 32).
Define the corresponding user identifier; see Defining user identifiers (see page 34).
To specify an interim session identifier:
application (for example, Avitek Financial).
2. Select Interim Session Identification. Click New.
The Interim Session Identification Parameter page appears.


3. Define the interim session identifier by choosing a parameter Type:
Location Query
Specifies a query parameter in a response "Location:" header that should
match a query parameter in a subsequent request.
Location URL
Specifies a URL parameter in a response "Location:" header that should match
a URL parameter in a subsequent request.
4. Type the parameter Name that contains the interim session identifier.
5. If you need to specify a substring within a parameter, click the Advanced button.
Offset
The number of characters to skip before examining the substring. Use a value
of 0 to specify the entire string.
Length
The number of characters to include in the user identifier. Use the value of -1
to specify the entire string.
6. Click Save to save the interim session identification parameter. If you need to define
more parameters, repeat the steps.
Note: If you create multiple interim session identification parameters for a business
application, then they must all be present to match the interim session identifier. (That
is, the parameters are combined with a logical AND.)
Example interim session identification using Location Query
These identifiers:

Parameter Type Name
user identifier Query username
interim session
identifier
Location Query zzid
session identifier Cookie SESSIONID
Defining user group identifiers


would provide the link between the first HTTP component:
HTTP component 1 (sent to www.domain.com)
GET /login?username=ccook
302 Found
Location: http://signon.domain.com/newlogin?zzid=1122334455
and the second HTTP component:
HTTP component 2 (sent to signon.domain.com)
GET /newlogin?zzid=1122334455
200 OK
Set-Cookie: SESSIONID=8D935FB50727D770FB9E9E789CA4C1
with the interim session identifier Location Query of zzid providing the link.
Defining user group identifiers
User group identifiers are similar to the user and session identification parameters, and
are used to determine the user group. You can identify a user group via any parameter
type.
User groups provide the convenience of configuring settings for a collection of users
instead of having to configure the settings for each individual user separately. User
groups can be defined so that you can easily identify user populations that are
experiencing problems.
Note: A user group identification parameter takes precedence over automatic user
group classification by client IP address, on the Setup > Domain page (Create User
Groups by IP Subnet).
If you create multiple user group identification parameters for a business application,
then they must all be present to identify a users group. (That is, the parameters are
combined with a logical AND.)
For more information, see the CA APM Configuration and Administration Guide.
Offset and Length examples


Offset and Length examples
Here are some examples of how the Offset and Length fields can be used to match a
substring in a parameter.

Offset Length Text matched in string: XYuser123
0 -1 XYuser123
2 -1 user123
2 4 user
Note: Offset and length with the URL Path parameter: Before using offset and length for
a URL Path parameter, consider if the Path parameter better suits your needs. See Using
path parameters to identify sessions (see page 44).
Note: Offset with multibyte characters: Character encoding for multi-lingual text can
take a variable number of bytes due to character serialization. Remember that the
offset is in characters, not bytes. See Monitoring multibyte transactions (see page 185).
Using XML to identify sessions, users, and user groups
You can use the power of XML to identify sessions, users, and user groups via business
application identification parameters. To do this, you first need to record a transaction
with the XML elements and attributes that you want. Then you can use the required
XML elements or attributes, found in the request body, to identify the users or sessions.
To identify users and sessions via XML:
1. Record an example XML-based transaction that contains the elements and
attributes you need. See Recording transaction signatures (see page 49).
Note: You must create a recording session with the XML elements; you cannot
define XML parameters manually.
application (for example, Avitek).
3. Select the appropriate identification link:
User
Session
User Group
4. Click New to create a new identification parameter for the business application.
The identification parameter page appears.
Using XML to identify sessions, users, and user groups


5. Select the Type XML.
A Recording Session list appears.
6. Select the appropriate recording session from the list.
A Recording Transaction list appears.
7. Select the appropriate recording transaction from the list.
The XML request body appears.
8. Review the request body to find the identifying information you need.

9. Click on the element or attribute to identify the user or session for this application.
10. Click Save to save the new parameter. If you need to define more parameters,
repeat the steps.
Defining identifiers for NTLM authentication


Defining identifiers for NTLM authentication
If you have defined a business application that uses NTLM authentication, you need to
take some additional steps to verify that monitoring works correctly.
To set up NTLM authentication:
1. Verify that the authentication type for the business application is NTLM
Authentication. See Defining a business application (see page 28).
2. When you set the transaction definition, verify that the Set NTLM Authentication
parameter is set to match any user name. See Editing transaction components (see
page 116).

This prevents 401 errors from being reported as defects. Because the server
responds with a 401 error to the clients initial challenge, each NTLM authentication
is associated with a 401 error.
3. To prevent users from being assigned as unspecified users, add a session
identification parameter to the business application. Set the Type to URL and the
Name to Port. See Defining business application identifiers (see page 31).

Using path parameters to identify sessions
Path parameters are primarily used to identify sessions. However, path parameters can
also be used to identify users, user groups, and transactions.
Important: If you are matching a URL path that includes path parameters, make sure to
terminate the URL path pattern with a wildcard as described in Editing transaction
components (see page 116).

Path parameters are identified by scanning the URL path for delimiters. When the first
delimiter is found, the string between the delimiters or the delimiter and the end of the
URL path (often terminated with a question mark) determines the path parameter.
Path parameter names and values are case-sensitive.
Using path parameters to identify sessions


These examples illustrate the use of the path parameter. In the examples, the delimiter
is the semicolon (;).
Example 1: One path parameter identified
http://myhost/browse.do;jsessionid=4DB7?chan=contact.main
These parameters can be identified:

Type Name Value
URL Path /browse.do;jsessionid=4DB7
Path jsessionid 4DB7
Query chan contact.main
If this component is identified as the main component of a transaction whose
application defines a single session ID parameter with type Path and name "jsessionid",
then CA CEM reports "4DB7" as the session ID.
Example 2: Multiple path parameters identified
http://myhost/browse.do;jsessionid=4DB7;groupid=sales

Type Name Value
URL Path /browse.do;jsessionid=4DB7;groupid=sales
Path jsessionid 4DB7
Path groupid sales
Example 3: Path parameter with an empty string
http://myhost/browse.do;userid?chan=contact.main

Type Name Value
URL Path /browse.do;userid
Path userid empty string

Setting the global delimiter for path parameters


Setting the global delimiter for path parameters
To use path parameters, you need to set the delimiter that determines the start and end
of the path parameter. This delimiter is global, that is, it applies to the default
application and all other business applications you define in CA CEM.
To set the global delimiter for path parameters:
1. Select Setup > Domain.
2. Specify a delimiter in the Path Parameter Delimiters.
The semicolon is the most likely choice of delimiter. Alphanumeric characters are
forbidden. Question marks and equals sign are not forbidden but are not sensible
choices. For information about specifying more than one delimiter, see More than
one kind of delimiter, below.
3. Click Save.
More than one kind of delimiter
You can specify more than one delimiter in the Path Parameter Delimiters field.
For example, you have two business applications. In one business application you want
to use a semicolon as the delimiter, and in the another business application you want to
use a colon as the delimiter. You can specify both in the Path Parameter Delimiters field.

The first matching delimiter is used, and others are ignored.
Example: Delimiter characters colon and semicolon specified
http://myhost/browse.do;jsessionid=4DB:7?chan=contact.main

Type Name Value
URL Path /browse.do;jsessionid=4DB:7
Path jsessionid 4DB:7

Defining business services


Transactions are stored in collections named business services. For example, within a
call center business service you can have transactions such as login, add a contact,
update an account, and others.
First create a business service. Then define transactions. Each business service must be
associated with a business application, but there can be multiple business services that
are associated with one business application (for example, Siebel).
Follow these steps:
1. Select Administration and then Business Services.
2. Click New to create a business service.
3. Enter a Name and Description for the business service. The business service name is
case-sensitive.
Do not use these characters in your business service names:
> < : % |
4. Select the Business Application that you created in Defining a business application
(see page 28).
5. Select the Impact Level, which determines the business priority of transaction
defects that are associated with this business service. (In most cases, the default
value of medium is sufficient.)
The default is to inherit the impact level from the domain. If you want to change
from the domain priority, clear the check box and select the appropriate impact
level from the list.
Note: To change the domain default values, go to Setup > Domain. See the CA APM
Configuration and Administration Guide for more information.


6. Complete the Service Level Agreement (SLA) values that define the SLA at the
business service level. To change a value, clear the check box and select a new value
from the list.
The default is to inherit the SLA values from the domain.
Note: These values are also used to define default SLA values that can be inherited
by the transactions within the business service.
Success Rate SLA
Success Rate Service Level Agreement as a percentage. The default is 95
percent defect-free transactions.
Sigma SLA
Sigma Service Level Agreement as a number. The Sigma score is a measure that
is calculated from defects per million opportunities (DPMO). The default is
4.00, where near-perfection is 6.00 and perfection (zero transaction defects) is
infinity.
Transaction Time SLA
Transaction Time Service Level Agreement in seconds. The default is 8 seconds
total elapsed time.
7. Click Save to save your new business service.
The new business service displays in the Business Service list.


Chapter 3: Recording transaction
signatures

When you are ready to record transaction signatures on your network, follow the
procedures in this chapter.
CA CEM recording sessions provide a way for you to collect transaction signatures using
user activity as it passes through your network.
Once you collect a transaction signature, you can use it as a template to generate
transaction definitions. You then edit the resulting transaction definitionsto make
them generalizedfor use in monitoring activity for all users.
After you define a request-based transaction, you can define a response-based
transaction that is based on that request-based transaction.
Transaction signatures help simplify the process of session identification, user
identification, and transaction identification. CA CEM uses the identification parameters
that you define to identify and monitor transactions.
The first step in a CA CEM recording session is to select a client computer that can
generate user activity.
CA CEM recorder types (see page 50)
Turning off web page caching (see page 50)
Setting up for recording with a proxy server (see page 51)
Using the TIM recorder (see page 53)
Using the script recorder (see page 61)
Viewing recording sessions (see page 63)
Editing recording sessions (see page 67)
Troubleshooting transaction recording (see page 68)
CA CEM recorder types


CA CEM recorder types
This section describes recording transaction signatures using these methods:
The TIM recorder can be run from any client computer that can access the CEM
console. However, CA Technologies recommends that you run it on the same client
computer where you are performing live transactions. The TIM recorder can record
transaction signatures from user activity originating from any client computer
capable of performing the user activity. The TIM recorder operates in the
background and does not display a recorder toolbar on your client computer.
The script recorder enables you to use prerecorded network packet capture files
and HP LoadRunner VuGen quality assurance test script output files to create
transaction signatures. You can download the script recorder from the CEM console
by clicking the Tools link.
Two more methods for recording are described in other chapters:
Automatic transaction discovery (see page 91) replaces the need for formal
recording by capturing real transactions.
The agent recorder (see page 69)
Turning off web page caching
For the best recording results, turn off web page caching on your client computer. This
changes need to be made on the client computer that you are planning to record
transactions from.
When you view a web page, the page components can be displayed from the web site
directly, or to speed up the results, page components can be displayed from local cache
on your client computer. Web page caching can result in faster response times if you
have already viewed a page previously.
During a recording, you should turn off web page caching so that data will be recorded
as it is retrieved from the data center rather than from your client computers cache
memory.
Note: These changes need to be made on the recording-target client computer, which
you are using for recording transactions (not the administrators client computer, unless
it happens to be the same one).
To turn off web page caching in Internet Explorer:
(You might follow a different procedure, according to the version your browser.)
1. Go to Tools > Internet Options.
2. On the General tab, Browsing history section, select the Settings button.
Setting up for recording with a proxy server


3. Under Check for newer versions of stored pages, select Every time I visit the web
page.
4. Click OK to save your changes.
5. Click OK to close the dialog.
Tip: Remember to turn caching on when recording is finished.
The TIM monitors transactions during:
transaction signature recording
transaction inspection (verification)
transaction tracing (debug)
transaction definition monitoring
Each of these scenarios requires the ability to distinguish transaction traffic for an
individual client computerwhether or not a proxy server is in the path.
Unless the CA CEM administrator recognizes and identifies a proxy server, transaction
signature recordings, inspection, and tracing scenarios can be hindered. That is, the TIM
might not be able to distinguish between transactions from multiple client computers.
(Transaction definition monitoring does not use or need this proxy server configuration.)
To find transactions originating from a specific client computer, as opposed to other
client computers' transactions going through the same proxy server, CA CEM uses the
web browser's language preference to uniquely identify transactions. The language
preference is used because it is the only web browser control that directly affects the
transaction traffic.
If you want to set the web browser language for all recordings on a particular computer,
see Monitoring traffic behind a proxy server (see page 52). You also need to set the web
browser language pattern for each recording session, see Starting a recording.
The inspection and tracing features are used mainly by CA Support and field personnel
for verification and debugging purposes. CA Technologies systems engineers can use the
language preference as a filter to isolate transactions in a proxy environment.


Monitoring traffic behind a proxy server
If the client computer you intend to use for recording transactions is behind a proxy
server, you can adjust your web browser language preference to allow the TIM recorder
to recognize your transaction traffic, as opposed to traffic from all other users traffic
going through the same proxy server.
You also need to set the browser language pattern for each recording session, see
Starting a recording.
To change the web browser language:
1. In Internet Explorer, go to Tools > Internet Options.
2. On the General tab, select the Languages button.
An existing language preference appears, for example:
English (United States) [en-us]
3. Click the Add button to add another language to your list of web browser
languages.
4. Select a unique language that will not otherwise appear on the network (for
example Afrikaans, or type a user-defined language, for example, wcem) and click
OK.
The order is important. To match the default pattern (en-US,af*), English (United
States) must be above Afrikaans.

Using the TIM recorder


Deactivate traffic monitoring on your client computer
Once you have finished recording, deactivate the traffic monitoring. Otherwise,
transactions from this client computer might be recorded later by mistake.
To remove the language preference:
1. In Internet Explorer, go to Tools > Internet Options.
2. On the General tab, select the Languages button.
The original language and Afrikaans (or other unique language selected in step 4
above) are listed.
3. Select Afrikaans and click the Remove button to remove the preference and
deactivate traffic monitoring.
The TIM recorder has been designed to help you capture one transaction, review it,
then move on to the next transaction. Recording allows you to analyze transactions
individually, rather than having to remember the exact sequence of clicks you took
during a lengthy recording session.
Tip: For the purposes of the TIM recorder, think of a transaction in terms of a web
browser clickfor example, a click to log in, or a click to buy a product.
For example, you would start recording, perform one action, and stop recording, and
then repeat the process for each action (transaction). If you perform multiple actions in
a single recording session, most of the transactions are non-identifying and therefore
not useful for monitoring.
As you use the TIM recorder, be sure to capture transactions that:
You really want to monitorif you monitor too much, you sort through a sea of
data later.
Are named appropriatelyif they are not named well, you might not realize what
the transactions are really doing, and therefore what it means to your business.
Are truly the transactions that you needif they are not the identifying
transactions you need, then your reports show too much or too little activity; the
activity is not an accurate reflection of the actual user transactions.


About content-types for recording sessions
The content-type is used to determine whether a transaction is recognized in a
recording session. If the transaction content-type matches with a type in the Selected
list, then the transaction is recognized. Otherwise, the transaction is recorded but not
considered as recognized.
For example, a recording session with the content-type as text/html records multiple
transactions, such as:
GET/Start.jsp HTTP/1.1
HTTP/1.1 200 OK

POST/MedRecWebServices HTTP/1.1
HTTP/1.1 200 OK
Content-Type: text/xml
After completion of a recording session, you can view the transaction with the content
type text/html as a recognized transaction. The transaction with the content-type
text/xml is considered as an unrecognized transaction.
Note: Response tag parameters are not in a recording.
To record Flex-based transactions, specify the content-type to application/xml or
application/x-amf.
About unrecognized transaction components
The content component recorded is considered as an unrecognized component when
the Parent URL (Referer) for the content-type is null or is not matching with the
recognized transaction's URL.
For example:
GET /Start.jsp HTTP/1.1
HTTP/1.1 200 OK

GET /my.jsp HTTP/1.1
HTTP/1.1 200 OK
Content-Type: text/xml
Referer: Null


In this scenario the content-type used is text/html to determine the content
component. The Start.jsp is a recognized transactions parent URL. The my.jsp
becomes an unrecognized component because the Parent URL (referer) value is Null.
You can move an unrecognized component (my.jsp) from the Components page and
turn it into a recognized transaction to monitor it after promotion.

More information
Viewing the recording session transactions (see page 64)
Viewing the recording session transaction components (see page 67)

Enabling transaction recording
To enable transaction recording on your network:
1. Select Setup > Monitors.
2. Make sure that the TIM is enabled. If not, select the check box and click Enable.
Starting a Recording
Now, you are ready to begin the recording session.
Note: Record when traffic is low or, on a test lab environment. Use the test lab to
record and then export the transactions to your production environment.
CA CEM stops recording under heavy load conditions. The TIM recorder slows down
when the TIM runs under load because the TIM processes defects, logins, and statistics
before providing recording data.
Follow these steps:
1. Select Administration > Recording Sessions.
2. Click New to go to the recorder page.
Note: If you cannot see the Recording Sessions tab, verify that you have write
access to at least one business service. (See Viewing access policies for business
services (see page 130).)
3. Set the Monitor Type to TIMs.
Note: You must have at least one TIM Agent installed in your environment to
monitor targeted application traffic.


4. Enter a name for the recording.
Give the recording a meaningful name that helps you to identify the transaction
recording later.
Tip: You can make an image capture for each transaction to help a business user
understand the recordings later. For example, capture the web page for the
transaction, then paste the image into a document. To cross-reference recordings
to transactions, type the name of each recording under each captured image.
5. Set the recording conditions:
a. Client IP Address the client computer where the transactions are recorded
from. The system automatically fills in the web browser address of the client
computer currently connected to the CEM console.
Note: The IP address must be the recording-target client computer, which you
are using for recording transactions (not the administrators client computer,
unless it happens to be the same one).
If you are using a proxy server and change this address to the web server
address of the proxy server, you record all transactions coming through the
proxy server. To record from only one computer, leave this field blank and set a
unique browser language instead. See Setting up for recording with a proxy
server (see page 51) for more information.

Tip: The Client IP Address and Browser Language Pattern are ORd together. It
records when a transaction matches at least one of them, when both fields are
non-empty. This is true whether behind a proxy server or not. To record
transactions based ONLY on the Browser Language Pattern, enter 0.0.0.0 in the
Client IP Address field and define the Browser Language Pattern accordingly.
0.0.0.0 is the wildcard IP address, which passes all filters to the wrong IP
addresses so that no network device can use it. CA APM then has no choice but
to use the Browser Language Pattern setting.
b. Browser Language Pattern Select this check box, if the client computer you
intend to use for recording transactions is behind a proxy server. You can adjust
your web browser language preference to allow the TIM recorder to recognize
your transaction traffic, as opposed to traffic from all other users traffic going
through the same proxy server.
By default, the Browser Language Pattern is set to English (United States) and
Afrikaans (en-us, af*), which means the TIM recorder is monitoring any
network traffic that matches this web browser language setting. You can leave
this setting as is, or you can change it to your own, user-defined setting.


For example, you can set your own Browser Language Pattern to: en-us, wcem;
another CA CEM administrator can set this to: en-us, wtest. This way, you can
both go through the same proxy server and the TIM recorder can distinguish
one recorded transaction from the other. See Monitoring traffic behind a proxy
server (see page 52).
c. Select the appropriate Default Character Encoding for your recording:

ISO-8859-1
default.
UTF-8
EUC-JP
Shift-JIS
ISO-2022-JP
Windows-31J
GB2312


Big5
EUC-KR
d. Enter a content-type in the Add Content-Type to Selected list and click Add.
A content type is added and saved in the Selected list only.
Note: You can also select the content-types from the Available list and move
them to the Selected list for your recording.
The default Available and Selected list of content-types is displayed in the New
Recording Session, and the Edit Recording Session pages.
The content -types are defined in the tess-default.properties file. The following
properties are used to determine the content-types:
The recorder.mainComponentTrustedContentType property is used to
determine the Selected content types. For example:
Selected Listrecorder.mainComponentTrustedContentTypes=text/html
text/plain text/xml application/x-java-serialized-object application/xml
application/x-amf
The recorder.mainComponentAvailableTypes property is used to determine
the Available content types. To add any new content-type to the 'Available'
list, edit this property. For example:
Available Listrecorder.mainComponentAvailableContentTypes=text/html
text/plain text/xml application/x-java-serialized-object application/xml
application/x-amf application/x-www-form-urlencoded application/pdf
Note: If you add a content type in the
recorder.mainComponentAvailableContentTypes property, then only it can be
part of the Selected list. The Selected content types are the subset of Available
content types defined in the tess-default.properties file. See About
content-types for recording sessions (see page 54) for more information.
6. Click Record to start recording the session.
The Recording Status indicates the recording is in process.


7. Perform the transaction that you want to record on the client computer. For
example, log in to your account.
The recorder page lists the transactions recorded. For identifying transactions,
response parameters are also listed.
Name
An interim transaction name, which you can modify later
Content type
From the HTML header; text/html, text/xml, image, css, script, and so on.
HTTP Status Code
200=OK; 300=redirect; 400=client; 500=server
Method
GET, POST
URL
Shows all the URLs that you go through as your transaction progresses
Tip: If you do not see any transaction activity on the page, verify that the TIM is able
to monitor your client computer activity; you can have to work on a different client
computer, depending on your network configuration.
8. Click Stop when you are finished recording your transaction.
The Recording Status indicates that the recording has been stopped. All your
transactions appear in the list.
If a recorded component matches an existing, identifying component of the
identifying transaction of an enabled business transaction, CA CEM displays this
information in the Matches Enabled Business Transaction column. This column
displays this information only for the identifying transaction in a recording page.
You can review and modify the transactions immediately, when you can remember
exactly what you did, and in what order.
9. Change the transactions as needed.
a. Click the Update button to:
Rename the transaction, if required.
Change whether a transaction must be included.
Change whether a transaction is cacheable.
Change the identifying transaction from one to another.
Note: There can be only one identifying transaction.


b. Select a check box to the left of a transaction and use the Delete button to:
Delete a non-essential transaction that you recorded.
Delete a non-identifying transaction that appears before an identifying
one.
Note: The identifying transaction must be the first in the list. For example, a
redirect appears as the first transaction.
10. If you want to record another transaction, click Record Next Transaction and repeat
the steps. For example, after the login, you can record a buy transaction.
Continue to record, stop, and analyze until you have recorded all the transactions
that you need.
11. Click Finished Recording when there are no more transactions to record.
The page refreshes with the transaction signature from the recording, with the
identifying transactions appearing. See Viewing recording sessions (see page 63) or
Editing recording sessions (see page 67) for more information.
For more information, see Defining transactions (see page 109).
Stopping a TIM recorder session
You must manually stop TIM recorder sessions after you have collected data from your
client computer.
To stop a TIM recorder session:
2. Select the check box for the recording session.
3. Click Stop. The TIM recorder stops recording transactions.
4. If you want to change the name of a recorded transaction, click the name, then click
on the General link.
5. Change the name to a meaningful name of your choice, then click Save.
See Editing recording sessions (see page 67) for more information on modifying
transactions.
Using the script recorder


The script recorder enables you to generate transaction signatures from network packet
capture files or VUGen quality assurance test script output files. The output of the script
recorder is a recording session.
The script recorder can generate transaction recording files from these input formats:
VUGen trace files (VUGen files)
libpcap packet capture files (pcap files)
The recording session can be viewed from the Administrator > Recording Sessions page.
Installing the script recorder
To install the script recorder:
1. Select Tools > Script Recorder.
2. Click Install Script Recorder.
3. Click Run to install the script recorder or Save to save the executable to your hard
disk (and then run the script recorder installer from your hard disk).
Input script file types
If you have HP LoadRunner software, you generate VuGen trace files to use with the
script recorder.
If you have the tcpdump, ethereal, or tethereal tools, you can use libpcap packet
capture files to generate input for the script recorder. Any protocol analyzer that can
produce output in libpcap format can be used to create an input file for the script
recorder.
VuGen trace files
HP LoadRunner software can generate synthetic transactions. HP LoadRunner comes
with a Virtual User Generator called VuGen. You can use VuGen in a verbose mode
which generates a detailed VuGen trace file.
Tip: To create a verbose VuGen trace file in LoadRunner 8, choose the run-time settings
for the log as follows:
Always send messages
Extended log and Advanced trace


VuGen trace files (output.txt) usually start like this:
Virtual User Script started
Starting action vuser_init.
Web Turbo Replay of LoadRunner 8.1.0 for WINXP; WebReplay81 build 5495 [MsgId:
MMSG-27143]
Run-Time Settings file:
"M:\TRX_2008\Scripts\Query\TRX_Query_1_UPDATED_05072008\\default.cfg" [MsgId:
MMSG-27141]
Vuser directory: "M:\TRX_2008\Scripts\Query\TRX_Query_1_UPDATED_05072008"
[MsgId: MMSG-27052]
Vuser output directory: "M:\TRX_2008\Scripts\Query\TRX_Query_1_UPDATED_05072008"
[MsgId: MMSG-27050]
Operating system's current working directory:
"M:\TRX_2008\Scripts\Query\TRX_Query_1_UPDATED_05072008" [MsgId:
MMSG-27048]
UTC (GMT) start date/time : 2008-06-12 20:23:49 [MsgId: MMSG-26000]
LOCAL start date/time : 2008-06-12 16:23:49 [MsgId: MMSG-26000]
Local daylight-Savings-Time: Yes [MsgId: MMSG-26000]
Some of the Run-Time Settings: [MsgId: MMSG-27142]
Use the VuGen trace file as input to the script recorder.
Pcap files
Pcap files are packet capture files in libpcap format. The libpcap format provides a
system-independent interface for user-level packet capture and a portable framework
for low-level network monitoring.
Pcap files are usually captured using one of these tools:
tcpdump a TCP/IP protocol analyzer that captures and analyzes TCP packets.
ethereal a protocol analyzer that has an open source license and is able to
capture and analyze a variety of network protocols.
tethereal a command line version of ethereal.
Note: The script recorder only handles pcap files with clear text HTTP traffic. It does not
support HTTPS and does not handle pcap files with missing or out-of-order packets.
Viewing recording sessions


Command line instructions
The script recorder runs from a command prompt. It takes input from a script file that
you specify and produces a file that can be read by CA CEM.
To run the script recorder from the command line:
1. Select Windows Start > Run.
2. Type cmd and click OK.
3. Navigate to the c:\wily\cem\scriptrecorder\bin directory:
c:
cd \wily\cem\scriptrecorder\bin
4. Type scriptrecorder to see help for the tool.
5. Specify the script file name to run and the server to run the script on.
6. Type the input file name and client computer to run the script on in this format:
scriptrecorder -file [set the File Name variable] -server <IP_Address>:CA Portal
where [set the File Name variable] is the name of a VUGen trace file or a pcap file,
<IP_Address> is the IP address of the MOM or the collector running the TIM
collection services , and CA Portal is the port number
(8081 is the default port number).
Examples:
c:
cd \wily\cem\scriptrecorder\bin
scriptrecorder -file example-vugen-trace-file.txt -server 192.168.1.50:8081
scriptrecorder -file example-pcap-file.pcap -server 192.168.1.50:8081
To view the recording sessions:
Note: If you cannot see the Recording Sessions tab, ensure that you have write
2. Your recording sessions appear at the top of the list. Click the name of a recording
session to view the contents.


Viewing the recording session transactions
The recording session Transaction page shows, by default, the identifying transactions
that match enabled business transactions. You can do several things from this point:
Restart recording, which adds more transactions to this session.
Delete any transaction in the list.
Promote any transaction in the list, that is, associate the transaction definition with
an existing production business service.
Modify the page display to show all transactions, rather than only showing the
identifying transactions.
Move any transaction as a component of an existing recognized transaction.
Note: The URL for a transaction must match with the Parent URL for the recognized
transaction.
Turn an unrecognized transaction into a recognized transaction to monitor it after
promotion.
Note: You can move an unrecognized transaction to the recognized transaction list,
only if it has a successful HTTP status code (that is 2xx).

Note: Moving an unrecognized transaction can cause unexpected results after you
promote it.
See Defining transactions (see page 109) for more information about promoting
transaction signatures to transaction definitions.


Viewing the recording session parameter map
The recording session parameter map is useful for determining transaction identification
parameters: session-id, login-name and transaction identification. For each transaction
parameter in a recording session, the parameter map shows:
Transaction CountThe number of times the parameter appears in the recording.
Distinct Value CountThe number of distinct values the parameter contains during
the recording.
The Transaction Count and Distinct Value Count for parameters are helpful in the
transaction identification process.

Parameter Type Transaction Count Distinct Value Count
Login-name Low Low
Session-id High Low
Identifying High High
Tip: When you are looking for ways to identify your transactions, its a good idea to start
with parameters with high counts.


To view the recording session parameter map:
2. Select a recording session, and click the Parameter Map link.

Editing recording sessions


Viewing the recording session transaction components
You can view the recognized and unrecognized transaction components in a recording
session. Turn an unrecognized transaction component into a recognized transaction
component to monitor it after promotion.
To view and move transaction components:
1. Select Administration > Recording Sessions > Transaction > Components.
The Transaction Components page opens.

2. Select a component and click Move to Recognized Transaction list.
Note: The URL for the components must match with the Parent URL for the
transaction. You can move components with the successful HTTP status code (that
is 2xx).
The component is moved as a recognized transaction with all sub components
having the same parent URL.

Once you have created a recording session, you can edit the name and other aspects of
the recording.
To edit recording sessions:
2. Click on the name of your recording session, which is usually located at or near the
top of the list.
3. Select the General link if you want to change the name of the recording session or
the client IP address, which defaults to the client computer the recording was run
from.
4. Click Save to save your changes.
Troubleshooting transaction recording


5. If you want to change the names of any of the transactions in the recording or add
comments, click the Transactions link and click on the name of the transaction.
The General link appears. Change the name or add comments on this page.
7. (Optional.) Turn on caching. See Turning off web page caching (see page 50).
Troubleshooting transaction recording
Symptom:
I am recording transactions but I do not see any results.
Solution:
Be sure that you have cleared the browser cache. If a page is in your cache and it has
not been modified, you do not see the response body issued by the server.
Symptom:
I am trying to record a transaction that contains an HTML response tag, but I do not see
any results.
Solution:
Response tag parameters are not recorded. However, you can use transaction discovery
to discover transactions based on response tags, if you define and enable an
appropriate template.
Symptom:
I am trying to record a transaction that contains Flex data, but I do not see any results.
Solution:
Verify that the content-type is set to application/xml or application/x-amf.


Chapter 4: Introscope agent recording

About recording with the Introscope agent (see page 69)
About upgrading to CA APM 9.x (see page 70)
Process for recording transactions (see page 70)
Enable agent recording (see page 71)
Setting up a business application (see page 73)
Setting up a business service (see page 74)
Setting up an agent filter (see page 75)
Recording a business transaction (see page 76)
Starting an agent recording session (see page 79)
Agent recording and proxy servers (see page 82)
Viewing recording sessions (see page 85)
Editing recording sessions (see page 87)
Promoting transactions to definitions (see page 88)
About recording with the Introscope agent
In Introscope 9.x, you can now record information about business transactions using the
agents and the CEM console. Introscope 9.x agents record and monitor transactions,
giving you more information about what your application is doing. For example, you can
record business transactions in your Purchasing application with the agent, and then
monitor these business transactions in the Introscope Workstation. The information
from the agent pinpoints where the Purchasing application is encountering issues,
allowing you to understand and report the transactions effect on the business.
Information recorded by the agents is sent to the application triage map to display the
activity of your application in a graphical format. This format gives you the ability to see
how the business transactions flow across your logical application structure.
Note: Agents cannot recognize transactions based on response parameters. Agents also
do not recognize Flex data in transactions.
For more information about the application triage map and viewing information in the
map, see the CA APM Workstation User Guide.
About upgrading to CA APM 9.x


About upgrading to CA APM 9.x
When problems with your online applications occur, IT has the tool they need CA
Introscope to monitor, detect, triage and pinpoint the cause in your application or
backend infrastructure. However, they may not know which problem to address first,
understand the impact on service quality to end users of their actions, or know how to
prioritize problem resolution based on revenue impact or other business requirements.
By upgrading to the complete CA Application Performance Management (APM) solution
by adding CA Customer Experience Manager to CA Introscope, IT can expand their view
of business transactions from the time the end user presses "enter" on the keyboard
until a response is delivered back to the end user, enabling IT to share real-time
end-user experience information with business managers. With this shared information,
IT and business owners can align IT activities with business priorities to serve end-users
better and meet business objectives.
The complete CA APM solution provides the information that both business owners and
IT need to manage the performance of online business services. By providing real-time
information about each end users online experience, the complete CA APM solution
helps IT find and resolve problems not seen by CA Introscope alone and provides
business context for IT problem resolution. With this solution, IT knows which problem
to fix first based on criteria important to the business, such as impact on revenue or key
customers. Customized and context-specific real-time displays provide the same
information at the same time to business owners, executives, and IT so everyone in your
enterprise can see how the online business is running. Displays use transaction metrics
as a common language that can be shared across the enterprise to manage
business-critical online services and meet the challenge of delivering the best possible
online experience for each end user.
For more information about upgrading to the CA Application Performance Management
solution, contact your CA Technologies representative, or see the CA APM Installation
and Upgrade Guide.
Process for recording transactions
Following is an overview of the tasks involved in recording transaction signatures using
the agent.
Follow these steps:
1. Enable agent recording (see page 71).
Note: Agent recording is not supported on agents prior to 9.0.
2. Set up a business application (see page 73). This step is optional.
3. Set up a business service (see page 74).
4. Set up agent filters (see page 75). While this step is optional, CA Technologies
recommends setting up a filter as a best practice.
Enable agent recording


5. Record transactions (see page 76).
6. Promote transactions to definitions (see page 88).
7. Synchronize monitors to send all definitions to your agents. (see page 88)
8. View transactions in the Introscope Workstation Investigator. See the CA APM
Workstation User Guide.
Agent recording sessions provide a way for you to collect business transaction
signatures using user activity as it passes through your network.
Once you collect a business transaction signature, you can use it as a template to
generate business transaction definitions. You then edit the resulting business
transaction definitionsto make them generalizedfor use in monitoring activity for all
users.
Business transaction signatures help simplify the process of business transaction
identification. Agents use the identification parameters you define to identify and
monitor transactions.
To use agent recording, you must first have the following present in your environment:
an Introscope Enterprise Manager or a MOM.
an Introscope 9.x or later agent configured to report data to the Enterprise
Manager.
Note: Agent recording is not supported on agents prior to 9.0.
an application being monitored by an agent reporting data to the Enterprise
Manager or MOM.
To enable agent recording, you will:
1. Enable agent recording in the IntroscopeAgent.profile (see page 72).
2. Turn off web page caching (see page 72).
3. Access the CEM console (see page 73).


Enabling agent recording in the agent profile
To record business transaction information using an agent, you must first enable
recording for the agent. You will add file names to a property in the
IntroscopeAgent.profile.
To enable agent recording:
1. Open the IntroscopeAgent.profile in a text editor.
2. Add bizrecording.pbd to the list of ProbeBuilder Directive files listed in the
introscope.autoprobe.directivesFiles property. For example:
introscope.autoprobe.directivesFile=default-typical.pbl,hotdeploy,bizrecordin
g.pbd
3. Save the IntroscopeAgent.profile.
Important: For agent recording to function correctly, the time on the agent and the
Enterprise Manager it reports to must be synchronized.
Turning off web page caching
When you view a web page, the page components can be displayed from the web site
directly, or to speed up the results, page components can be displayed from local cache
on your client computer. Web page caching can result in faster response times if you
have already viewed a page previously.
During a recording, you should turn off web page caching so that data will be recorded
as it is retrieved from the data center rather than from your client computers cache
memory.
To turn off web page caching in Internet Explorer:
1. Go to Tools > Internet Options.
2. On the General tab, Browsing history section, select the Settings button.
3. Under Check for newer versions of stored pages, select Every time I visit the web
page.
Tip: Remember to turn caching on when recording is finished.
Setting up a business application


Accessing the CEM console
The CEM console is the main user interface (UI) of CA CEM. Administrators use it to set
up and configure CA CEM, including business transaction recording using an agent or the
TIM, and creating business transaction definitions. You use the CA CEM console to
record transactions using the agent.
If you are using Introscope 9.0 only, with no CA CEM installation present, much of the
CEM console is unavailable for use. If you upgrade to CA APM 9.x, you have access to all
CA CEM functionality.
Note: Unless otherwise indicated, this chapter assumes you are using the CEM console
as an Introscope-only user.
To access the CEM console:
Important: The recording functionality is supported by Internet Explorer only. You must
turn off caching for agent recording to function correctly. See Turning off web page
caching (see page 72).
1. Open an Internet Explorer web browser and type the address:
http://<IP_Address>:8081/wily
where <IP_Address> is the address of the MOM or a standalone Enterprise
Manager. For example:
http://192.168.1.54:8081/wily/cem/admin
2. Enter the user name and password.
The default user name for the CA CEM administrator is cemadmin.
The CEM console displays.
Setting up a business application
A business application contains information about the application you are monitoring,
as well as the business services and recorded transactions for each application. When
setting up a business application, you should describe basic characteristics of the
application, which allow for ease of identification later.
Setting up a business application is an optional step in the agent recording process. You
can use the default application provided, or no business application. However, if you are
specifying character encoding, you may want to set up a specific business application as
a container for this specific encoding.
For more information about setting up a business application, see Defining business
applications and services (see page 31).
Setting up a business service


Known issue
When selecting the Case Sensitive URL Path check box while setting up your business
application, some versions of JBoss and Tomcat might save header keys as lower case
values which makes the caseSensitiveName attribute not work properly for
HEADER_TYPEs.
Setting up a business service
Business services are groups of business transactions. Before recording your business
transactions, you must first create a business service.
To create a business service:
1. Navigate to Administration > Business Service. Click New to create a new business
service.
2. Enter a Name and Description for the business service. The business service name
and description are not case sensitive.
3. (Optional) Select the Business Application you created in Setting up a business
application (see page 73).
4. Select the Impact Level, which determines the business priority of business
transaction defects associated with this business service. (In most cases, the default
value of medium is sufficient.)
The default is to inherit the impact level from the domain. If you want to change
from the domain priority, clear the check box and select the appropriate impact
level from the list.
Note: To change the domain default values, go to Setup > Domain. See the CA APM
Configuration and Administration Guide for more information.
5. Click Save to save your new business service.
The new business service displays in the Business service list.
The business service you define is also displayed in the Introscope Investigator. The
business transactions you record and associate with a business service are displayed in
the Investigator. You can monitor business transaction metrics using the Investigator.
For more information on how to view and monitor business services and transactions in
the Introscope Investigator, see the CA APM Workstation User Guide.
Setting up an agent filter


Setting up an agent filter
An agent filter allows you to filter which agents will return data for business
transactions. This will help limit the number of business services that are evaluated by a
particular agent. While this is an optional step, without an agent filter, business
transaction definitions are sent to every agent. If you have an agent filter, you can have
the business transactions evaluated by only a subset of your existing agents, for
example 50 of your existing 4000 agents. Limiting the number of business transactions
definitions an agent has to match on allows for better agent performance.
To set up an agent filter:
Important: When setting the regular expression filter, you must use four segments that
identify the following:
<SuperDomain>|<HostName>|<ApplicationServer>|<AgentName>. For business
transactions recorded by the agent to appear correctly in the application triage map in
the Workstation, you must supply the SuperDomain. Use of wildcards for the other
three segments is acceptable. All four segments must be provided for the agent filter to
function correctly.
1. Navigate to Administration > Business Services > Agent Filter. Click New to create a
new agent filter.
2. Select the business service you want to filter.
3. Set one of the following:
Agent Name Regular Expression
Enter a regular expression for a specific agent, for example
SuperDomain|XINYI01|Weblogic|WebLogic Agent, or use regular expressions
to specify a range of agents, for example SuperDomain|XINYI01|(.*)|(.*).
Introscope Domain
Contains all Introscope domain information. You can select one or more
domains from the list. Agents associated with this domain will be used to
monitor the transactions you record.
4. Click Save to save the filter.
The new filter is now listed in the agent filters.
Recording a business transaction


The agent recorder has been designed to help you capture one business transaction,
review it, then move on to the next business transaction. This allows you to analyze
transactions individually, rather than having to remember the exact sequence of clicks
you took during a lengthy recording session.
Tip: For the purposes of agent recording, think of a business transaction in terms of a
web browser clickfor example, a click to log in, or a click to buy a product.
As you use the agent recorder, make sure you capture transactions that:
are named appropriatelyif they are not named well, you might not realize what
the transactions are really doing, and therefore what it means to your business.
are truly the transactions you needif they are not the identifying transactions you
need, then your metrics will show too much or too little activity; the activity will not
be an accurate reflection of the actual user transactions.
Here is a high level example of an agent recording session:
1. Start the agent recorder in the CEM console.
2. In a separate browser, click to log in to your application.
3. Switch back to the CEM console and stop the agent recorder.
4. Review the resulting business transaction signature. You realize the name might be
confusing later and change the name of the business transaction to something
more meaningful.
5. Start the agent recorder again.
6. Click to buy a product in your application.
7. Stop the agent recorder.
8. Review the resulting business transaction signature. You realize that the identifying
business transaction (the buy) did not appear first. For example, a re-direct might
appear first.
9. Delete the first, non-identifying business transaction, which leaves the correct,
identifying business transaction first in the list. Check the box to mark the first
business transaction as identifying.
Continue with the steps above as required, until you are finished with all the
transactions you need.
To capture business transaction information, you must perform the recording from a
client computer that can perform the user activity you want to observe. For example, if
you are working from a client computer that does not have access to your application,
you cannot record transactions from your application.


Known limitations
When configuring agent recording, there are some known limitations when using
regular expressions. The known limitations are:
POST parameters (see page 77)
HTTP path parameters (see page 78)
Agents may not handle host names correctly (see page 78)
IPv6 (see page 78)
POST parameters
The known limitations for POST parameters are:
Non-printable characters are not supported in POST parameters and may produce
unexpected results.
If POST parameter definitions are dependent on the business transaction definition,
only three metrics will be provided for the business transaction component. These
metrics are:
Average Response Time
Responses Per Interval
Errors Per Interval
For more information, see the properties appendix of either the CA APM .NET
Agent Implementation Guide or the CA APM Java Agent Implementation Guide.
If business transaction definitions are dependent on POST parameter definitions,
then the business component name in the business transaction trace component
will have a generic name and not the specific name of the business service, business
transaction, and business transaction component. This also applies to business
transaction definitions that are dependent on POST parameter definitions that do
not match.
Some versions of JBoss and Tomcat might save header keys as lower case values
which makes the caseSensitiveName attribute not work properly for
HEADER_TYPEs.


HTTP path parameters
Agents process HTTP path parameters differently than the TIM. Path parameters are
parameters that appear in the URL path as semicolon (;) separated pairs, for example:
http://mysite.mydomain.com/some/path;param1=value1
Note: These are different from query parameters, which are normally separated by a
question mark (?).
The agent considers path parameters as part of the URL path and is not capable of
matching them individually.
The TIM also considers path parameters as part of the URL path, but is capable of
matching business transaction components based on individual path parameters. If
business transaction components contains rules for individual path parameters, the TIM
does matching based on these rules. However, the agent will ignore these rules as if the
rules do not exist.
If business transaction components must to be identified by the agent by path
parameters, match them as part of the URL path using regular expressions rather than
using individual path parameters.
Important: Path parameters named JSESSIONID will not be seen by the agent in the URL
paths when the agent is running on WebLogic Application Server. This is due to the
special meaning this path parameter has for WebLogic Application Server.
Agents may not handle host names correctly
Business transactions monitored by .NET Agents are not recognized when they are
defined to match on the host names of IP addresses. However, business transactions
monitored via Java Agents under the same conditions are recognized and appear in the
Investigator tree as expected.
To work around this issue, change the Host name to match on an UPPERCASE host name
instead of an IP address. You change this setting by navigating to Business Services >
Business Transactions > Transactions > Components > Identification in the CEM console.
IPv6
Agent recording may be unavailable in environments using IPv6. For more information
on IPv6 and CA CEM, see the CA APM Configuration and Administration Guide.
Starting an agent recording session


Record when traffic through your application is low, or, if you have a test lab
environment, use the test lab to record and then export the transactions to your
production environment.
To start an agent recording session:
Important! If you are using a proxy server, you can experience problems recording. CA
Technologies recommends recording transactions with the agent from machines that
can directly see the machine that is monitored by agents to avoid problems. If you must
record using a proxy server, see Agent recording and proxy servers (see page 82).
1. From the CEM console, navigate to Administration > Recording Sessions.
Note: If you cannot see the Recording Sessions tab, verify that you have write
2. Click New to go to the agent recorder page.
3. Enter a name for the recording.
Give the recording a meaningful name that helps you identify the business
transaction recording later.
Tip: You might want an image capture for each business transaction to help a
business user understand the recordings later. For example, capture the web page
for the business transaction, then paste the image into a document. To
cross-reference recordings to transactions, type the name of each recording under
each captured image.
4. Set the recording conditions. If you are recording transactions from this computer
and this computer is not behind a proxy server, you can accept the default
conditions and skip to step 5 below to start recording the session.
Client IP Address
The client computer that the transactions will be recorded from. The system
automatically fills in the web browser address of the client computer currently
connected to the CEM console.
Note: If you are recording using an agent that is on the same machine as the
Enterprise Manager, use the local host IP address (also known as the loop back
address, 127.0.0.1) instead of the actual IP address (for example:
130.200.163.90).


Agent Identifier
Identify a specific agent, or use regular expressions to identify multiple agents.
The default is .*, which identifies all agents.
If you set an agent filter, the default of this field will only return transactions
from the agents specified in the filter. You can use this field to further narrow
the scope of agents monitoring transactions.
Browser Language Pattern
In most cases, accept the default.
However, if you are recording from behind a proxy server or in some other
environment where the client IP address might be masked, then you should
change your web browser language and set the browser language pattern field
to match exactly. See Setting up for recording with a proxy server (see page 51)
and Recording with an agent through a proxy server (see page 83).
Tip: If you are in a country other than the US, then your default language might
be something else (for example, en-au instead of en-us).
5. Click Record to start recording the session.

The Recording Status indicates the recording is in process.
6. Perform the business transaction that you want to record on the client computer.
For example, log in to an account.
The recorder page lists the transactions recorded.
Name
An interim business transaction name, which you can modify later
Content type
From the HTML header; text/html, image, css, script, and so on.
HTTP Status Code
200=OK; 300=redirect; 400=client; 500=server
Method
GET, POST
URL
Shows all the URLs that you go through as your business transaction progresses



Tip: If you do not see any business transaction activity on the page, verify that the
TIM is able to monitor your client computer activity; you might have to work on a
different client computer, depending on your network configuration.
7. Click Stop when you are finished recording your business transaction.

The Recording Status indicates that the recording has been stopped. All your
transactions appear in the list.
You can review and modify the transactions immediately, when you can remember
exactly what you did, and in what order.
8. Change the transactions as needed.
a. Click the Update button to:
Rename the business transaction, if required.
Change whether or not a business transaction must be included.
Change whether or not a business transaction is cacheable.
Change the identifying business transaction from one to another.
Note: There can be only one identifying business transaction.
b. Select a check box to the left of a business transaction and use the Delete
button to:
Delete a non-essential business transaction that you recorded.
Delete a non-identifying business transaction that appears before an
identifying one.
Note: The identifying business transaction must be the first in the list. For
example, a redirect might appear as the first business transaction.
Agent recording and proxy servers


9. If you want to record another business transaction, click Record Next Transaction
and repeat the steps. For example, after the login, you might need to record a buy
business transaction.
Continue to record, stop, and analyze until you have recorded all the transactions
that you need.
10. Click Finished Recording when there are no more transactions to record.

The page refreshes with the business transaction signature from the recording, with
the identifying transactions appearing. See Viewing recording sessions (see page 85)
or Editing recording sessions (see page 87) for more information.
The functionality of agent recording is somewhat complicated by recording with an
agent through a proxy server. The following details how to configure the agent using the
CEM console to record with an agent directly, and to record with an agent through a
proxy server.


Recording with an agent (no proxy server)
When a recording session is started, by default the IP address of the machine where the
recording is launched is the IP addressed used in the CEM console for the Client IP
Address.
If you are recording with an agent that does not go through a proxy server, the record
request goes to the web application server and agent directly from the client
browser/machine.

In this case, the CEM console uses the client IP address (a.a.a.a) to initiate a recording
session, as well as to capture business transaction data.
Recording with an agent through a proxy server
If you are recording with an agent that you connect to through a proxy server, the
record request goes through the proxy server before it goes to the agent, for various
reasons, such as security.

In this case, you should enter the proxy server IP address (p.p.p.p.) in the field for the
Client IP address when setting up the recording conditions (see Starting an agent
recording session (see page 79), step 4. If you are recording transactions from this
computer and this computer is not behind a proxy server, you can accept the default
conditions and skip to step 5 of Click Record to start recording the session..).


However, in real world scenarios, you could have multiple clients sending requests to
the same web application server and agent.

When this occurs, the HTTP traffic from multiple clients is recorded.
To filter out multiple clients and record traffic from one specific client, you use the
Browser Language Pattern field as a filter. For example, if you want to record only those
transactions coming from a client machine with IP address b.b.b.b., you would set the
client machines browser language to something non-English based, for example tai-tw.
You would set the CEM console fields to:
Client IP Address: b.b.b.b.
Browser Language Pattern: tai-tw
When these conditions have been set, the agent records only transactions coming from
b.b.b.b.


To view the recording sessions:
Note: If you cannot see the Recording Sessions tab, ensure that you have write
2. Your recording sessions appear at the top of the list. Click the name of a recording
session to view the contents.

Viewing the recording session transactions
The recording session business transaction page shows, by default, the identifying
transactions. You can do several things from this point:
Restart recording, which adds more transactions to this session.
Delete any business transaction in the list.
Promote any business transaction in the list, that is, associate the business
transaction definition with an existing business service.
Modify the page display to show all transactions, rather than only showing the
identifying transactions to view all recognized and unrecognized transactions.
Turn an unrecognized transaction into a recognized transaction to monitor it after
promotion.
Note: You can move an unrecognized transaction to the recognized transaction list,
only if it has the successful HTTP status code (that is, 2xx). Moving an unrecognized
transaction can cause unexpected results after you promote them.
For more information, see About unrecognized transaction components (see page 54).


Viewing the recording session parameter map
The recording session parameter map is useful for determining business transaction
identification parameters: session-id, login-name and business transaction
identification. For each business transaction parameter in a recording session, the
parameter map shows:
Transaction CountThe number of times the parameter appears in the recording.
Distinct Value CountThe number of distinct values the parameter contains during
the recording.
Tip: The Transaction Count and Distinct Value Count for parameters are helpful in the
business transaction identification process. When you are looking for ways to identify
your transactions, its a good idea to start with parameters with high counts.
To view the recording session parameter map:
2. Select a recording session, and click the Parameter Map link.



Once you have created a recording session, you can edit the name and other aspects of
the recording.
To edit recording sessions:
2. Click on the name of your recording session, which is usually located at or near the
top of the list.
3. Select the General link if you want to change the name of the recording session or
the client IP address, which defaults to the client computer the recording was run
from.

Promoting transactions to definitions


5. If you want to change the names of any of the transactions in the recording or add
comments, click the Transactions link and click on the name of the business
transaction.
The General link appears. Change the name or add comments on this page.

After you have collected and generalized transactions (called a business transaction
signature), you promote the signatures to business transaction definitions. For example,
if you want to create a business transaction definition for executing a purchase, you can
select the Execute Buy business transaction signature and promote it to a business
transaction definition within your business service.
You must have already defined your business service before performing this procedure.
See Setting up a business service (see page 74) for more information.
If you do not want to create a transaction, but instead want to replace an existing
transaction, see Replacing existing business transaction definitions (see page 156).
Once you have promoted a signature to a business service, you enable the signature and
send it out to your agents. Once the signature is sent to your agents, the agents monitor
for the transactions matching the signature and report this data to the Enterprise
Manager.
Important! Be sure to both promote your business transaction definitions and
synchronize monitors. If you do not, your definitions will not be sent to the agents for
monitoring.


To promote the collected business transaction signatures to business transaction
definitions:
2. Select the name of a recording session you have created.
3. Select one or more of the check boxes in front of the business transaction
signatures you want to promote.
4. From the Promote to drop down menu, select the name of the business service you
want to associate the business transaction with, then click Promote.
The Business Transactions page appears.
5. Select the business transaction name check box and then click Enable to enable the
business transaction definition.
6. Repeat steps 2 through 5 until you have enabled all transactions you want for a
specific business service.
Once all transactions have been enabled, you must push these settings out to the
agents. To do this, you must synchronize monitors. Synchronizing will send the business
transaction definitions to the agents. Once the agents have the business transaction
definitions, they will begin monitoring and reporting data about the transactions.
To synchronize monitors:
2. Click the Synchronize All Monitors button.
Monitors have now sent the business transaction definitions to your agents.


Chapter 5: Automatically discovering
transactions

As an alternative to recording transaction signatures (as described in Recording
transaction signatures (see page 49)), you can have CA CEM automatically discover
transactions for you. You set up some bounding parameters to describe the transactions
that you are interested in, for example, the website, the language, and parameters
(such as post, query, and cookies). Additionally, you can choose to discover transactions
from all or some of the TIMs. Then, after monitoring your users transactions for a while,
CA CEM presents you with discovered transactions that you can edit and enable as you
want.
This process describes the tasks required to discover transactions:
1. Learn about automatic transaction discovery and its advantages. (see page 92)
2. Create a template for automatic transaction discovery and add parameters to it.
(see page 93)
3. Enable the template so that it is ready to discover transactions. (see page 98)
4. (Optional) Edit the template and its parameters. (see page 98)
5. Choose which TIMs participate in transaction discovery. (see page 99)
6. Begin discovering transactions. (see page 100)
7. Stop discovering transactions. (see page 101)
8. Examine discovered transactions. (see page 102)
9. Edit and enable monitoring for the discovered transactions. (see page 103)
10. If you want to look for new non-identifying components associate with currently
monitored transactions, enable automatic discovery of non-identifying
components. (see page 91)
About automatic transaction discovery


About automatic transaction discovery
CA CEM monitors the user experience of performing web transactions. However, the
application administrator who is responsible for managing CA CEM has to define these
transactions. This task involves recording the transactions and then specifying which
aspects of each transaction uniquely identify it. In some cases, the application
administrator spends significant time performing this task. In addition, the administrator
might need the help of the web programmers who know about the internal details of
the transactions that are required to specify the identifying aspects.
Furthermore, when the transaction changes, re-record the transaction. Some
web-based applications change frequently.
Automatic transaction discovery provides a solution to the drawbacks of regular
transaction recording and promoting.
Automatic transaction discovery facilitates:
Identifying transactions:
Identifying the transaction based on the URL
Every new URL is considered a separate transaction. The administrator can
determine what is a transaction by specifying certain content types.
Identifying the transaction based on hints provided by the application owner
Even in sophisticated and complex web applications, there is usually a set of
parameters whose combination can uniquely identify the transaction. The
application owner (with help from the web application developers) can provide
this list so that automatic transaction discovery can find the transactions that
contain these parameters. This method is more hands-on than identifying
solely on URL. However, its advantages are that it can be done without the help
of application programmers and that parameters that are unlikely to change
can be used.
Updating transactions:
Automatic transaction discovery can find changes in the non-identifying
components of transactions that are already being monitored. These components
can be automatically added to the transaction definition. Examples of
non-identifying components that might change are images and JavaScript files.
Automatically discovering non-identifying components in currently monitored
transactions significantly reduces the manual effort required by the administrator
to maintain transactions.
In summary, the automatic transaction discovery feature records the actual user
experience of transactions. In some applications, this may be superior to a recording
session carried out by an administrator (described in Recording transaction signatures
(see page 49)).
Creating a template and parameters


The first task in setting up automatic transaction discovery is to create transaction
templates and parameters for the templates. The templates specify the URLs,
applications, and content-type for discovery.
Also, the template groups the parameters, and the parameters specify the kinds of
transactions you want to discover. The template can contain response parameters. You
must have at least one request parameter before you add a response parameter.
The more familiar you are with the web application being monitored, the better. This
familiarity helps you decide what parameters to define and how many parameters to
define. In general, the more specific you can be, the more you can reduce the number of
transactions that are of no interest. For example, if you know the port for an
application, specifying it as a required parameter limits the volume of transactions that
the TIM returns to the Enterprise Manager.
Tip: If you have access to the web application developers, ask them to suggest
appropriate parameters.
The order in which you create templates is important. If you have multiple templates,
create the templates with the more specific URL path filters first (see page 98).
To create a template and parameters:
1. Select Administration > Transaction Discovery.
2. In the Templates section of the page, click New.
The Transaction Template page appears.
3. Complete the fields and click Save.
Name
Give a meaningful name to the template. This name cannot be changed after
saving.
Description
Add a comment about the template.
URL Path Filter
The default of /* allows discovery of transactions from all URLs. In a production
environment, modify this to restrict the traffic that the TIMs analyze for new
transactions. Only one * (wildcard) can be used. See the URL Path Filter
examples (see page 95).


Content Type Filter
The default of text/html means that only transactions where the response has
a content type of text/html are discovered; for example, Content-Type:
text/html; charset=utf-8. (The charset information is ignored.)
If the Content Type Filter is set to *, then most types of content are discovered;
other possible settings are text/plain, text/*, text/xml. However, using this
wildcard does not enable discovery of Flex or HTML tags.
To discover Flex transactions, specify a content-type of application/xml,
application/x-amf, or application/x*.
Business Application
Select the business application for the transactions that you want to record.
Automatically discovered transactions can only be promoted to business
services having the same business application type.
The business application session identification parameters are used to group
the non-identifying components with the identifying component.
Also important is character encoding. The character encoding definition for the
application is used to translate the parameter values.
After the template is saved, you can add parameters to it.
4. Click New.
The Parameters page appears.
5. Complete the fields.
Type
Select Cookie, Post, Query, URL, HTTP Header, Path, Any, Plug-in, Flex Request
Property, Flex HTTP Request Header, HTTP Response, HTTP Response Header,
HTML Response Tag, Plug-in HTTP Response, or Flex Response Property.
Any means any of the other types. See the Any type example (see page 95). If
you use Path parameters, see Path parameter example (see page 97).
Action
Select Matches or Matches regular expression. Wildcards can be used with
Matches. For information about regular expressions in CA CEM, see the Regular
expressions in CA CEM (see page 201).
Required
If a parameter is required, the transaction is not discovered if the parameter is
not present. For a transaction to be discovered, all the parameters marked
required must be present and their values must match.
The order that the parameters appear determines the transaction names. See the
Transaction naming example (see page 96).


6. Confirm that the Name and Type values are correct. These values cannot be
changed after you click Save.
7. Click Save.
URL Path Filter examples
Only one * can be used. Regular expressions cannot be used.
A URL Path Filter of /mybank/* discovers transactions to web pages with this URL:
www.thebank.com/mybank/Default.aspx
but not with this URL: www.thebank.com/public/mybank/Default.aspx
Any type example
Setting the parameter type to Any means that if any parameter from the list has a
name/value pair that matches the Name/Action/Pattern specified, a transaction is
discovered.
For example, if Type = Any, Name = P1, Action = Matches and Pattern = ABC123, then a
cookie or a query or a post or any type where there is a value/name pair like P1=ABC123
can be a discovered transaction.

For example, if any of these are observed, a definition is generated:
Cookie: P1=ABC123
or a query parameter
www.company.com/dir/file.html?P1=ABC123
or a post parameter
P1=ABC123&P6=V6
If all of these are discovered in separate transactions, then the transactions are named
ABC123, ABC123(1), and ABC123(2).


Multiple transactions discovered from one template
Every combination of parameter type, name, and value is a different definition. For
example, if the template parameters include the URL path and query parameters action
and type, like this:

Then these URLs:
/app?action=buy&type=new
/app?action=sell&type=new
/app?action=buy&type=old
/app?action=sell&type=old
Generate these definitions:
/app-new-buy
/app-new-sell
/app-old-buy
/app-old-sell

Transaction naming example
Discovered transactions are named according to the parameters found. The parameters
are separated by hyphens. The transaction name is based on the order that the
parameters appear in the parameter list.
For example, these parameters:

Resulted in these transactions named:
192.168.163.89-/Petshopp/Items.aspx
192.168.163.89-FISH-/Petshopp/Category.aspx


Path parameter example
If you set path parameters, ensure that the Path Parameter Delimiters field contains the
correct path parameter delimiter. (To specify a path delimiter, see Setting the global
delimiter for path parameters (see page 46).) If the delimiter is a semicolon (;) and the
path parameter is as follows:

Then transactions can be discovered for this URL path.
http://www.petshopp.com/Petshopp/MyItems.html;action=buy;quantity=10
However, if the separator is set to any other character, then no path parameters can be
discovered.
A catchall example
In a test environment, you might want to try setting the widest possible filter and
parameters in order to catchall transactions for a short period of time. You can then
review all the business transactions captured and use this to help you decide what
templates and parameters to create for more specific discovery of transactions. For a
catchall filter and parameters, set the URL path filter to /*

and a URL path parameter to match * .

Important: Only use a catchall template like this for a short time and in a test
environment. Such a template can generate many transactions very quickly.
Enabling templates


The order in which templates are created
If you have multiple templates, you need to take care with the order in which you create
them. Transactions are discovered in the order that the templates are listed in the table.
It is important that you create the templates with the most specific path filters before
the templates with the more general path filters.
If the template with the most general path filter (/*) is created first, then it discovers all
the transactions and the other two templates are ignored.
However, if template with the most specific path filter is created first and the most
general created last, then any matching transactions with the /dir/file* path are
discovered. Traffic that does not match is passed to the less general template (/dir/*)
and finally to most general template (/*).

Enabling templates
After a template and its parameters have been created, you need to enable it. If you
have multiple templates, enable those with the more specific URL path filters first. See
the order in which templates are created (see page 98).
To enable a template:
2. In the templates list, select the disabled template that you want to enable.
Ensure that the template has at least one parameter.
3. Click Enable.
Editing templates
You can edit the template and its parameters. You can also add and delete parameters
from the template.
However, you cannot change these things:
The name of the template
Parameter type
Selecting the TIMs for automatic transaction discovery


Parameter name
The position of a parameter in the list
Tip: You can delete a template or a parameter and recreate a similar one with a
different name or type.
To edit a template:
2. In the templates list, click a template name.
The Transaction Template page appears.
3. Make changes to the template and click Save.
4. Make changes to the parameters and click Update.
Selecting the TIMs for automatic transaction discovery
Note: The service discussed in this topic is an Enterprise Manager service. It is not a
business service.
By default, HTTP traffic from all TIMs is scanned when automatic transaction discovery is
running. However, you can specify that only some of the TIMs in your environment
participate in automatic transaction discovery.
You might want to do this if you know that the transactions of interest are only being
accessed by a particular TIM. Limiting transaction discovery to this TIM means no
overhead related to discovery is placed on the other TIMs.
To view or specify which TIMs participate in automatic transaction discovery:
1. Select Setup > Services.
2. Click TIM Collection Service.
3. In the TIM Collection Service menu, select Transaction Discovery Collection Service.
The TIMs that are participating in transaction discovery are marked enabled in the
TIMs list.
4. If necessary, select or clear TIMs from the list.
5. Click Save.
For general information about Enterprise Manager services, see the CA APM
Starting automatic transaction discovery


Starting automatic transaction discovery
After you have created and enabled at least one template, you are ready to start
automatic transaction discovery.
To start automatic transaction discovery:
2. (Optional) Set automatic stops for transaction discovery:
a. Select the Limit the number of transactions check box and specify a maximum
number.
b. Select the Stop discovering transactions after check box and specify a time in
minutes.
Tip: Best practice is to enable both of these limits. If your transaction templates are
less specific that you think or you forget to turn off transaction discover, setting
these limits can prevent the performance impact of excessive transaction discovery.
3. Ensure that the Path Parameter Separator is set to the correct character for the
web application being monitored.
If a path parameter separator is specified, everything after the separator character
is replaced with a *. For example, if the separator is ; and the observed path is
/login;SessionId=f03a4622;lang=en then the TIM reports "/login*" as the URL path
parameter pattern. This is so that generated definitions match actual URLs
irrespective of path parameters. If no path separator is set the above example, then
a new transaction is discovered for each unique session id.
Note: An observed path parameter of /login;SessionId=f03a4622 does not match a
configured URL path /login but does match /login*
For more information, see Path parameter example (see page 97).
4. Click Start.
You might see the status set to In Progress before it changes to Running.
5. To ensure that automatic transaction discovery is on, check that these conditions
are met:
The Transaction Discovery Collection Service is running.
The Start button is unavailable and the Stop button is available.
If the Limit the number of transactions option is enabled, then the limit
number must exceed the current number.
If the Stop discovering after option is enabled, then it has been less than the
number of minutes since this option was enabled and saved.
Stopping automatic transaction discovery


Stopping automatic transaction discovery
Automatic transaction discovery stops when either of these conditions are met:
The Transaction Discovery Collection Service is stopped.
The Discovered Transactions business service contains the maximum number of
business transactions.
Stopping the Transaction Discovery Collection Service
There are two ways to stop the Transaction Discovery Collection Service.
To stop automatic transaction discovery manually:
2. Click Stop.
To stop automatic transaction discovery by elapsed time:
1. Select the Stop discovering after option.
2. Enter a number of minutes to run the discovery.
3. Click Save.
Stopping automatic transaction discovery, but not stopping the service
The discovery of transaction also stops when the maximum number of transactions have
been discovered. However, in this case, the Transaction Discovery Collection Service
does not stop, so that if you remove business transactions from the Discovered
Transactions business service, then discovery starts again because the service is still
running.
To stop automatic transaction discovery by limiting the number of transactions
discovered:
2. Select the Limit the number of transactions option.
3. Enter a number.
The number must be larger than the current number of transactions in the business
service.
4. Click Save.
Viewing discovered transactions


Viewing discovered transactions
Either while discovery is in process or after it has stopped, you can view the transactions
that have been discovered.
To view discovered transactions:
2. Click the Click here link.
The Business Service: Discovered Transactions page appears.

On this page, CA CEM displays the following information about each discovered
transaction:
Name
First Discovered Date
Last Discovered Date
Number of Times Detected
Transaction Template
Matches Enabled Request Business Transaction
If a discovered component matches an existing, identifying component of the
identifying transaction of an enabled business transaction, CA CEM displays this
information in the Matches Enabled Request Business Transaction.
If a transaction matches an existing, enabled request-based transaction definition,
CA CEM discovers that transaction if it matches the required response parameters
specified in the template. CA CEM displays the name of the matching request-based
business transaction in the Matches Enabled Request Business Transaction column.
Monitoring discovered transactions


Monitoring discovered transactions
Before they can be edited or monitored, discovered transactions must be moved from
the Discovered Transaction business service to another business service.
To move a discovered transaction to another business service:
1. Select Administration > Business Services.
2. Click Discovered Transactions.
3. Select one or more business transactions to move to another business service.
4. In the Move to list, choose the business service that you want to move the
transaction to.
Ensure that the business application is the same for both the discovered transaction
business service and the new business service.
5. Click Move.
7. Click business service that you moved the transaction to.
8. Edit the business transaction as necessary and then enable it.
Once it has been moved into a different business service it can be treated as any
other business service. You set the defect definitions. You can check what is
identified for matching transactions and refine if necessary.
When monitors are next synchronized, monitoring begins for the transaction.
9. (Optional) A good practice is to disable the template after the discovered
transactions have been moved and are being monitored.
Automatically discovering components
The other topics in this chapter describe how to find new transactions that you might
want to monitor. This topic describes another type of automatic discovery feature that
you can use.
This is automatic capture of non-identifying components. Automatic capture of
non-identifying components applies to existing transactions that are currently being
monitored by the TIMs. That is, enabled, synchronized transactions in business services.
It does not apply to transactions in the Discovered Transactions business service.
When capture of non-identifying components is enabled, if any new, non-identifying
components (associated with enabled transactions) are observed by the TIMs, these are
automatically added to the transaction.
Automatically discovering components


Example 1
You are currently monitoring a transaction that has four components, one identifying
and the rest non-identifying.

A recent modification to the web application that you are monitoring has added two
new graphics. If capture of non-identifying components is enabled, these new
components appear in the component list for the transaction.

Example 2
You recorded a transaction using agents recording only (Introscope agent recording).
Agents recording does not capture the non-identifying components that are observed
by the TIMs. However, when you enable capture of non-identifying components, all the
components associated with this transaction that can be monitored by the TIMs, and
thus more complete data and statistics about the transaction are collected.
Troubleshooting automatic transaction discovery


To capture non-identifying components:
2. Select Discover new non-identifying components.
3. Start automatic transaction discovery. For more information, see Starting automatic
transaction discovery (see page 100).
4. Run automatic transaction discovery for a while and then stop it.
When non-identifying components have been captured, the Monitors are not
synchronized icon appears.
5. (Optional) View which new components have been added by viewing configuration
changes since last synchronization. See the CA APM Configuration and
Administration Guide for instructions on how to do this.
6. Synchronize monitors to start the monitoring of the new non-identifying
components.
About the maximum number of non-identifying components
By default, up to 50 non-identifying components can be discovered per transaction.
After 50 have been discovered, the oldest ones are deleted to allow new ones to be
added. A CA CEM event called Limit exceeded adding new components is logged each
time a new non-identifying component replaces an old one.
To change the maximum number of non-identifying components, edit the
Autogen.Max.NonIdentifying.Components property; see tess-default properties in the
CA APM Configuration and Administration Guide.
The following lists some common problems with automatic transaction discovery and
how to solve them.
Symptom:
No transactions are being discovered.
Solution:
Verify that:
The template contains at least one parameter.
The template is enabled.


Symptom:
No transactions are being discovered.
Solution:
Verify that there are no existing transactions that are the same or broader that are also
being monitored.
If the template and parameters match any already defined transaction definition
(enabled and synchronized), then transactions are not discovered for the template.
Symptom:
Transactions are being discovered but not for the templates that you expect.
Solution:
Verify that you created the templates in the correct order according to the URL path
filter. See the order in which templates are created (see page 98).
Symptom:
Transactions are no longer being discovered.
Solution:
1. Verify that the template is enabled.
2. Verify that the Transaction Discovery Collection Service is started.
3. Verify that the discovery was not running on a timer and has stopped.
4. If a transaction limit was set, the discovered transaction limit may have been
reached.
Symptom:
Not all non-identifying components are being discovered
Solution:
Browser caching can prevent some non-identifying components from being discovered.
If possible, clear the browser cache. Otherwise, the components are eventually added
when accessed by a browser that has not cached them yet.
Symptom:
Path parameters are not being discovered as expected.
Solution:
Verify that the Path Parameter Delimiters field (Setting the global delimiter for path
parameters) includes the character that separates the path parameters.


Symptom:
The message "Warning: Autogen service is not enabled for monitoring" displays.
Solution:
The error message displays after you modify or add a template but the transaction
discovery service is not running. What it means is that the changes are not sent to the
TIM. To start the service, go to the Transaction Discovery tab and click Start.


Chapter 6: Defining transactions

About transaction definitions and identifiers (see page 109)
About edits to request and response identifiers (see page 110)
Promoting transaction signatures to definitions (see page 110)
Creating Business Transactions (see page 111)
Editing transactions (see page 113)
Editing transaction components (see page 116)
Wildcarding parameter names (see page 119)
Using XML to identify transactions (see page 120)
Adding and deleting parameters (see page 122)
About defining defects (see page 124)
Defining business transaction defects (see page 125)
Defining transaction defects (see page 127)
Defining component defects (see page 128)
Viewing access policies for business services (see page 130)
Adding access policies for business services (see page 131)
Monitoring transactions (see page 134)
About transaction definitions and identifiers
To create a transaction definition, you must determine which transactions to match and
what patterns will trigger a match. A transaction identifier is a set of parameters that
include:
Type the type of the transaction, such as Cookie, Post, Query, or URL.
Name the name of a transaction identification parameter, which is a unique
identifier (for example, the URL names Path and Host are assigned to the
corresponding parts of the URL). All other names are detected from the CA CEM
Recorder and represent parameter names at the time of the recording.
Match options which parameters to use in the transaction identification process.
Transactions can be defined based on a parameter value matching a value or string,
a parameter not existing. A parameter can also be ignored in the transaction
identification process.
Pattern the pattern that must be matched for a parameter to be selected in the
transaction identification process. Wildcards can be used in pattern matching.
The best transaction identifiers are usually those that have the fewest identification
parameters necessary to uniquely identify a transaction type. Selecting too few
identification parameters might cause your transaction identifiers to match more than
one transaction definition. Selecting too many identifying parameters might cause only
certain instances of a transaction to be matched.
About edits to request and response identifiers


One way to create a transaction definition is to record transaction signatures on your
network and promote them to transaction definitions. You can then edit the transaction
definitions to create the best matching conditions for your network.
About edits to request and response identifiers
Here are some things to know when editing request-based or response-based
transactions:
If you edit a request-based transaction definition that has one or more associated
response-based transactions, the updated request parameters display when you
next view the response-based transaction definitions.
If you edit a response-based transaction definition, the changes do not display the
next time you view the associated request-based transaction definition.
If you delete a request-based transaction definition that has one or more associated
response-based transactions, CA CEM also deletes all associated response-based
transaction definitions.
If you edit a response-based transaction definition, CA CEM displays the
request-based parameters for informational purposes only. You cannot edit the
request-based parameters while editing the response-based parameters.
If you edit a request-based transaction definition, CA CEM displays the
response-based parameters for informational purposes only. You cannot edit the
response-based parameters while editing the request-based parameters.

Promoting transaction signatures to definitions
After you have collected transaction signatures through a CA CEM recording session,
you can promote the signatures to transaction definitions to use in your transaction
analysis. For example, if you want to create a transaction definition for executing a
purchase, you can select the Execute Buy transaction signature and promote it to a
transaction definition within your business service.
You must have already defined your business service before performing this procedure.
See Defining business services (see page 47) for more information.
If you do not want to create a transaction, but instead want to replace an existing
transaction, see Replacing existing business transaction definitions (see page 156).
Creating Business Transactions


To promote the collected transaction signatures to transaction definitions:
1. Select Administration, Recording Sessions.
The Transactions page appears. For more information, see Recording transaction
signatures (see page 49).
3. To view only the identifying transactions, select Only Identifying in the Show list
box. To see identifying and nonidentifying transactions, select All.
4. Select one or more of the check boxes in front of the transaction signatures you
want to promote.
The promotion process is different for Siebel business transactions and for
non-Siebel business transactions. Each Siebel business transaction may contain one
or more transactions. Non-Siebel business transactions have exactly one
transaction. In both cases, you must specify exactly one transaction as the
identifying transaction for each business transaction.
a. To promote a collection of non-Siebel transaction signatures to transaction
definitions: select all of the check boxes in the Identifying column.
This will turn all transactions into business transactions with exactly one
transaction, which will also be its identifying transaction.
b. To promote a collection of Siebel transaction signatures to transaction
definitions: select only those check boxes in the Identifying column that match
the identifying transaction of each Siebel business transaction.
Identifying transactions mark the end of the previous business transaction and
the start of a new business transaction. Transactions without their Identifying
check box selected are sub-transactions belonging to the first Identifying
transaction above them in the list.
5. From the Promote to list, select the name of your business service, then click
Promote.
Note: The business service must be associated with a business application with the same
character encoding. See Monitoring multibyte transactions for more information.
1. Select the transaction name check box and then click Enable to enable the
transaction definition and start transaction monitoring.
The term business transaction is used to describe a sequence of back-to-back,
computer-generated transactions. Specify business transactions clearly, so they do not
include user-generated transactions that can add varying client behavior (think time) to
the transaction.


The business transaction consists of an identifying transaction and a number of other
related transactions which can be executed in any order. Transactions can be
designated as included, cacheable, or both:
Included select the transactions to include and make a part of a larger business
transaction. If a transaction is marked to be included, its size and time are included
in the size and time of the business transaction.
Cacheable a transaction must be designated to be included first before the
cacheable value is examined.
A cacheable transaction that is marked to be included in the business
transaction is optional. When it is observed, its time and size are included in
the time and size of the business transaction. When it is missing, no defects are
generated.
A non-cacheable component that is marked to be included in the business
transaction is mandatory. When CA CEM observes this component, its time and
size are included in the time and size of the business transaction. When it is
missing, CA CEM generates a Missing Component defect and marks the
transaction as defective.
Note: An included transaction that can be cached by the browser client or by a proxy
server must be marked as cacheable. Such a transaction may not be observed in the
data center when it has been cached.
To create business transactions:
1. Select Administration and then Business Services.
2. Click the name of the business service.
3. Select Business Transactions.
4. To create a request-based transaction, click New and provide a meaningful name
and description for the business transaction.
To create a response-based transaction, click Create Response-Based Transaction in
the row that lists the request transaction to which the response transaction
belongs.Continue to Step 6.
5. Select the Transaction Impact Level, which determines the business priority of the
defect type for the transaction. In most cases, the default value of Medium is
sufficient.
6. Fill in the Service Level Agreement (SLA) values that define the SLA at the business
transaction level.
Editing transactions


Note: These values are also used to define default SLA values that can be inherited
by the transactions within the business transaction.

Setting Description
Success Rate SLA Success Rate Service Level Agreement as a percentage. The
default is inherited from the business service.
Sigma SLA Sigma Service Level Agreement as a number. The default is
inherited from the business service.
Transaction Time
SLA
Transaction Time Service Level Agreement in seconds. The
default is inherited from the business service.
7. (Optional) Select Calculate Business Value and enter the Business Value quantity.
8. (Optional) Select Collect Transaction Statistics.
The Collect Transaction Statistics check box is not a requirement for reports; use it
sparingly and temporarily. Use Collect Transaction Statistics where a business
transaction has many transactions and further investigation is required to
determine which transaction is causing a delay.
9. Click Save.
CEM lists the new Business Transaction on the Business Service: Business
Transaction page.
Creating a good transaction definition means more than merely recording current
transaction signatures from single clients. To create a good transaction definition that
provides the most useful information for your organization, you may need to edit the
transaction definition to generalize it to match transactions executed by all users.
To identify the transactions to match:
2. Click the name of the business service (for example, Avitek Financial Services).


3. Click the name of the business transaction you want to edit (for example, Web).
The Transactions page appears.

4. Click the name of the transaction you want to edit (for example, Web).
The Components page appears.

The critical component set consists of a base transaction and a number of
components of the transaction. The components can be designated as included or
cacheable or both:
Included
A component that must be correctly delivered to the user for the transaction to
be considered successful. The entire transaction will be considered defective if
an included component is requested and not returned, or returned and found
to be defective. Included components sizes and times are included in the
transactions size and time.


Cacheable
A component must be designated as included first before the cacheable value
is examined.
An included cacheable component is optional. When it is observed, its time and size
are included in the transaction's time and size. When it is not observed, no defects
are generated.
An included non-cacheable component is mandatory. When it is observed, its time
and size are included in the transaction's time and size. When it is missing, CA CEM
generates a Missing Component defect and marks the transaction as defective.
An included component that has the potential of being cached by the browser
client or by a proxy server must be marked as cacheable. Transaction components
such as cascading style sheets, JavaScript, images, and other static content should
be marked as cacheable.
The table following this procedure lists a few example components.
For example, you have a web page that has a banner advertisement graphic
component, a main cascading style sheet component, and a JavaScript code
component. If you do not want to include the banner advertisement graphic
component in the transaction time, size, and throughput measurements, you would
mark only the cascading style sheet and JavaScript components as Included.
Main.css is included and cacheable, which means that when observed, its size
and time must be included in the transaction size and time. However, it is
cacheable, so if this component is not observed (for example, because it has
been cached by a proxy server or client web browser) the transaction is still
considered successful.
Content.js is included and it is not cacheable, which means that when
observed, its size and time must be included in the transaction size and time. It
is not cacheable, so this item must be observed as part of the transaction or
the transaction is not considered successful and a missing component defect is
generated.
Banner.gif is not included, but is cacheable, which means that its size and time
are not included in the transaction size and time. Because it is not included, the
cacheable value is meaningless and is not examined.
5. Specify whether to include a component in the transaction definition on this page
by selecting the Included check box.
If the component is not marked to be included, then its time and size are not
included in the transaction time and size.
Editing transaction components


6. For included components, select the Cacheable check box. A component must be
selected as included if you want to specify it as cacheable.
If you designate a component as cacheable, a proxy server or the client web
browser can cache the results.
Note: If you want to generate a defect when a specific component is missing, verify
that the Cacheable check box is not selected.
7. Click Update to save your changes to the component selections.
This table lists a few example components.

Component Included Cacheable
main.css Yes Yes
content.js Yes No
banner.gif No Yes

You can edit the transaction components to specify further what to include in your
transaction definitions. You can specify more parameters in the HTTP request or
response header or body.
When editing transaction components for a request transaction, CA CEM also displays
uneditable response parameters if they are defined in an associated response
transaction. When editing transaction components for a response transaction, CA CEM
displays the uneditable request parameters.
Note: Response parameters are only valid for identifying components of an identifying
transaction.
For information about adding new parameters to a transaction component, see Adding
parameters (see page 122).
For information about wildcarding transaction parameter names, see Wildcarding
parameter names (see page 119).


To edit a transaction component:
1. From a transaction components list, click the component name. (To access the
components list, see Editing transactions (see page 113).)
The Identification page appears.

2. In the Action column, select the operation to perform on each parameter:
(blank)
If the parameter is not relevant to determining whether transactions fall within
the transaction definition, select this option.
Matches
Select this option to compare the parameter value to the string or pattern in
the Pattern column.
Does not exist
If the parameter must not exist for transactions to fall within the transaction
definition, select this option. If the parameter exists in a transaction, regardless
of its value, the transaction does not match the transaction definition.
Matches regular expression
If you must use regular expressions as an alternative to simple pattern
matching, select this option. This option gives you the flexibility to combine
similar transactions, rather than having to record and identify every variation.
Note: Regular expressions are more powerful than the simple pattern matching in
CA CEM but are less efficient and therefore add some overhead on the TIM. See
Regular expressions in CA CEM (see page 201) for more information.


3. For each parameter requiring a match in the previous step, specify the parameter
value or pattern that must be observed for a user transaction to match this
transaction definition. Edit the Pattern text box to change the values to match for a
particular component.
You can generalize on which patterns to match using the "*" wildcard character.
Only one wildcard character is allowed for each pattern. These wildcard strings are
allowed:
abc* start matching
*xyz end matching
abc*xyz start and end matching
* always match (any value is acceptable)
For example, you want to make the URL path more generic by changing
/sampleportal/application/specific.url to /sampleportal/* so that any directories or
applications under the /sampleportal directory are matched.
4. If you are matching a URL path and the URL path includes path parameters (for
example, session ID path parameter in this URL path
"/browse.do;jsessionid=7ksjnc"), then do one of the following:
Add a * to the end of URL path pattern that you want to match (for example,
"browse.do*").
Use regular expression matching (for example, /.*browse.do.* to match a URL
path of "/mybank/browse.do;jsessionid=7ksjnc").
In both cases, be aware that transactions with longer URL paths are also matched
(for example, "/browse.doit;uid=7ksjnc"). However, if you do not wildcard the end
of the URL path pattern, the match fails and path parameters are not recognized.

5. Click Update to save your changes.
Wildcarding parameter names


Wildcarding parameter names
In addition to using the wildcard character for matching parameter values, you can use
the wildcard in parameter names.
Examples for using wildcards in parameter names:
On .NET applications, the session identifier parameter name might include a
timestamp based on the machine reboot time. Adding a wildcard to the parameters
name allows you to ignore the timestamp so that you do not need to redefine the
transaction every time the machine reboots.
On portal applications, such as WebSphere Portal, the transaction identifiers can
include post parameters which refer to buttons (for example BUTTON12,
BUTTON14) for links selected by the user. These identifiers can change each time
the portal application is recompiled. Rather than be forced to re-record the portal
after each recompile, you can now wildcard all but the common part of the
identifier name (for example BUTTON) and the appropriate parameter value to
identify the transaction.
You can use wildcards in parameter names for:
Transactions
Session Identification (See Defining session identifiers (see page 32))
To wildcard a parameter name:
1. Edit the transaction component as described in Editing transaction components
(see page 116).
2. Click on the name of the parameter.
Using XML to identify transactions


3. Set the Name Type to Wildcard string and include one "*" wildcard character in the
Name.
Only certain types of parameters can contain a wildcard (for example, cookie, post,
and query).
You can generalize on which parameters to match using the "*" wildcard character.
Only one wildcard character is allowed. These wildcard strings are allowed:
abc* start matching
*xyz end matching
abc*xyz start and end matching

You can use the power of XML to identify transactions. To do this, you first need to
record a transaction with the XML elements and attributes that you want. Then you can
use the required XML elements or attributes, found in the request body, to identify the
transactions.
To identify transactions via XML:
1. Record an example XML-based transaction that contains the elements and
attributes you need. See Recording transaction signatures (see page 49).
Note: You must create a recording session with the XML elements; you cannot
define XML parameters manually.
2. Select Administration > Business Services. Select the name of your business service
(for example, Avitek).
3. Select the name of the Business Transaction > Transaction > Component you want
to use to identify the transaction.
4. Click New to create a new identification parameter for the component.
The new parameter page appears.


5. Select the Type XML.
A Recording Session list appears.
6. Select the appropriate recording session from the list.
A Recording Transaction list appears.
7. Select the appropriate recording transaction from the list.
The XML request body appears.
8. Review the request body to find the identifying information you need.

9. Click on the element or attribute required to identify transactions.
10. Select the Action and enter the Pattern to complete the configuration. See Editing
transaction components (see page 116).
11. Click Save to save the new parameter. If you need to define more parameters,
repeat the steps.
Note: If you create multiple identification parameters for the transaction component,
then they must all be present to identify the transaction.
Adding and deleting parameters


You can add or remove parameters from the transaction definition as necessary.
To add a new parameter to a transaction definition:
1. Click New on the Identification page.(To access the Identification page, click a
component in the Components list, see Editing transactions (see page 113).)
2. Select a parameter Type from the drop-down list.
Parameters for use in request transactions:
Cookie, Post, Query, URL, or HTTP Request Header
See About transaction identification. (see page 14)
XML
See Using XML to identify transactions (see page 120).
CA SiteMinder
Not recommended for transaction identification. (More commonly used for
user, user group, and session identification.) For information about using CA
SiteMinder with CA CEM, see the CA APM Configuration and Administration
Guide.
NTLM Authentication
See Defining identifiers for NTLM authentication (see page 44).
Basic Authentication
Not recommended for transaction identification.
x-wtg-info
For information about using CA APM Transaction Generator (WTG) with CA
CEM, see the CA APM Configuration and Administration Guide.
Plug-in
Select this type for use with an HTTP analyzer plug-in. For more information,
see Identifying transactions using the HTTP analyzer plug-in (see page 157).
Path
See Using path parameters to identify sessions (see page 44).


Flex Request Property
Select one of the following: messagetype, destination, source, operation,
contenttype, method, url. For more information, see Flex parameter types (see
page 19).
Flex HTTP Request Header
Select this type to specify Flex header information that occurs in the HTTP
request body. For more information, see Flex parameter types (see page 19).
Parameters for use in response transactions:
HTTP Response
Specify an HTTP response status code. For more information, see HTTP and
HTML Response parameter types (see page 17) and HTTP status codes (see
page 197)
Specify an HTTP Response parameter that occurs in the HTTP Response Header.
Specify either a literal or wildcard string.
HTML Response Tag
Specify the name of an HTML tag that occurs in the HTML Response body.
Plug-in HTTP Response
Select this type for use with an HTTP analyzer plug-in. For more information,
see Identifying transactions using the HTTP analyzer plug-in (see page 157).
Flex Response Property
Select either messageType or destination. For more information, see Flex
parameter types (see page 19).
3. Type in the parameter name.
If you want to add a wildcard to the parameter name, see Wildcarding parameter
names (see page 119).
4. Select an Action to apply to the parameter.
See Editing transaction components (see page 116) for a description of Action
types.
5. Click Save.
The new parameter is added to the transaction.
About defining defects


To delete a parameter:
1. Click on the parameter name in the Identification page. (To access the Identification
page, click a component in the Components list, see Editing transactions (see
page 113).)
A parameter detail page appears.
2. Click Delete to remove the parameter from the transaction definition.
About defining defects
Transactions are defective when they fail to meet quality standards. You can specify
these quality standards at business transaction, transaction or component levels. There
are two main types of defects:
Behavioral defects result from the behavior of a transaction failing to meet
specifications. Examples are:
Slow transaction time
Fast transaction time
Low throughput
Incomplete transactions
Response defects result from the response of a transaction failing to meet
specifications. Examples are:
HTTP response codes (for example, HTTP 500-599 errors)
Unauthorized access
Content analysis defects
Missing response defects
Response header defects
Defects are reported per transaction.
Defining business transaction defects


The best way to define defect conditions for business transactions is based on past
experience, as well as knowledge of your system and your application. After promoting
transaction recordings to transaction definitions, monitor the user activity for a week.
After that time, you can set up the defect conditions based on the measurements during
that observation period.
The system always calculates a baseline value for every business transaction based on
the monitored traffic. At any time, a number of defect conditions for business
transactions can be set automatically from the baseline. You can also exclude some
defect definitions from being updated from the baseline by locking them with a specific
condition.
Locate business transaction defect conditions
Follow these steps:
1. Select Administration > Specifications.
2. Select the name of the business service (for example, Avitek Financial).
3. Select the name of the business transaction (for example, Web).
The defect condition list appears, based on the selections you made.
Modify a Defect Type Condition
Follow these steps:
1. Locate the defect condition you want to modify. (See Locate Business Transaction
Defect Conditions (see page 125).)
2. Click on the Defect Name (for example, Slow Time) or the Condition (for example,
Transaction Time > 5.000s) and modify the condition as needed.
3. Click Save.


Lock or Unlock a Defect Type Condition
Lock a Defect Type Condition
Follow these steps:
To lock a defect type condition:
1. Locate the defect condition you want to lock. (See "To locate business transaction
defect conditions," above.)
2. Click the check box to the left of the defect.
3. Click Lock.
Note: The lock takes effect immediately.
Unlock a Defect Type Condition
Follow these steps:
1. Locate the defect condition you want to unlock. (See "To locate business
transaction defect conditions," above.)
2. Click on the Defect Name (for example, Slow Time) or the Condition (for example,
Transaction Time > 5.000s).
3. Clear the Locked check box.
4. Click Save.
Set the baseline for a defect condition
Follow these steps:
3. In the Defect Type pull-down list, select the defect type (for example, Slow Time).
The baseline can be set only on these defect types:
Slow Time
Fast Time
High Throughput
Low Throughput
Large Size
Small Size
HTTP Status Code
Defining transaction defects


Missing Transaction/Component
Content Error
Missing Response
Partial Response
HTTP Response Header Parameter
4. Click Search.
The defect condition list appears, based on the selections you made.
When you search and find one of the defect types that allow you to set the
baseline, the Set condition value to baseline button appears.
5. Click the check box to the left of the defect.
6. Click the Set condition value to baseline button.
A confirmation message appears, warning you that setting the baseline means that
the baseline replaces the current condition value.
7. Click OK to set the baseline or Cancel to exit without setting the baseline.
Defining transaction defects
To edit the transaction defect definitions:
2. Select the name of the business service (for example, Siebel Call Center).
3. Select the name of the business transaction (for example, Login).
4. Select the name of the transaction (for example, Execute Login).
5. Select the Transaction Specifications page.
This table below lists typical defects.
You can enable or disable monitoring of transaction defect types from this page.
6. To change the default values, click on a transaction defect name and then change
the default values such as the name, condition, and impact level.
7. Click Save.
These are typical defects:

Defect Name Default Enabled Default Limits Impact Level
Slow Time No Transaction time > 5s Medium (Default)
Defining component defects


Fast Time No Transaction time < .05s Medium (Default)
High
Throughput
No Throughput > 100kB/s Medium (Default)
Low
Throughput
No Throughput < 1kB/s Medium (Default)
Large Size No Transaction size > 100
kB
Medium (Default)
Small Size No Transaction size < .1kB Medium (Default)
Missing
Component
Yes Component timeout =
10s
Medium (Default)

For the most part, CA CEM observes and creates defects based on HTTP requests.
However, the component specification features is an exception because it allows defect
identification based on HTTP responses in the transaction.
These conditions can be used to identify response defects:
HTTP response code is any of If the specified HTTP status codes are contained in
a response header, then a defect is created.
For example, a defect could be created by this status-line: HTTP/1.1 405 Method
Not Allowed
Content contains If the response body contains the specified text, then a defect
is created.
For example, a defect could be created if this text is found in the message body: <td
class="header">Error - Single Sign-On</td>
Even if multiple content errors are present in a single response body, only one
defect is created for that response.
HTTP response header parameter If the specified header contains this text, then
a defect is created.
For example, a defect could be created if this message header appears in the
response: Server: Apache/1.3.6 (Unix)
To edit the transaction component definitions:
2. Select the name of the business service (for example, Siebel Call Center).
4. Select the name of the transaction (for example, Execute Login).


5. Select the Component Specifications page.
The table below lists typical defects.
For a list of code numbers and meanings, see HTTP status codes. (see page 197)
You can enable or disable monitoring of component defect types from this page.
The content error and HTTP response header parameter conditions are case
sensitive.
6. To change the default values, click on a component defect name and then change
the default values such as the name, condition, and impact level.
7. Click Save.
Changes to the defect specifications are saved.
This table lists typical defects.

Defect Type Default
Enabled
Condition Impact
Level
Unauthorized Access Yes Component Response is any of
401, 403, 407
Medium
(Default)
Client Request Error Yes Component Response is any of
400, 402, 404-406, 408-499
Medium
(Default)
Server Response Error Yes Component Response is any of
500-599
Medium
(Default)
Content Error No Component contains
<B>Error</B>
Medium
(Default)
Missing Response Yes Component Timeout = 60.000s Medium
(Default)
Partial Response Yes Component Timeout = 60.000s Medium
(Default)
Parameter
No HTTP Header Parameter
<Name> contains <Value>
Medium
(Default)
Viewing access policies for business services


About the HTTP Response Header Parameter
The value for the HTTP Header Parameter can be a partial match. For example, a portion
of an IP address is sufficient to create a defect for any Location header that contains the
string "192.168.42".

Similarly, "HTTP Response Header Server contains Apache" recognizes the response
header "Server: Apache/1.3.6 (Unix)."
Viewing access policies for business services
If your organization has deployed CA Embedded Entitlements Manager (EEM), you can
use access policies to control which security groups have access to a business service
and its associated data.
A security group is a grouping of users created for the CA EEM APM application. In CA
EEM, security groups are called application groups.
You can use either the CEM console (as described here) or CA EEM (as described in the
CA APM Security Guide) to create access policies that give security groups access to
business services. However, if you want to give a particular user (as opposed to a
security group) access to a business service, you must use CA EEM.
Adding access policies for business services


When a business service is created, it might have access policies automatically
associated to it. Any access policy that includes all business services is automatically
associated with every new business service that is created.

In addition, the creator of a business service always has full access to it (read, write, and
read sensitive data).
To view the access policies associated with a business service:
2. Click the name of the business service.
3. Click Access Policies.

The Access Policies page lists the policies associated with the business service.
If you have write or all actions permission for Access Policy - "Access Policy" in CA
EEM, the (business service) policy name appears as a link for accessing the policys
update page.
You can create additional access policies for a business service.
For example, you might create access policies so that only the global administrator of
the CA CEM application and members of the HR department can access a business
service. Furthermore, you might specify that global administrator and the HR
administrators have full access to the business service, but that HR analysts can only
read the business service, that is, view the graphs and reports associated with that
business service in the CA CEM tab.


When a business service is created, it has some access policies automatically created for
it. For more information about these access policies, see the CA APM Configuration and
Administration Guide and the CA APM Security Guide. However, you can create new
access policies for a specific business service or add a specific business service to an
existing access policy.
The procedure below describes how to create a new access policy for one or more
business services. If the access that you want already exists for another business service,
you do not need to create a new policy; instead, you add the business service to the
existing policy. See To add a business service to an existing access policy, below.
To create an access policy for a business service:
1. Select Security > Access Policies.
2. Click New.
3. Complete the fields on the New Access Policy page and click Save.
The Access Policies page lists the policies associated with the business service.

The fields in the New Access Policy page are described here.
Access Policy Name
Give a meaningful name to the policy.
Description
Add a descriptive comment.


Policy Option
Choose to create a policy to grant actions or deny actions for the business service.
For example, you may want to explicitly prevent junior analysts from viewing a
particular HR business service.
If there is a conflict between grant and deny, the deny policy takes precedence.
Enabled
Enable a policy if you want it to be in effect.
Disable a policy if you dont want to use it now, but might want to use in the future.
Delete policies that you dont want to use again.
Write
Select this to allow the security group members to view, edit, and delete the
business service and all its child objects (business transactions, transactions,
components, and so on) from the Business Service tab.
Users who do not have access to at least one business service, do not see the
Business Service tab.
Read
Select this to allow the security group members to view the graphs and reports
associated with that business service in the CEM tab.
Read sensitive data
Select this to allow the security group members to see the Host, URL path, TCP port,
cookies, and HTTP headers associated with a defect. These appear on the CEM >
Incident Management > Defect details page.
If the Capture Comprehensive Defect Details check box (on the Setup > Domain
page) is selected, then query and post parameters and request and response body
information for a defect can also appear on the Defect details page. For more
information, see the CA APM Security Guide for information.
Use this option with the read check box. The read action is required to access the
defect details page.
Business Services
Select Choose and move the business services for the policy to the Selected column.
Security Groups
Select Choose and move the security groups for the policy to the Selected column.
The security groups shown here correspond to CA APM application-specific user
groups in EEM. EEM global user groups cannot be selected in CA CEM.
Use EEM to view or modify the security groups. See the CA APM Security Guide for
information about using EEM. Security groups cannot be managed from the CEM
console.
Monitoring transactions


To add a business service to an existing access policy:
1. Select Security > Access Policies.
2. Select the access policy and click Update.
The Update Access Policy page appears.
3. Under Business Services, move the new business service to the Selected column.
4. Click Save.
Transaction definitions are used not only to identify transactions and identify users, but
also to monitor transactions for defects. After you have created transaction definitions,
you must enable the definitions. Then synchronize the TIM monitors and agents. After
being synchronized, the TIM monitors and agents use the transaction definitions to
analyze current traffic.
Enabling transaction definitions
Before monitoring transactions, the transaction definitions must be enabled.
Note: If you enable a response-based transaction, the associated request-based
transaction is also enabled. Also, you cannot enable a response-based transaction if the
response parameter is not enabled. If you disable a request-based transaction, CA CEM
also disables any response-based transactions that extend from that request-based
transaction.
To enable transaction definitions:
1. Select Administration > Business Services. Select the name of the business service
you created.
2. Select one or more of the check boxes in front of the transaction definitions you
want to enable.
Tip: Start small!
3. Click Enable to enable the transaction definition and prepare for transaction
monitoring.


Enabling transaction monitoring
After the transaction definitions are enabled, you are ready to begin monitoring real
user transactions.
To enable transaction monitoring:
2. Make sure that the TIMs you want to update are enabled. Select the check box and
click Enable if you need to enable a TIM.
Synchronizing to TIMs, agents, WebView, and Workstation
After you have created or edited transaction definitions, you must use the synchronize
function to push the updated definitions to the enabled TIMs and the agents.
Changes you make such as adding, deleting, and renaming business services and
business transactions are not reflected in the Workstation or WebView Investigator
trees until you synchronize the monitors and the agents generate metrics for the
business services.
To synchronize:
2. To push the new transaction definitions to the TIMs, select the check boxes for
those Monitors and click Enable if they are not already enabled.
3. Click Synchronize All Monitors to push the updated transaction definitions to all
enabled TIMs on your network and to the agents.
The TIMs and agents immediately start monitoring the transactions that you have
defined and enabled.
Also, after the agents have sent metrics to the Enterprise Manager, the Investigator
tree shows any changes you made to the business services or transactions from the
CA CEM UI.


Chapter 7: Managing your transactions

Once you have recorded your sample transactions and modified them to create
generalized definitions, then you need to verify and maintain them.
These are the general tasks for verifying and managing your transaction definitions.
About reviewing your transactions (see page 137)
Verifying transactions with CA CEM performance reports (see page 138)
Troubleshooting tips for transactions (see page 139)
Managing transaction settings with CA CEM (see page 144)
Managing transaction settings with bulk editing (see page 148)
Exporting and importing business transaction definitions (see page 151)
Moving business transactions between business services (see page 152)
Managing transaction definitions (see page 153)
Replacing existing business transaction definitions (see page 156)
About reviewing your transactions
CA CEM communicates results in a number of ways and in various report formats:
Service Level Management Transaction SLA, User SLA, Correlational SLA,
Transaction Trend, User Trend, and Business Value. These historical management
reports provide Top 10, continuous improvement, and SLA reporting information
for IT and business professionals. tasked with managing process improvement and
user transaction quality.
Incident Management Incidents, Impact Leaders, Defects, and Transaction Trace
Sessions. These real-time reports alert IT to user-affecting incidents, identify user
defects before they become incidents, and provide detailed information about the
scope, severity, priority, and user impact of transaction defects.
Performance Reports Business Services, Business Transactions, User Groups, and
Users. These historical reports provide status on the volume, performance, success,
and failure of user transactions.
Quality Reports Business Services, Business Transactions, User Groups, and
Users. These historical reports apply proven quality management techniques to
provide status on the quality of the business services that are used to deliver user
transactions.
Verifying transactions with CA CEM performance reports


Analysis Graphs Success Rate, Time, Throughput, Size, Volume, Count, Yield,
Defects, and Session Usage. These historical reports provide detailed graphs and
tables to support the results displayed in other CA CEM views. Proven quality-focus
data representation techniques such as Pareto graphs, control charts, and time
series histograms are displayed here for in-depth data analysis.
My Reports Your own list of scheduled, on demand, and license compliance
reports.
Verifying transactions with CA CEM performance reports
Your transaction definitions can be verified in a number of ways. One of the easiest
ways is to generate a performance report for a specified time period.
Note: First let CA CEM run for at least two hours so that you can collect enough data.
To generate a Performance Report:
1. Select CEM, Performance Reports.
2. From the Application list, select a business application.
3. From the Business Service list, select a business service.
4. From the Time Frame list, select the time frame (for example, Current Year).
5. Click Refresh to produce a report.
Note: Results from the previous hour are available 10 minutes after the current
hour.
6. Verify that the expected business service appears.
If not, this means that the transaction definitions for the business service have not
been identified. Verify that the transactions and business transactions are enabled
for monitoring.
See Editing transactions (see page 113) for more information.
Troubleshooting tips for transactions


7. Verify that the expected business transactions appear in the list.
If not, this means that the transaction definitions have not been identified. Verify
that your transaction definition parameters are set up to identify user transactions
correctly. See Editing transaction components (see page 116) for more information.
8. Click the business transaction name. Ensure that the expected transaction appear.
If you are not able to click on the business transaction name, that means that
Collect Transaction Statistics has not been activated (Business Services > Business
Transactions > General).
Important: The Collect Transaction Statistics check box is not a requirement for reports.
It is meant to be used sparingly and temporarily. Use the check box in cases where a
business transaction has more than one transaction and further investigation is required
to determine which transaction is causing a delay. It does not provide any additional
information if the business transaction has only one transaction under it.
Note: Transaction monitoring must be enabled to generate reports. See Monitoring
transactions (see page 134) for information about enabling transaction monitoring.
If your reports do not show the transactions that you expect, following are some
troubleshooting hints.
Transaction troubleshooting
Transactions were being recognized but suddenly stopped (see page 140)
Observe the transactions being monitored by the TIM (see page 140)
Too many missing response defects (see page 142)
Problems with transactions that contain path parameters (see page 143)
Troubleshooting Flex transactions (see page 143)



Transactions were being recognized but suddenly stopped
Has your web application changed? If transactions were being recognized and reported
successfully and suddenly stop, consider if any changes have been made to your web
application.
If your application changes or if you move a non-cacheable-identifying component
repository, then the transaction needs to be re-recorded or at least modified to ensure
that CA CEM can identify the transaction again.
(Moving a cacheable component, such as a cached image repository is not a problem
because cacheable components cant be identifying.)
Observe the transactions being monitored by the TIM
If CA CEM is not recognizing transactions, you can use the TIM Transaction Inspection
page to view business transactions that the TIM is identifying.
If the TIM is identifying transactions correctly, then you know that the transactions you
defined are getting sent to the TIM.


To view transactions that the TIM is identifying:
1. Access the TIM System Setup page. (See the CA APM Configuration and
Administration Guide for information about accessing the System Setup pages for
the TIM.)
2. Click View TIM Transaction Inspection.
The TIM Transaction Inspection page appears.

3. Check the filters you want and click Set Filter.
If the client is behind a proxy server, set its browser language to distinguish its
traffic. (If the client is behind a proxy server, the TIM recognizes the proxy servers
address and not the client's. Even if you know the proxy servers IP address, there
might be a lot of traffic from other users going through the proxy.)
If you select all filters as shown, then both defective transactions from any client
where the browser language setting matches en_us, af* and defective transactions
from 192.168.164.102 (regardless of browser setting) are logged.
If you clear all filters, then all transactions (defective and not defective) from all
clients and browsers are logged.


4. Click Start.
5. Click Stop when you have finished observing transactions.
Important: Because this feature creates a lot of log files on the TIM
(/etc/wily/cem/tim/logs/inspection), dont leave it on any longer than necessary.
Too many missing response defects
If there are more missing response defects than anticipated, try the following:
Increase the component time-out for missing transactions. Too short a component
time-out can result in slow time defects being reported as both slow time defects
and missing response defects.
(For general information about setting the component time-out, see Defining
transaction defects (see page 127).)
If you are using regular expressions rather than simple matching to identify
transaction components, verify that the regular expressions are correct. Small
errors in regular expressions often result in false missing response defects.
(For general information about matching transaction components, see Editing
transaction components (see page 116).)
Enable the TIM setting IgnoreOnlyRequestErrorComponents. This setting was added
to address a particular situation where a web application receives empty request
packets by design. The TIMs default behavior is to interpret empty packets as
corrupt and to report a missing response defect. When the
IgnoreOnlyRequestErrorComponents is 1, empty and corrupt request packets are
ignored and are not reported as missing response defects.
If IgnoreOnlyRequestErrorComponents is 1 and empty or corrupt response packets
are found, an entry is placed in the TIM log. For example,
Tue Feb 28 12:03:22 2011 19136 Trace: ignoring request on
connection ([172.16.214.7]:2479->[172.18.10.20]:443) due to - bad
start line
To edit TIM settings, select TIM > Configure TIM Settings on the System Setup page.
A TIM setting is available to handle empty (and corrupt) request packets without
creating missing response defects. When the IgnoreOnlyRequestErrorComponents
is 1, empty and corrupt request packets are ignored and are not reported as missing
response defects.


Problems with transactions that contain path parameters
If the URL path contains path parameters, confirm the following:
The path parameter delimiter is correctly set. See Setting the global delimiter for
path parameters (see page 46).
In the identifying component, the URL path pattern for a matched URL terminates
in a wildcard. See Editing transaction components (see page 116).
Troubleshooting response-based transactions
Symptom:
I am trying to discover transactions based on an HTML response tag, but I do not see
any results.
Solution:
Verify that the content type is correct. If you are looking for response-based
transactions, the content type must include text/html or text/*.
Troubleshooting Flex transactions
Symptom:
I am trying to discover Flex transactions, but I am not getting any results.
Solution:
Verify that the content type is correct. If you are looking for Flex transactions, the
content type must include application/xml or application/x-amf. For transaction
discovery only, you can specify application/x* also.

Managing transaction settings with CA CEM


To examine all your current transactions from a high level, you can view the Overview
page on the CEM console. This page also allows you to review transaction setting
details.
To manage transaction settings with CA CEM:
Select Administration > Overview.
The Overview page appears.
The Overview page shows current settings for:
transactions grouped by business service and business transaction
behavioral defect characteristics
SLA success criteria
You can click any of these settings to change values.
The advantage of the Overview page is the ability to compare transaction-related
settings side-by-side. This saves you the trouble of navigating up and down the
Administration > Business Services hierarchy for similar transactions.
Note: You might want to use the bulk editing feature as an alternative to this method of
modifying business service and transaction settings. See Managing transaction settings
with bulk editing (see page 148).
Modifying business service and transaction settings
The Overview page allows you to modify settings related to business services, business
transactions, and transactions, following the same general steps.
If you click on the business service, business transaction, transaction, or one of the SLA
values, you can modify inheritance and other global transaction settings.


For example, if you click on the Login business transaction, you can change inheritance
settings, or you can change other settings that affect all transactions related to this



To modify your transaction-related settings, follow these steps:
1. Select Administration, Overview.
2. Click on the name of the business service, business transaction, or transaction that
you want to change.
For example, if you clicked on the "Logged in" transaction, the related transaction
page appears, on the Components page.

3. Click on any of the settings to modify it.
4. Click Save to keep your changes or click on the Overview link to return without
saving your changes.
Comparing views: overview versus business services
You might notice that the transaction information is the same as you would see if you
clicked Administration, Business Services, Business Transactions, and then Transaction
for the transaction.
The business services tree helps you keep track of where you are.
Modifying behavioral defect settings
The Overview page allows you to modify settings related to behavioral defects,
following the same general steps.
If you click on one of the behavioral defect characteristics, you can specify whether or
not the characteristic is monitored or locked; you can also change the condition and
impact level.


For example, if you click on the value listed under Slow Time for the Avitek Financial
Services business service, Login transaction, you can change the transaction time.

To modify behavioral defect settings, follow these steps:
1. Select Administration > Overview.
2. Click on the behavioral defect value that you want to change:
Slow Time
Fast Time
High Throughput
Low Throughput
Large Size
Small Size
The related Specification page appears. For example, Specification: Low
Throughput.
Managing transaction settings with bulk editing


Modifying SLA success settings
The Overview page allows you to modify settings related to SLA success criteria,
following the same general steps.
To modify SLA success settings:
1. Select Administration > Overview.
2. Click on the SLA setting value that you want to change:
Success Rate SLA
Sigma SLA
Time SLA
The related Business Service, Business Transaction, or Transaction page appears, on
the General page.
Note: The page that appears depends on the setting that you select. For example, if
you click the Sigma SLA for the business service, then the Business Service page will
appear.
In some cases, you might need to make a global change to your transaction or user
settings. For example, perhaps your company is involved in a Six Sigma effort and wants
to raise the bar on SLAs for several transactions. Perhaps all transactions currently have
a Sigma SLA setting of 4.00, and the new company goal is to increase the SLA to a Sigma
setting of 5.00.
Bulk editing allows you to make widespread changes for:
business service and transaction settings
transaction and component defect conditions
user settings


Modifying business transaction settings
The Business Transaction Search page allows you to modify business services and
transactions on a large scale.
To modify business transaction settings:
1. Select Administration > Business Services > Business Transaction Search.
The search options appear.
3. Type the name of the business transaction if you need to modify a specific business
transaction.
4. Select the Impact Level (for example, All).
5. Click Search.
The results of your search appear.
If a value is dimmed, you cannot modify the value. Set inheritance to No if you want
to change a value.
If Calculate Business Value is set to No, then you cannot modify Business Value.
6. Click the check box to the left of the business transaction that you want to change.
Or, if you want to change the entire list, click the top check box.
7. Select an item from the Set value of list:
Business Value
Calculate Business Value
Collect Transaction Statistics
Inherit Sigma SLA
Sigma SLA
Inherit Success Rate SLA
Success Rate SLA
Inherit Transaction Time SLA
Transaction Time SLA
A value text box or Yes|No list appears, depending on your choice.
8. Type a value, or select Yes or No, and click Set.


Modifying defect conditions
The Specifications page allows you to modify transaction and component defect
conditions on a large scale.
To modify defect conditions:
The search options appear.
A list of business transactions associated with the business service appears.
4. Select the Defect Type (for example, Slow Time).
5. Click Search.
If you selected a specific Defect Type, the Set condition value to text box appears.
You must select a Defect Type to cause the bulk editing features to appear. If you
select one of the behavioral defect types (Slow/Fast Time, High/Low Throughput,
Large/Small Size), then you also have the ability to set the baseline.
6. Click the check box to the left of the defect condition that you want to modify. Or, if
you want to modify the entire list, click the top check box.
7. Type a new value for the selected condition and click Set.
Tip: Optionally, you can type the Defect Name (for example, *throughput* for both
high and low throughput). However, if you use this search method, the bulk editing
features do not appear.
Modifying user settings
If you want to modify user groups on a large scale, see the CA APM Configuration and
Administration Guide.
Exporting and importing business transaction definitions


Exporting and importing business transaction definitions
There are situations where you might want to export one or more business transaction
definitions from one CA CEM system and import to another:
Example 1: You have created and verified a business transaction definition in your
test environment and want to move the transaction definition into your production
environment.
Example 2: There are problems with a particular business transaction definition in
your production environment. You move it to your test environment to diagnose
and correct the problem.
Business transactions can be moved by exporting them (to a ZIP file) and importing the
file into another environment.
To export business transaction definitions:
2. Select a business service and then one or more business transactions to export.
3. Click Export and save the file.
Note: If your business transaction contains file names with multibyte characters, you
must use WinZip 11.2 or later. Earlier versions of WinZip do not correctly show file
names within an export zip file when they contain multibyte characters. This is an
incompatibility between the java.util.zip classes and WinZip.
To import business transaction definitions:
2. Select the business service to which you want to add the business transaction
definition.
If the business service does not already exist, create it.
3. Click Import.
4. Browse to the ZIP file in the Import File field.
5. Click Import.
The business service and a confirmation message appear.
6. To start monitoring the imported business transactions, enable them (if they are
not already enabled) and synchronize monitors.
For information, see Enabling transaction monitoring (see page 135) and
Synchronizing to TIMs, agents, WebView, and Workstation (see page 135).
Moving business transactions between business services


Additional information about exporting and importing business transaction
definitions
Requirements for importing
To be imported, business transactions must have at least one identifying
transaction, one identifying component, one parameter, and the necessary defect
definitions.
Importing with the same name
If you import a business transaction definition with the same name as an existing
one, CA CEM appends the name of the new business transaction definition with a
number. For example, if you already have a business transaction definition named
Login, CA CEM names the new definition Login(2).
Importing enabled definitions
If monitoring is enabled for the exported business transaction definition, then it is
enabled for the imported definition. Monitoring does not begin until the monitors
are synchronized.
Importing and exporting response-based transactions
When you export response-based transactions, CA CEM includes any and all
associated request-based transactions.
You can export request-based transactions without exporting the
response-based transactions, if desired.
You cannot import response-based transactions only.
You can define a response-based transaction definition from an imported
request-based transaction definition, even if the request-based transaction was
created in CA APM before 9.5.
Moving business transactions between business services
Business services are containers for business transactions. There are times when you
might want to move business transactions to a different business service. For example
for an online shopping application, you might decide that a particular business
transaction should be in the Browsing business service instead of the Check-out
business service.
Managing transaction definitions


Only move business transactions between business services that have compatible
character encoding .
Moving transactions to another business service does not affect reports. All statistics
collected before the move are not changed and remain under the old business
transaction. After the move, the new statistics will be under the new business service.
The following restrictions apply to moving business transactions:
If you move a request-based business transaction to another business service, CA
CEM moves all response-based business transactions that extend from that
request-based business transaction also.
If you move a response-based transaction to a different business service, CA CEM
moves the corresponding request-based transaction also.
To move business transaction definitions to a different business service:
2. Click the name of the business service that contains the business transaction
definitions that you want to move.
The list of business transaction definitions in the business service appears.
3. Select the business transaction definitions that you want to move.
4. In the Move to field, select a business service and click Move.
The selected business transaction definitions are moved to the different business
service.
You can manage your transaction definitions to optimize the performance of the CA
CEM system. You should know which business transactions have been run recently and
which are potentially stale. By eliminating redundant or stale transaction definitions,
you can improve the performance of CA CEM.
Using this feature, you can analyze the relevance and usage patterns for business
transactions. You do this by exporting data about your business transactions to a
comma separated values (CSV) file.
You can use these data:
to identify unused transaction definitions (to improve performance).
when troubleshooting transactions.
to chart transaction statistics.


These values are written to the file:
Business Service
Business Transaction
Total Captures
Last Capture Date
Created By
Created On
Last Modified By
Last Modified On
Enabled/Disabled
Deleted/Active
The Total Captures and Last Capture Date are accurate up to the last complete hour.
The total captures are counted from when the transaction was first defined. Or, if the
transaction was defined before Wily CEM 4.5, then total captures are counted after the
upgrade from Wily CEM 4.5.
To create a CSV file containing business transaction data:
2. Select one or more business services for which you want transaction statistics.
3. Click Save to CSV.

4. Save or open the CSV file.
Microsoft Excel is a suitable application for viewing and sorting this data.
Note: If your business transaction contains file names with multibyte characters, the
name does not appear correctly in the CSV file. This is because the default codepage in
Windows does not support UTF-8.


Usage example: TIM performance
Open the CSV file and review the last capture dates for enabled business transactions.
Are there stale transactions, business transactions that have not been captured for a
long time? If so, consider whether they can be disabled or deleted.
Including business transactions that will never occur puts a needless burden on the TIM.
It can negatively affect TIM performance.
Usage example: Troubleshooting
Unexpectedly, a transaction has stopped being monitored. Review the CSV file. Has the
web application being monitored changed? Or, has the transaction been changed, and if
so, by whom? Does the change correlate with the last capture date? Is another
transaction being captured instead? Does some other transaction have a creation date
that correlates with the last capture date?
To replace a transaction with a newly recorded one, see Replacing existing business
transaction definitions (see page 156).
Usage example: Transaction statistics
Use the data in the CSV file to create your own charts and reports about transactions.
For example, this chart, created in a spreadsheet application, plots Total Captures
against Business Transaction.

Replacing existing business transaction definitions


Replacing existing business transaction definitions
You can replace an existing monitored business transaction with a newly recorded
business transaction. The new business transaction can have a different definition and
different components, yet maintain the historical performance and statistics from the
original business transaction.
Note: You cannot replace an existing response-based transaction or a request-based
transaction that has associated response-based transactions with a newly recorded
transaction.
Follow these steps:
1. Go to the recording session and select the correct business service from the
Promote To list.
2. From the Show list, select Only Identifying.
3. Select the new transaction (or transactions) that you want to substitute for the old
4. For that identifying transaction, select the business transaction from the Replace
Existing Business Transaction list.
If a business service does not have any business transactions, the list is empty.
(If you do not select a business transaction from the list, the selected transaction
can be promoted as a new transaction. For information about promoting as new,
see Promoting transaction signatures to definitions (see page 110) and Promoting
transactions to definitions (see page 88).)
5. Click Promote to replace the existing definition with the new recording signature.
If the promotion is successful, the business service page appears.
The non-identifying transactions are also replaced.
A replaced business transaction is disabled.
6. Go to the business transaction:
a. Edit it (for example, specify new identifying parameters).
b. Set the business transaction specifications (these specifications are reset to
default values when the business transaction is replaced).
c. Re-enable it for monitoring.


Chapter 8: Identifying transactions using
the HTTP analyzer plug-in

The HTTP analyzer plug-in feature provides the capability to customize the way CA CEM
identifies transactions.
You can use the HTTP analyzer plug-in API as an extension to CA CEM, to recognize
transactions with Java code. You can use the CA CEM SDK for the sample plug-in, which
uses the API, to create your own Java class.
Note: The primary audience for this chapter of the CA APM Transaction Definition Guide
is Java developers who are designing and testing their own Java code for the HTTP
analyzer plug-in. The secondary audience is the CA CEM administrator or the person
responsible for CA CEM transaction definitions (who might not actually write the Java
code themselves).
About the HTTP analyzer plug-in (see page 158)
HTTP analyzer plug-in overview (see page 158)
About using the HTTP analyzer plug-in (see page 160)
Process for deploying the HTTP analyzer plug-in (see page 163)
Downloading the HTTP analyzer plug-in SDK (see page 164)
Using the SDK to create an HTTP analyzer plug-in (see page 165)
Configuring an HTTP analyzer plug-in (see page 166)
Modifying an HTTP analyzer plug-in (see page 168)
Enabling an HTTP analyzer plug-in (see page 170)
Enabling and disabling TIM monitors (see page 170)
Testing an HTTP analyzer plug-in (see page 170)
Verifying an HTTP analyzer plug-in in the CEM console (see page 173)
Verifying an HTTP analyzer plug-in on the TIM (see page 174)
Disabling an HTTP analyzer plug-in (see page 177)
Troubleshooting the HTTP analyzer plug-in SDK (see page 177)
About the HTTP analyzer plug-in


About the HTTP analyzer plug-in
In some cases, you might need to customize the way CA CEM recognizes a subset of
your transactions. The HTTP analyzer plug-in allows you to extend transaction
identification beyond the usual limits of CA CEM.
The CA CEM TIM monitors and identifies transactions by observing network traffic and
then comparing that network traffic to transaction definitions provided to the TIM by
the Enterprise Manager. Those transaction definitions include parameter definitions,
which are used to compare and identify HTTP component parameters in the observed
transactions.
You can write your own HTTP analyzer plug-in that receives HTTP requests and adds
parameters to the TIMs internal parameter list. These parameters can then be used to
identify transactions in the same way as other CA CEM parameters.
For every HTTP component, the TIM builds an internal parameter list (for example,
cookie and post parameters) and then matches these parameters against transaction
definitions. A plug-in can add its own parameters to the same internal parameter list.
You can use the plug-in to decode proprietary data formats, including applications with
binary data. You can also use the plug-in to extract embedded identifying data in XML
messages by parsing and extracting the identifying parameters.
Note: The HTTP analyzer plug-in is not supported with CEMTracer.
HTTP analyzer plug-in overview
The HTTP analyzer plug-in includes a software development kit (SDK). The SDK includes
documentation, source code for a sample plug-in, and a Java interface that defines the
plug-in API.
The API defines plug-in methods that the TIM calls with HTTP component request and
response data. These methods return parameters (name/value pairs), which the TIM
adds to its internal parameter list and then matches against transaction definitions.
Plug-in methods can also return log messages, which appear in the TIM log.
CA CEM uses a parameter type of plug-in for identifying transactions as defined in an
HTTP analyzer plug-in. All parameters generated by a plug-in are automatically assigned
the type of plug-in.
The plug-in parameter type can be used to identify:
transactions using the component identification parameter
users to identify the correct user
HTTP analyzer plug-in overview


sessions to identify the correct session
user groups to identify the correct user group
When the TIM monitors an HTTP component request and response, it passes the
request and response to the plug-in. The TIM adds any parameters returned by the
plug-in to its internal parameter list with the type of plug-in.
The HTTP analyzer plug-in feature allows you to filter what the TIM passes to the
plug-in. You can filter by server IP address range, port number, and URL filter.
The plug-in parameters appear in the HTTP information section of the CA CEM defects.
Multiple plug-ins can be enabled at one time, up to a maximum of 10. If the request
matches that plug-in's filter, the TIM passes each HTTP component request to every
enabled plug-in. The TIM uses the parameters from all plug-ins.
The CemPluginApiV2 interface includes these methods, which the TIM calls once:
initialize called when the TIM enables the plug-in
terminate called when the TIM disables the plug-in, or when the plug-in throws
an exception
The TIM calls these methods, in the following order, for each HTTP component:
newComponent called once at the beginning of each HTTP component
requestHeader called for each HTTP request header
endRequestHeader called once at the end of the HTTP request header
requestBody called one or more times if the request has a body
endRequest called once at the end of the HTTP request, regardless of whether
the component has a body; called only if the request completes normally
responseStart called at the start of the HTTP response
responseHeader called for each HTTP response header
endResponseHeader called once at the end of the HTTP response header
responseBody called one or more times if the response has a body
endResponse called once at the end of the HTTP response, regardless of whether
the component has a body; called only if the response completes normally
endComponent called once at the end of the component
About using the HTTP analyzer plug-in


The preceding methods (not including initialize or terminate) can return either null or a
CemPluginOutput instance. The CemPluginOutput class has two fields, either (or both) of
which can be null:
a parameter array supplied by the plug-in to be added to the TIMs parameter list
(name/value pairsthat is, what to watch for)
log messages to be written to the TIM log (that is, what just happened)
Note: Often multiple HTTP components are in progress at the same time (in other
words, multiple transaction components in various states). The component ID is passed
to each component method so the plug-in can handle multiple components at the same
time.
Before you begin to write your HTTP analyzer plug-in, you need to familiarize yourself
with important cautions and best practices for its use.
Important: The HTTP analyzer plug-in is a powerful addition to the CA CEM system. As
such, it has the potential to interfere with normal operations of CA CEM. It is important
to adhere to the cautions and to maintain best practices.
See also Troubleshooting the HTTP analyzer plug-in SDK (see page 177).
Important cautions when deploying the HTTP analyzer plug-in (see page 161)
Best practices when deploying the HTTP analyzer plug-in (see page 161)
Deploying multiple HTTP analyzer plug-ins (see page 162)
Handling XML data using the HTTP analyzer plug-in (see page 162)


Important cautions when deploying the HTTP analyzer plug-in
Review this list of cautions before you design your plug-in:
WARNING! The HTTP analyzer plug-ins run as root on the TIM machine, which means
that all protections are bypassed. As such, it is possible to corrupt CA CEM, the TIM, and
the operating system.
WARNING! Be aware of the TIM as a secure machine; you should control who deploys
plug-ins in this secure environment.
The TIM is blocked while a plug-in is executing. This means that process-intensive
plug-ins have the ability to prevent normal monitoring, cause the TIM to drop
packets, block recording, and delay statistics collection.
Do not modify, delete, or add any operating system files or otherwise reconfigure
the operating system with your plug-in.
Do not use any operating system facilities that might change the state of the
process. Plug-ins run in the TIM process and should not change the state of the
process.
Do not call System.exit() because this exits the TIM (not only your plug-in).
Do not read from standard input (System.in) or write to standard output
(System.out). (Use the log message feature instead.)
Do not attempt to use any files that are already open (by the TIM).
Do not place a wait in your plug-in code. The HTTP analyzer plug-in does not have a
time-out feature. Ensure that your plug-in cannot hang the TIM. For example, do
not wait for an external event or put a sleep call in your code.
Free up any per-component resources in the endComponent method.
Free up any other plug-in resources in the terminate method.
Best practices when deploying the HTTP analyzer plug-in
Review these best practices and general tips for the plug-in:
It is best to start with a small transaction population and in a test CA CEM
environment. Then test the performance load before migrating to a production
environment.
The plug-in is an early adopter feature intended for outlying transaction
identification, not for all transaction identification. If you want to create a plug-in
for all your transactions, contact CA Technologies Professional Services.
Create plug-ins that use the message log to provide feedback as to what is
happening. Keep in mind, however, that log messages take time, so minimize their
use in production.


Log messages for Java errors, and for general warning and error conditions.
Buffer the entire request body if necessary and if it is small; however, be aware of
the performance impact if the body is large.
If you want to use a plug-in but do not want response data passed to the plug-in for
performance reasons, use an earlier version of the plug-in. The plug-in SDK lists
information about using an earlier version.
Deploying multiple HTTP analyzer plug-ins
You can deploy multiple HTTP analyzer plug-ins if you have more than one subset of
transactions that cannot otherwise be recognized via standard TIM monitoring. You
follow the same steps as for one plug-in to deploy additional plug-ins.
Be aware of the following for multiple HTTP analyzer plug-ins:
Multiple plug-ins can be useful when they have different filters or are written by
independent groups.
Every plug-in takes away processing time from the TIM. Weigh performance impact
versus other business drivers that might suggest the need for multiple plug-ins.
You might want to combine multiple plug-ins into a single plug-in (JAR file) for
performance reasons.
A maximum of 10 plug-ins can be enabled at the same time.
CA CEM does not distinguish which plug-in generated any particular parameter.
To distinguish which plug-in generated a parameter, you can prefix the parameter
name with the plug-in name (for example, pluginName_paramName).
Handling XML data using the HTTP analyzer plug-in
If you are writing a plug-in to handle XML data, you should be aware of the following:
The TIM passes the HTTP request body data to the plug-in unaltered.
The plug-in is responsible for determining the encoding of the input data, based on
(1) the "encoding" attribute in the XML declaration (if there is one), (2) the
"charset" attribute of the "Content-Type" field in the HTTP request header, (3) a
Byte Order Mark in the data, and (4) any knowledge you have about your
applications.
The plug-in is responsible for performing any necessary character encoding
conversion (normally the XML parser takes care of this); the plug-in returns
parameter names and values as Java strings.
Process for deploying the HTTP analyzer plug-in


Process for deploying the HTTP analyzer plug-in
These tasks describe how to extend transaction identification using a plug-in:
1. Get the SDK with Javadoc and sample plug-in code (see page 164).
2. Learn about the SDK and read the Javadoc to create your plug-in (see page 165).
3. Configure the plug-in (see page 166).
4. Modify the plug-in (see page 168).
5. Enable the plug-in (see page 170).
6. Test the plug-in (see page 170).
7. Verify the plug-in in the CEM console (see page 173) and on the TIM (see page 174).
8. Disable the plug-in. (see page 177)
Downloading the HTTP analyzer plug-in SDK


Downloading the HTTP analyzer plug-in SDK
If you decide that you need to extend transaction identification for a subset of your
transactions, you need to download the SDK to get started.
To get the SDK follow these instructions:
Important! The cem-java-plugin-sdk.zip file shipped with a previous version of CA CEM
should be replaced with the new file.
the TIM.)

2. Click Download the Java plug-in SDK.
3. Download the cem-java-plugin-sdk.zip file to your local PC.
4. Unzip the file, maintaining the existing directory structure (for example, if you are
using WinZip, select the Use folder names option).
Using the SDK to create an HTTP analyzer plug-in


5. Verify the following new directories after you unzip the file:
class directory the HTTP plug-in API itself
javadoc directory Java documentation for the API
sample2 directory SDK sample plug-in
6. Provide the SDK to the Java developer who will write your plug-in.
Using the SDK to create an HTTP analyzer plug-in
An experienced Java developer will be able to use the Javadoc and the sample plug-in
code to write a plug-in.
To get started with the HTTP analyzer plug-in SDK:
1. Double-click the Javadoc index.html.
The Javadoc provides information that the Java developer needs to get started.
2. Review the overview for information on the interface and the available methods
and classes.
3. Review the information about the plug-in run-time environment on the TIM, which
includes warnings and best practices. For more information about:
the interface, methods, and classes, see HTTP analyzer plug-in overview (see
page 158).
best practices, see Using the HTTP analyzer plug-in (see page 160).
testing, see Testing an HTTP analyzer plug-in (see page 170).
troubleshooting, see Troubleshooting the HTTP analyzer plug-in SDK (see
page 177).
4. Write a Java class that implements the interface (API) defined in the HTTP analyzer
plug-in SDK.
5. Compile your Java source code. For example, in the command line:
javac -classpath /<directory_path> /<directory_path>/CemJavaPlugin.java
6. Create a JAR file that includes the class file and any other required libraries. For
example, in the command line:
jar cf <your_jar_file>.jar *.class
Note: If you have more than one plug-in, give each JAR file a unique and meaningful
name.
The JAR file is your HTTP analyzer plug-in, which you install, configure, and enable
via the CEM console. See Configuring an HTTP analyzer plug-in (see page 166).
Configuring an HTTP analyzer plug-in


You need to configure the HTTP analyzer plug-in in the CEM console to specify which
transactions to monitor, and to deploy your plug-in JAR file to the TIMs.
About using filters to limit HTTP analyzer plug-in traffic
The IP address range, Port, and URL Path fields are used to filter traffic that the HTTP
analyzer plug-in needs to monitor.
If you enter a filter, then only the filtered HTTP components will be passed from the
TIM to the HTTP analyzer plug-in.
If you do not enter any filters at all, then all HTTP components will be passed from
the TIM to the HTTP analyzer plug-in.
The TIM calls the plug-in for an HTTP component if both of the following are true:
The servers IP address and port number match at least one of the configured
IP filters, or there are no configured IP filters.
AND
The request URL path matches the configured URL filter, or there is no
configured URL filter.
To configure your plug-in in the CEM console:
1. Select Setup > Plug-ins.
2. Select CA CEM HTTP Analyzer.
A list of the existing plug-ins appears.


3. Click New to configure your plug-in.
The new plug-in page appears.

4. Type the Name and Description of your plug-in.
5. (Optional) Set filters to limit HTTP analyzer plug-in traffic. See About using filters to
limit HTTP analyzer plug-in traffic (see page 166) for more information.
From and To IP Address
Enter the IP address range to filter the server address of the HTTP components
that this plug-in needs to monitor.
Only HTTP components that are from servers within the defined IP address
range are passed to the HTTP analyzer plug-in.
Port
If the plug-in should monitor HTTP components on a specific server port, enter
the port number. The default of 0 means monitor all ports.
Modifying an HTTP analyzer plug-in


URL Path
If the plug-in should monitor transactions that match a URL path pattern,
specify how to recognize the path:
Matches
Select this option to compare the URL path to a string or pattern. (You can
use one wildcard character and follow the same simple pattern matching
as elsewhere in CA CEM. See Editing transaction components (see
page 116) for more information.)
Matches regular expression
Select this option if you need to use regular expressions as an alternative
to combine similar URL paths. See Regular expressions in CA CEM (see
page 201) for more information.
Only HTTP components that match the defined pattern are passed to the HTTP
analyzer plug-in.
Note: This filter is ANDed with the IP Address and Port filters. See About using
filters to limit HTTP analyzer plug-in traffic (see page 166) for more information.
6. In the HTTP Analyzer JAR field, type the directory path and name of your plug-in JAR
file or click Browse to locate it.
Tip: If you have more than one plug-in, each JAR file should have a unique and
meaningful name.
7. Click Save.
When you click Save, CA CEM sends the JAR file to all the enabled TIMs. The new
plug-in appears in the HTTP analyzer plug-in list in a disabled state.
8. If you are ready to enable the plug-in, see Enabling an HTTP analyzer plug-in (see
page 170).
9. If you need to add another IP address filter or make other changes to the plug-in
configuration, see Modifying an HTTP analyzer plug-in (see page 168).
You can rename, add a filter, replace the plug-in JAR file, or otherwise modify the HTTP
analyzer plug-in after you have created it.
Note: If the plug-in is enabled, you cannot replace the JAR file.
To modify your plug-in:


3. Click the name of the plug-in you want to modify.
The plug-in page appears.
.
4. If you are ready to enable the plug-in now, select Enable HTTP analyzer plug-in.
5. If you want to add another IP address filter range, click New.
a. Enter the additional IP address range and port.
b. Click Save to add the new filter.
6. If you need to replace the plug-in JAR file, browse to find the new file and select
Overwrite existing file.
7. Click Save to keep your new settings.
Enabling an HTTP analyzer plug-in


Enabling an HTTP analyzer plug-in
You must enable the plug-in in the CEM console to start monitoring on the TIMs.
To enable your plug-in:
Important: When you click Enable, CA CEM immediately signals all the enabled TIMs to
begin using the plug-in to extend monitoring.
3. Select the plug-in from the list and click Enable.
Note: If you restart a TIM later, it runs any plug-in that was enabled before the
restart.
4. See Verifying an HTTP analyzer plug-in to verify the plug-in.
Enabling and disabling TIM monitors
As with most functions of CA CEM, you need to keep the TIMs in sync with the
Enterprise Managers. This is also true with the HTTP analyzer plug-in.
In relation to the HTTP analyzer plug-in:
When you restart or enable a TIM monitor, all enabled plug-ins are loaded and
active on that TIM.
When you disable a TIM monitor, all plug-ins are deleted from that TIM.
For more information on enabling and disabling TIM monitors, see Synchronizing to
TIMs, agents, WebView, and Workstation (see page 135).
Testing an HTTP analyzer plug-in
Once you have unit tested your plug-in, you can configure and test it in a controlled
environment.
To test your HTTP analyzer plug-in, you need to perform these tasks, which are
documented in this section:
Configure and enable the HTTP analyzer plug-in in the CEM console.
Verify that the plug-in is active on the TIM.
Configure the business application.


Create a business service.
Record a sample transaction.
Check the recorded transaction.
Promote the transaction.
Configure the components.
Enable the business transaction.
Synchronize monitors.
Generate traffic that causes the plug-in to generate parameters.
Review and verify the results.
Note: This section assumes that you have a reasonable understanding of CA CEM and
how it works. Several of the following steps provide cross-references to the related
documentation if you need more information.
To test the HTTP analyzer plug-in:
1. Configure your plug-in. See Configuring an HTTP analyzer plug-in (see page 166).
Tip: Work in a controlled test environment if at all possible.
2. Enable your plug-in. See Enabling an HTTP analyzer plug-in (see page 170).
3. Verify that your plug-in is active on the TIM. See Verifying on the TIM (see
page 174) (step 1 through step 3 ).
4. Create your test business application with the appropriate user, session, or user
group identifiers.
a. Select Administration > Business Applications.
b. Create a business application for the plug-in testing. See Defining a business
application (see page 28).
c. Select the type of parameter (session, user, or user group).
d. Click New to create a plug-in identification parameter.
e. Select the Type of Plug-in.


f. Type the Name of the identifier. The name must match the name that the
plug-in generates for:
Session name
Must match the session ID, using a literal or wildcard match.
User name
Must match the plug-in parameter name for user name.
User group
Name must match the plug-in parameter name for user group name.
g. Click Save to save the plug-in identifier. If you need to define more parameters,
repeat the steps.
Note: The behavior for plug-in parameters is the same as for other parameter
types. For example, if you create multiple identification parameters for a business
application, then they must all be present to identify.
5. Create your test business service.
a. Select Administration > Business Services.
b. Create a business service for the plug-in testing. See Defining business services
(see page 47).
6. Record a sample transaction that is related to your plug-in.
Tip: To make the test easier, do not also generate non-plug-in related transactions.
a. Select Administration > Recording Sessions.
b. Record a sample transaction for the plug-in testing. See Recording transaction
7. Verify that your plug-in parameters appear in the recording.
a. Click the Parameter Map link.
b. Look for the plug-in parameters that you expect to find in the recorded
transaction.
8. Promote and modify the transaction. See Defining transactions (see page 109).
9. Select the Business Transaction > Transaction > Component for the plug-in test.
a. Modify transaction components as needed. See Editing transaction
components (see page 116).
The URL Path parameter must match the URL Path as configured in the
plug-in.
Other parameters must match your plug-in code, to match the expected
components.
b. Add transaction components as needed. See Adding parameters (see
page 122).
Verifying an HTTP analyzer plug-in in the CEM console


10. Enable your business transaction.
a. Select Administration > Business Services.
b. Select your test business service.
c. Select the test business transaction and click Enable.
11. Synchronize monitors to notify all TIMs of the new transaction. See Enabling and
disabling TIM monitors (see page 170).
Note: If the associated plug-in is enabled, the TIMs immediately begin monitoring
your new test transaction using the plug-in.
12. If you have not yet enabled your plug-in, see Enabling an HTTP analyzer plug-in (see
page 170).
13. Begin generating transactions to test your plug-in.
Note: It is a good idea to monitor your new plug-in closely because it has the
potential to interfere with the TIMs normal operations. See Using the HTTP
analyzer plug-in (see page 160) and Troubleshooting the HTTP analyzer plug-in SDK
(see page 177).
14. Review the defects and incident reports to ensure that you get the results you
expect.
Tip: Generate both positive and negative test scenarios to validate your error
checking, logging, and program logic.
For more information, see Verifying an HTTP analyzer plug-in in the CEM console
(see page 173) and Verifying an HTTP analyzer plug-in on the TIM (see page 174)
Verifying an HTTP analyzer plug-in in the CEM console
Once you have enabled the HTTP analyzer plug-in, you should verify that it is working as
expected. You should verify in the CEM console and each of the TIMs. You can verify the
configuration and usage of the HTTP analyzer plug-in in the CEM console.
To verify your plug-in in the CEM console:
3. Verify that your new plug-in displays Enabled next to the plug-in name.
Verifying an HTTP analyzer plug-in on the TIM


4. Select the plug-in name and verify that the filtering and other configuration settings
are correct. Filtering reduces the traffic sent to plug-ins.
a. If you have specified any IP address ranges (and ports), only HTTP components
from servers within the range will be passed to the plug-ins.
b. If you have specified a URL Path and pattern, only HTTP components with a
matching URL path pattern will be passed to the plug-ins.
c. Verify that you are using plug-in filtering correctly. See About using filters to
limit HTTP analyzer plug-in traffic (see page 166).
d. Verify that the correct JAR file has been loaded for the plug-in.
5. Select Administration > Business Services and select the business service that
contains plug-in parameters.
6. Click the Save to CSV button and review the resulting transaction-related data.
Verify that the usage pattern for the business service is as you expect for your test.
For more information, see Managing transaction definitions (see page 153).
7. Select CEM > Incident Management > Defects and search for a defect that includes
a plug-in parameter. (Plug-in type parameters are generated only by HTTP analyzer
plug-ins.)
Tip: If possible, generate only plug-in related transactions during a test. Otherwise,
it might be difficult to find a defect from a transaction with plug-in parameters.
8. Review the HTTP Information section on the defect to verify that the expected
plug-in parameters (name / value pairs) appear there.
9. Select System > Events and look for events associated with the plug-in. For
example, if there are any HTTP analyzer plug-in error messages or communication
messages related to the Enterprise Manager communications with the TIMs.
For more information, see Troubleshooting the HTTP analyzer plug-in SDK (see
page 177).
10. (Optional) Select System > Event Manager and configure system event email for the
HTTP analyzer plug-in error messages. For more information, see the CA APM
Once you have enabled the HTTP analyzer plug-in, you should verify that it is working as
expected. You should verify in the CEM console and each of the TIMs. You should verify
the HTTP analyzer plug-in status and the TIM status as related to the plug-in.
Note: You should verify the HTTP analyzer plug-in on each enabled TIM.


To verify your plug-in on the TIM:
the TIM.)
2. Select TIM System Setup > View TIM Plug-in Status.
The TIM Java plug-ins page appears.

3. Verify that your new plug-in is active.
If your plug-in is not active on the TIM when you expect it to be, check the TIM log.
4. Select TIM System Setup > View TIM Log.
The TIM Log page appears.
5. Look for log messages that you expect to see, as related to the HTTP analyzer
plug-in you are verifying.
Tip: Search for the "plugin" keyword.


6. Select TIM System Setup > View TIM Status.
The TIM status page appears.

Disabling an HTTP analyzer plug-in


7. Check the Executing Java plug-in ID.
If a plug-in ID appears here for a long time, that is a possible indicator that the
plug-in might be in a loop. See Troubleshooting the HTTP analyzer plug-in SDK (see
page 177).
In most cases, the ID appears as 0, indicating that no plug-in was executing at the
exact second when this page displayed.
8. (Optional) Enter Automatic refresh (in seconds) and click Apply to see if a plug-in ID
appears.
9. Repeat this procedure for each enabled TIM.
Disabling an HTTP analyzer plug-in
If you need to delete the plug-in or replace your HTTP analyzer plug-in JAR file, you need
to disable it first.
To disable your plug-in:
3. Select the plug-in from the list and click Disable.
When you click Disable, CA CEM immediately signals all the enabled TIMs to stop
monitoring using the plug-in.
Troubleshooting the HTTP analyzer plug-in SDK
If you have not yet verified the HTTP analyzer plug-in in the CEM console and the TIMs,
see Verifying an HTTP analyzer plug-in.
This table provides symptoms and solutions that might help you troubleshoot the HTTP
analyzer plug-in.
Events and logs
Symptom:
System event appears in System > Events log: HTTP analyzer plug-in error
You can also receive an email with this system event news.


Solution:
This is the result of an uncaught program exception in the plug-in. It also disables the
plug-in on the TIM (not necessarily all TIMs), and it displays as enabled in the CEM
console.
See the TIM log stack trace to find out where the uncaught exception occurs.
Debug your code and correct it.
See Disabling an HTTP analyzer plug-in (see page 177).
See Checklist for deploying the HTTP analyzer plug-in (see page 163).
Symptom:
System event appSystem event appears in System > Events log:
Enterprise Manager cannot reach TIM
with a description:
Error retrieving
http://<ip_address>/wily/cem/tim/tess/loadplugin?id=600000000000000020: Read
time
Solution:
There was an error loading the plug-in JAR file on the TIM.
This is usually a network-related problem. Verify that the TIMs are up, enabled, and
reachable.
Disable and re-Enable the plug-in, then verify that it is active on each of the TIMs.
See Enabling and disabling TIM monitors (see page 170).
Symptom:
System event appears in System > Events log:
Enterprise Manager cannot reach TIM
with a description:
Error retrieving http://<ip_address>/wily/cem/tim/tess/setpluginconfig: Read timed out
Solution:
There was an error loading the plug-in configuration file on the TIM.
This is usually a network-related problem. Verify that the TIMs are up, enabled, and
reachable.


Disable and re-enable the plug-in, then verify that it is active on each of the TIMs.
Symptom:
Expected log messages do not appear in the TIM log.
Solution:
Verify that the plug-in is enabled in the CEM console and active on the TIMs.
Symptom:
The plug-in flooding the TIM log.
Solution:
Change the plug-in so it does not return log messages (or only logs critical messages).
Debug and test the plug-in in a non-production environment.
TIM status
Symptom:
The Executing Java plug-in ID often displays a non-zero ID.
Any plug-in that appears here often might be in a loop or a wait state, which blocks the
TIM from all other processing.
Solution:
Check the plug-in for a loop or wait state.
Symptom:
The Executing Java plug-in ID always displays 0.
This is common and not usually cause for concern.
Solution:
The TIM Status page displays the plug-in ID only at the exact time the plug-in is
executing. You can try updating the Automatic refresh in seconds option or verify
another way. (It might be too fast to see on the TIM Status page display.)


Symptom:
TIM Plug-in status does not display the plug-in.
It should appear in the list when you save the plug-in configuration in the CEM console.
Solution:
Verify that the plug-in appears in the plug-in list. Verify that the TIM monitor is enabled
on the Setup > Monitors page.
Symptom:
TIM Plug-in status displays the plug-in as NOT active.
The plug-in should appear as active on the TIM when it has been enabled.
Solution:
Verify that the TIM monitor is enabled on the Setup > Monitors page.
See also next symptom / solution.
Symptom:
TIM Plug-in status displays the plug-in as NOT active, yet it appears enabled in the
plug-in list in the CEM console.
Solution:
This is the result of an uncaught program exception in the plug-in. It also generates a
system event.
See the TIM log stack trace to find out where the uncaught exception occurs.
Debug your code and correct it.
Symptom:
TIM Plug-in status is not the same across all the TIMs.
The plug-in states should change on every enabled TIM at the same time.
Solution:
Verify that all TIMs are enabled.
See also the previous symptom / solution.
Note: It is possible for a plug-in program exception to occur on one TIM and not
another.


Symptom:
TIM Appliance Health indicates heavy memory usage.
The plug-in is a possible cause.
Solution:
Modify the plug-in code to improve memory usage.
Transaction identification
Symptom:
The plug-in is enabled and transactions are running, but the TIM does not recognize
them.
Solution:
Verify that the business transaction is enabled.
Verify the filters that you have applied to the plug-in. See About using filters to limit
HTTP analyzer plug-in traffic (see page 166).
Symptom:
The business transaction is enabled and transactions are running, but the TIM does not
recognize them.
Solution:
Verify that the plug-in is enabled and running. Enable TIM component parameter tracing
(TIM System Setup > Configure TIM Trace Options).
Look in the TIM log. See the TIM log stack trace.
Symptom:
Recording is not working.
Solution:
Verify that there is not a plug-in in a loop or in a wait state.
Symptom:
Transaction monitoring does not seem to be working.


Solution:
Verify that you are not monitoring too large a subset of your transactions.
Symptom:
Transaction monitoring is working, but the TIM seems to be falling behind.
Solution:
You must select the check box next to the filter, make the change, and then click Save.
User interface
Symptom:
Changing the IP address or Port filter, then clicking Save does not work.
Solution:
You must select the check box next to the filter, make the change, and then click Save.
Symptom:
The TIM plug-in JAR file is named 600000000000000001.jar and not sure which plug-in it
is.
Solution:
Go to TIM System Setup > View TIM Plug-in Status to see the correlation of JAR file to
plug-in name.
Symptom:
The existing plug-in JAR file is named [Plugin_Name]_1246906950581.jar .
Solution:
This occurs when you do not select the Overwrite existing file option when you update
your plug-in code.
This means both the old and new JAR files are stored on the Enterprise Manager.
In most cases, you should overwrite the existing JAR file.
Code and compiler
Symptom:
Not sure if the JAR file is on the Enterprise Manager machine.


Solution:
The plug-in JAR file is stored on the Enterprise Manager in the
/etc/wily/cem/tess/plugins/ directory.
Do not make changes to this directory or its contents.
Symptom:
Not sure if the JAR file is on the TIM machine.
Solution:
The plug-in JAR file is stored on the TIMs in the /etc/wily/cem/tim/config/javaplugins/
directory.
Do not make changes to this directory or its contents.
Symptom:
Compiler errors.
Solution:
CemJavaPlugin class must be declared as public.


Chapter 9: Monitoring multibyte
transactions

CA CEM supports 16-bit characters in transaction data and definition names. This
provides out-of-the-box support for Chinese, Japanese, and Korean character sets.
This chapter highlights the differences and special considerations when you are
monitoring multibyte transactions. In general, however, the CA CEM workflow for
multibyte is identical to any other transaction monitoring.
Process for using multibyte with CA CEM (see page 185)
About using multibyte character sets with CA CEM (see page 186)
Before using multibyte with CA CEM (see page 187)
Configuring applications for multibyte characters (see page 187)
Recording multibyte transactions (see page 189)
Promoting multibyte transactions (see page 190)
Moving multibyte business transactions (see page 191)
Special considerations for multibyte transaction monitoring (see page 192)
Troubleshooting multibyte with CA CEM (see page 194)
Process for using multibyte with CA CEM
This process describes the tasks related to multibyte support with CA CEM.
1. Learn about how CA CEM supports multibyte. (see page 186)
2. Configure your application for use with multibyte character sets. (see page 187)
3. Record multibyte transactions. (see page 189)
4. Promote multibyte transactions (see page 190).
5. Move multibyte transactions (see page 191).
6. Understand the special considerations for multibyte transaction monitoring. (see
page 192)
7. Troubleshoot common problems with multibyte transaction monitoring. (see
page 194)
About using multibyte character sets with CA CEM


About using multibyte character sets with CA CEM
The CEM console employs UTF-8 character encoding. This enables CA CEM to display
multibyte characters in your browser.
CA CEM supports multibyte for the following objects:
CA CEM transaction hierarchy names:
Business application
Business service
Business transaction
Transaction
Transaction component
CA CEM user-related objects:
User
User group
CA CEM supports multibyte for the following data values:
CA CEM parameters values:
User identification
Session identification
Transaction
CA CEM defect values:
Condition values for content defects
Defect detail values in response data
CA CEM supports multibyte for regular expressions.
A single TIM can monitor multibyte transactionsusing multiple character
encodingsat the same time.
Before using multibyte with CA CEM


Before using multibyte with CA CEM
You must have the required fonts installed (Asian language support) on your PC in order
for multibyte characters to appear properly in your browser.
You need to know the character encoding of your monitored web application in order to
use the CA CEM multibyte feature.
To discover the character encoding of your web application:
In Internet Explorer, select View > Encoding to view your character encoding.
You need the correct character encoding when you:
Create or modify a business application.
Create a new recording session.
Promote a transaction signature to a business service.
Move a transaction definition to another business service.
In order to view HTTP request and response body data, the Capture Comprehensive
Defect Details check box (on the Setup > Domain page) must be selected and you must
have read sensitive data permission. For more information, see the CA APM Security
Guide.
If your organization has deployed CA Embedded Entitlements Manager (CA EEM), you
must set up access policies to allow the correct security groups have access to the
multibyte business service and its associated data. For more information, see the CA
APM Security Guide.
Configuring applications for multibyte characters
The TIM monitor needs to be aware of a transactions character encoding in order to
convert parameter values to the application's character encoding for proper transaction
matching and to convert it to UTF-8 before returning transaction information to CA
CEM.
The foundation of the CA CEM transaction hierarchy is the business application. You
configure your applications character encoding here. Once you have established the
business application, then you associate the business service (and the transactions
under it) with the business application. For more information on the transaction
hierarchy, see the CA APM Overview Guide.
Configuring applications for multibyte characters


To configure your application for multibyte characters:
1. Select Administration > Business Applications.
2. Click New to create a new business application or select an existing business
application.
3. Configure the business application as required. See Defining a business application
(see page 28) for more information.
4. Select the appropriate Character Encoding for your business application:
ISO-8859-1
default.
UTF-8
EUC-JP
Shift-JIS
ISO-2022-JP
Windows-31J
GB2312
Recording multibyte transactions


Big5
EUC-KR
Note: Although it is possible to change the character encoding for an existing
business application, it is not recommended.
5. Click Save to keep your business application settings.
Now you are ready to create business application identifiers and define a business
service, which you need to associate with the business application.
For more information about business application identifiers, see Defining business
application identifiers (see page 31). For more information on defining a business
service, see Defining business services (see page 47).
Recording multibyte transactions
The TIM reads the Content-Type header and <meta> tags during the recording process
to determine the transactions character encoding.
If the character encoding cannot be determined, then the TIM uses the default
character encoding to interpret the transaction signature.
The character encoding should match the business service to which you intend to
promote the transaction signature. (The associated business application is where you
specify the character encoding for the business services and transactions.)
To record transactions with multibyte characters:
1. Select Administration, Recording Sessions.
2. Click New to create a new recording or select an existing recording.
3. Configure the recording as required. See Recording transaction signatures (see
page 49) for more information.
4. Select the appropriate Default Character Encoding for your recording:
ISO-8859-1
default.
UTF-8
Promoting multibyte transactions


EUC-JP
Shift-JIS
ISO-2022-JP
Windows-31J
GB2312
Big5
EUC-KR
5. Click Record to start the recording session.
For more information about recording transactions, see Recording transaction
Promoting multibyte transactions
After you have recorded the transaction signature with your multibyte recording
session, you need to promote the signature to a transaction definition.
You must already have defined your business service before performing this procedure.
See Defining business applications (see page 28) and services (see page 47) for more
information.
To promote a transaction signature to a transaction definition:
3. Select the transaction signature you want to promote by clicking the associated
check box
Moving multibyte business transactions


4. From the Promote to list, select the name of the correct multibyte business service,
then click Promote.
The Business Transactions page appears with the promoted transaction.
Note: The business service must be associated with a business application with the
same character encoding as the transaction signature.
Now you are ready to edit the transaction definition from the specific transaction you
recorded, in order to generalize it to match transactions executed by all users. For
information on editing transactions, see Editing transactions (see page 113).
Moving multibyte business transactions
You can move business transactions from one business service to another. With
multibyte transactions, especially when you are using automatic transaction discovery,
it is possible to discover transactions with multiple character encodings. See Using
automatic transaction discovery with multibyte applications (see page 193) for more
information.
With the move function you can manually move a business transaction to another
business service, which is in turn associated with a different business application, with
the correct character encoding.
Follow these steps:
1. Select Administration, Business Services.
2. Select the name of a business service you need.
3. Select the business transaction that you want to move by clicking the associated
check box.
4. From the Move to list, select the name of the correct multibyte business service,
and then click Move.
The business transaction moves to the selected business service.
Note: The business service should be associated with a business application with the
same character encoding. However, because it is possible to discover transactions with
the mixed character encodings, you are allowed to move in order to manually correct
that situation.
Special considerations for multibyte transaction monitoring


These sections cover special situations that you should be aware of when monitoring
multibyte transactions:
CA CEM limitations for multibyte support (see page 192)
Using export with multibyte business transactions (see page 192)
Using Save to CSV with multibyte business transactions (see page 193)
Using regular expressions with multibyte transactions (see page 193)
Using offsets with multibyte business transactions (see page 193)
Using automatic transaction discovery with multibyte applications (see page 193)
Using the HTTP analyzer plug-in with multibyte applications (see page 194)
CA CEM limitations for multibyte support
CA CEM multibyte support has the following limitations:
The browser (not CA CEM) supports writing direction (left-to-right or right-to-left).
Collating sequences and sort order is based on Unicode code point values.
Identical-looking characters might mean two different transactions could appear to
have the same name, and could cause searches to appear to fail.
Business application content is expected to have one-character encoding.
Internationalized domain names are not supported.
SiteMinder does not support character encodings other than us-ascii.
Using export with multibyte business transactions
If your business transaction name consists of multibyte characters, you must use WinZip
11.2 or later to manually view the exported zip file. Earlier versions of WinZip do not
correctly show file names within an export zip file when they contain multibyte
characters. This is an incompatibility between the java.util.zip classes and WinZip.
See Exporting and importing business transaction definitions (see page 151) for more
information.


Using Save to CSV with multibyte business transactions
If your business transaction definitions contain multibyte characters, the exported CSV
file cannot be opened directly by Excel. You must first save the file then import it (as
data from text) into Excel.
See Managing transaction definitions (see page 153) for more information.
Using regular expressions with multibyte transactions
CA CEM supports multibyte for regular expressions with these caveats:
Regular expressions can cause unnecessary performance issues when another
method is available.
When using a double byte character encoding (e.g., Shift-JIS), using a wildcard in an
attempt to find a particular character offset might not work.
Note: Although the character value itself is 16 bits, many character encodings in use by
web applications for multi-lingual text can take a variable number of bytes due to
character serialization. If you are using regular expressions to find an offset, remember
that the offset is in characters, not bytes.
See Regular expressions in CA CEM (see page 201) for more information.
Using offsets with multibyte business transactions
If you need to use offsets for user and session identification parameters, remember that
the offset is in characters, not bytes. Character encoding for multi-lingual text can take a
variable number of bytes due to character serialization.
See Offset and Length examples (see page 42) for more information.
Using automatic transaction discovery with multibyte applications
When you use automatic transaction discovery, you assign the character encoding via
the template you use; you configure the business application in the template.
Automatic transaction discovery does not verify the character encoding for each
discovered transaction. If you do not create the template to match your applications
transactions, it is possible to discover transactions with character encodings that do not
match the assigned business application.
See Automatically discovering transactions (see page 91) for more information.
Troubleshooting multibyte with CA CEM


If you make this mistake, the resulting errors include:
Invalid or "garbage" characters appear in transaction parameter values.
The TIM monitor might not discover valid transactions because it cannot match
values; the TIM is expecting a character encoding that is different from the
transaction.
UTF-8 failure messages appear in the TIM log.
To correct this situation, you can move the business transaction to a business service /
application that has the correct character encoding. See Moving multibyte business
transactions (see page 191) for more information.
You can also use the business transaction export and import feature. See Using export
with multibyte business transactions (see page 192) for more information.
Using the HTTP analyzer plug-in with multibyte applications
If you are writing a plug-in to handle multibyte data, you should be aware of the
following:
The TIM passes the HTTP request body data to the plug-in unaltered.
The plug-in is responsible for determining the encoding of the input data, based on
(1) the "encoding" attribute in the XML declaration (if there is one), (2) the
"charset" attribute of the "Content-Type" field in the HTTP request header, (3) a
Byte Order Mark in the data, and (4) any knowledge you have about your
applications.
The plug-in is responsible for performing any necessary character encoding
conversion (normally the XML parser takes care of this); the plug-in returns
parameter names and values as Java strings, which use UTF-16.
This table lists possible issues that you might have with multibyte transaction
monitoring and how to solve them.
Symptom:
Seeing "garbage" characters in the UI where you expect multibyte characters to appear.
Solution:
Verify that you have installed the proper fonts and character encoding on your
computer. See Before using multibyte with CA CEM (see page 187).


Symptom:
Valid transactions are not being discovered with automatic transaction discovery.
Solution:
Verify that the template is configured with the correct character encoding.
See Automatically discovering transactions (see page 91).
Symptom:
Valid transactions are being discovered with automatic transaction discovery, however
they are assigned to the default business application, which is configured for UTF-8.
Solution:
Move the discovered transactions to a business application with the correct character
encoding.
See Moving multibyte business transactions (see page 191).

Symptom:
The TIM log contains iconv errors. The error starts with:
**Error: Unicode: iconv: cannot convert ...
Solution:
Verify that the business application is configured with the correct character encoding.
See Configuring applications for multibyte characters (see page 187).
Symptom:
A transaction that worked before now displays "garbage" characters in the UI.
Solution:
Verify that a CEM administrator did not change the character encoding by mistake.
(Although it is possible to change the character encoding on a business application, it is
not recommended.)
Symptom:
Some transactions display properly and some display "garbage" characters.
Solution:
Business application content is expected to be one-character encoding.
Symptom:
Cannot promote a transaction signature to a business service.


Solution:
Verify that the business service is associated with the proper business application and
that the business application has the matching character encoding.

Symptom:
A transaction fails to match your transaction definition.
Solution:
multilingual text can take a variable number of bytes due to character serialization. If
you are using a regular expression to find an offset, remember the offset is in
characters, not bytes.
Symptom:
A recording has a character encoding of us-ascii (or another), yet the default character
encoding is ISO-8859-1.
Solution:
The TIM reads the Content-Type header during the recording to determine the
transaction character encoding. (This is not an issue.)
Symptom:
The character encoding that you need is not in the selection list for the business
application.
Solution:
If you need a character encoding that is not currently supported, contact your CA
Technologies representative.
Symptom:
The TIM log contains hexadecimal characters that I cannot explain.
Solution:
Multibyte characters appear in the TIM log; it is expected and not a problem.


Appendix A: HTTP status codes

Hypertext Transfer Protocol (HTTP) 1.1 status codes and their meanings:
100 series: informational status codes (see page 197)
200 series: success status codes (see page 197)
300 series: redirection status codes (see page 198)
400 series: client error status codes (see page 198)
500 series: server error status codes (see page 199)
For more information, go to http://www.w3.org
100 series: informational status codes
This table lists the 1xx HTTP status codes and meanings.

Code Description
100 Continue
101 Switching protocols

200 series: success status codes

Code Description
200 OK
201 Created
202 Accepted
203 Non-Authoritative Information
204 No Content
205 Reset Content
206 Partial Content

300 series: redirection status codes


300 series: redirection status codes

Code Description
300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
305 Use Proxy
306 Status code 306 is no longer used, and the code is reserved.
307 Temporary Redirect

400 series: client error status codes

Code Description
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Time-Out
409 Conflict
410 Gone
411 Length Required
412 Precondition Failed
500 series: server error status codes


Code Description
413 Request Entity Too Large
414 Request URI Too Long
415 Unsupported Media Type
416 Request Range Not Satisfiable
417 Expectation Failed

500 series: server error status codes

Code Description
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Time-Out
505 HTTP Version Not Supported


Appendix B: Regular expressions in CA CEM

Regular expressions (sometimes shortened to RegEx) can be used as an alternative to
simple pattern matching in CA CEM. For example, regular expressions give you the
flexibility to combine similar transactions, rather than having to record and identify
every variation.
Regular expressions are more powerful than simple pattern matching but are less
efficient and therefore add some overhead.
CA CEM uses these libraries for regular expressions:
Jakarta-ORO
PCRE Perl-compatible regular expressions
Java
Multiple CA CEM components use regular expressions.
BizTrxHttpTracer (see page 201)
CEMTracer (see page 201)
CA CEM TIM (see page 202)
CA CEM (see page 202)
CA CEM NSM bridge (see page 202)
Regular expressions resources (see page 202)
BizTrxHttpTracer
BizTrxHttpTracer uses regular expressions for transaction matching.
BizTrxHttpTracer uses java.util.regex. See the CA APM Compatibility Guide for the JVM
versions supported by Introscope.
CEMTracer
CEMTracer uses regular expressions for transaction matching.
CEMTracer uses Jakarta-ORO.
Functionality previously provided with CEMTracer (pre CA APM 9.0) is supplied by
BizTrxHttpTracer.
CA CEM TIM


CA CEM TIM
CA CEM TIM also uses regular expressions for transaction matching.
CA CEMTIM uses PCRE for matching data against regular expressions. The PCRE library
supports multibyte characters.
About anchoring
Regular expressions in CA CEM are not anchored. For example, the regular expression
"c.*d" matches any parameter value that contains a "c" followed anywhere by a "d",
such as "cd", "c123d", or "abc123def".
You must use "^" to anchor a regular expression to the beginning of a parameter value.
You must use "$" to anchor a regular expression to the end of a parameter value.
You can use both "^" and "$" in the same regular expression. For example, to match a
parameter value that starts with "c" and ends with "d", use "^c.*d$". This matches "cd"
and "c123d". It does not match "abc123d" because "c" is not the first character.
Similarly, it does not match "c123def" because "d" is not the last character.
CA CEM
CA CEM validates regular expressions using both PCRE and Jakarta-ORO.
Note: This does not guarantee that both libraries interpret regular expressions in the
same way.
CA CEM NSM bridge
The NSM bridge uses regular expressions in the cemBridgeConnector.properties file as a
method for filtering business services, business transactions, and user groups that are
not required to be reported in NSM.
The NSM bridge uses Java regular expressions.
Regular expressions resources
The following resources can help you when you need to use regular expressions in CA
CEM.
Regular expressions resources


Jakarta-ORO
Jakarta web site with ORO project and demo:
http://jakarta.apache.org/oro/
OROMatcher Users Guide:
http://www.savarese.org/oro/docs/OROMatcher/Syntax.html
PCRE Perl-compatible regular expressions
Syntax and semantics see the PCREPATTERN section:
http://www.pcre.org/pcre.txt
Java
Tutorial:
http://download.oracle.com/javase/tutorial/essential/regex/index.html
Javadoc:
http://download.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html


Appendix C: Transaction Definition
Troubleshooting

All Transaction Definition Troubleshooting Information
Troubleshooting Login to CA CEM (see page 26)
Troubleshooting transaction recording (see page 68)
Troubleshooting automatic transaction discovery (see page 105)
Troubleshooting tips for transactions (see page 139)
Transactions were being recognized but suddenly stopped (see page 140)
Observe the transactions being monitored by the TIM (see page 140)
Too many missing response defects (see page 142)
Problems with transactions that contain path parameters (see page 143)
Troubleshooting Flex transactions (see page 143)
Troubleshooting the HTTP analyzer plug-in SDK (see page 177)
Troubleshooting multibyte with CA CEM (see page 194)

Index 207

Index

A
agent recording 69
HTTP path parameters 78
JSESSIONID 78
proxy server 79
transaction definitions 70
transaction signatures 70
agents, synchronizing 135
Any type parameter in automatic discovery 95
application, see business application See business
application
Asian language support for multibyte 187
automatic transaction discovery
Any type parameter 95
automatic transaction discovery, about 92
catchall example 97
creating templates 93
monitoring discovered transactions 103
multiple transactions per template 96
path parameters 97
selecting TIMs for 99
starting 100
stopping 101
templates, editing 98
templates, enabling 98
templates, ordering 98
troubleshooting 105
viewing transactions 102
with multibyte transactions 193
B
baseline, setting for defect type conditions 125
Big5, multibyte character encoding 187
BizTrxHttpTracer, using regular expressions with
201
browser language, pattern for recording
agent 79
example 83
setting recording with 52
bulk editing
business transactions 148
defect conditions 148
business application 27
defining 28
defining (agent recording) 73
hierarchy 27
setting up 28
business service
defining 47
Discovered Transactions 102
moving business transactions between 152
Business Transaction Components, defined 19
business transactions
bulk editing 148
creating 111
data, exporting to file 153
export and import 151
moving to another business service 152
replacing existing 156
C
CA SiteMinder See authentication type
caching web pages 50
caching web pages (agent recording) 72
Case Sensitive Login Names 28
Case Sensitive URL Path 28
case sensitivity
login names 28
login names, troubleshooting 31
URL path 28
CEMTracer, using regular expressions with 201
client IP addresses
client IP addresses, as user identifier 36
contacting technical support 5
CSV files
exporting business transaction data 153
UTF-8 characters in 153
customer support, contacting 5
D
default business application, deleting or editing 27
defects
defining 124
defining component 128
editing conditions for 150
Discovered Transactions business service 102
discovered transactions, monitoring 103


E
e-commerce, user processing type 28
Enterprise Manager
recording on 79
Enterprise, user processing type 28
EUC-JP, multibyte character encoding 187
EUC-KR, multibyte character encoding 187
exporting
business transaction data 153
business transaction definitions 151
F
fonts, required for multibyte support 187
G
GB2312, multibyte character encoding 187
H
host name, limitation for agent recording 78
HP LoadRunner 61
HTTP analyzer plug-in
about 158
best practices 161
cautions 161
checklist 163
compiling 165
configuring 166
creating a JAR file 165
deploying multiple plug-ins 162
disabling 177
enabling 170
enabling and disabling TIM monitors for 170
filters 166
IP address range filter 166
modifying 168
overview 158
plug-in parameter type 158
port filter 166
testing 170
troubleshooting 177
URL path filter 166
using 160
verifying in the CEM console 173
verifying on a TIM 174
XML data handling 162
HTTP path parameters, limitation 78
HTTP response codes, for defect identification 128
HTTP Response Header Parameter
about 128
using 128
HTTP responses, for defect identification 128
HTTP status codes 197
I
iconv errors, with multibyte 194
identifiers
interim session 39
session 32
user 34
user group 41
using client IP address to identify users 36
using XML to identify transactions 120
using XML to identify users, groups, user groups
42
importing
interim session identifiers
defining 39
example using Location Query 40
Introscope agent recording See agent recording
invalid byte sequence, with multibyte 194
Investigator tree, synchronize to 135
IP addresses
using client to identify users 36
IPv6
limitation for agent recording 78
ISO-2022-JP, multibyte character encoding 187
ISO-8859-1, multibyte character encoding 187
J
Jakarta-ORO regular expressions 203
JSESSIONID (agent recording) 78
L
Length field, example 42
Limit exceeded adding new components event 103
LoadRunner 61
locking
defect type conditions 125
log files
TIM log 174
login names, using client IP address 36
loop back address (agent recording) 79

Index 209

M
multibyte
configuring applications for 187
CSV files and UTF-8 153
fonts required 187
garbage characters with 194
iconv errors with 194
invalid byte sequence with 194
limitations 192
moving business transactions 191
prerequisites to using 187
promoting transactions 190
recording transactions 189
special considerations for 192
supported CA CEM objects 186
supported character encoding 187
TIM monitoring transactions 186
troubleshooting 194
using automatic transaction discovery with 193
using export with 192
using offsets with 193
using regular expressions with 193
using save to CSV with 193
using the HTTP analyzer plug-in with 194
multibyte character encoding
Big5 187
EUC-JP 187
EUC-KR 187
GB2312 187
ISO-2022-JP 187
ISO-8859-1 187
Shift-JIS 187
UTF-8 187
Windows-31J 187
N
non-identifying components
discovering 103
discovering, about 92
maximum for automatic discovery, about 103
NTLM authentication 44
O
Offset field, example 42
offsets
examples 42
ORO, Jakarta regular expressions 203
P
parameter map
viewing 65
viewing (agent recording) 86
parameters
adding to transaction definitions 122
Any type in automatic discovery 95
defining 44
defining transactions 109
deleting 122
examples 14
for automatic transaction discovery 93
NTLM authentication 44
path 44
wildcarding names 119
XML for transactions 120
XML, for sessions, users, user groups 42
path parameters
automatic transaction discovery 97
setting delimiter 46
troubleshooting 143
Pcap files 62
PCRE Perl-compatible regular expressions 203
performance view, generating 137
plug-in
CA SiteMinder 32
HTTP analyzer plug-in 157
parameter type 158
prerequisites for this book 14
promoting business transactions
agent recording 88
TIM recording 110
to replace existing 156
proxy server
agent recording 79
monitoring traffic behind 52
monitoring traffic behind (agent recording) 83
setting up for 51
R
recorders, types 50
recording
editing sessions (agent recording) 87
installing the script recorder 61
libpcap packet capture 61
problems in high traffic (agent recording) 79


recording, generating VUGen trace files 61
script output files 61
script recorder command-line instructions 63
transactions 53
types 50
viewing sessions 63
viewing sessions (agent recording) 85
viewing the parameter map 65
viewing the parameter map (agent recording)
86
RegEx
in CA CEM 201
regular expressions
in CA CEM 201
replacing
S
Save to CSV
using with CA CEM 193
write transaction data 153
script recorder
about 61
command-line instructions 63
input file types 61
installing 61
scripts
VUGen 61
WTG 22
session identifiers
defining 32
example 32
Shift-JIS, multibyte character encoding 187
signatures
promoting to definitions 110
recording 49
SiteMinder
authentication type 28
session identifiers 32
user identifiers 34
support, contacting 5
synchronizing TIMs and agents 135
T
technical support, contacting 5
templates, for automatic transaction discovery
creating 93
editing 98
enabling 98
ordering 98
TIM log, viewing 174
TIM Transaction Inspection 140
TIMs
automatic transaction discovery, for 99
enabling 135
monitoring multibyte transactions 186
synchronizing 135
transaction definition administration 153
transactions 13
adding new parameters to a definition 122
creating business 111
defining 109
defining component defects 128
defining defects 124
deleting definition parameters 122
editing components 116
editing definitions 113
hierarchy 19
how CA CEM monitors 13
identifier parameters 109
importing and exporting business 151
missing, troubleshooting 139
modifying definition parameters 116
monitoring 134
monitoring discovered 103
monitoring multibyte 185
names for automatically discovered 96
non-identifying components, discovering 92
promoting signatures to definitions 110
recorder types 50
recording 49
transactions, automatic discovery of 91
viewing results 137
viewing settings 144
troubleshooting
agent recording, slow or no 79
automatic transaction discovery 105
HTTP analyzer plug-in SDK 177
logging in to CEM console 26
login names case sensitivity 31
missing transactions 139
multibyte 194
path parameters 143

Index 211

U
URL Path Filter, examples in automatic discovery
95
user group identifiers
defining 41
user identifiers
defining 34
example 34
user names, using client IP address 36
User Processing Type 28
using path parameters to identify users, groups, and
user groups 44
UTF-8, in CSV files 153
V
VUGen
generating with script recorder 61
W
WebLogic Application Server 78
agent recording 78
JSESSIONID 78
wildcards
for para 116
for parameter names 119
Windows-31J, multibyte character encoding 187
Workstation
monitoring recorded transactions 69
WRM scripts 22
X
XML identifiers
defining for sessions, users, groups 42
defining for transactions 120

APM - 9.5 Transaction Definition Guide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

APM - 9.5 Transaction Definition Guide

Uploaded by

Copyright:

Available Formats

Transaction Definition Guide

You might also like