Hallett_German

CA Tuesday Tip: APM Transaction Definition Setup - Part 1 Strategies

Discussion created by Hallett_German Employee on Jan 2, 2012
Latest reply on Jan 3, 2012 by MaryGreening
CA Wily Tuesday Tip by Hallett German, Sr. Support Engineer for 1/3/2011

APM Transaction Definition Setup - Part 1 Strategies

So you recorded and promoted your definition and it is time to set up the rules that uniquely identify a business transaction regardless of the steps used to access. This is such an important topic that it be covered in two articles.

Setting up the correct transaction define ensures that defects and statistics will only be for the transactions that you define. A clear definition means that no ambiguous or overlapping definition processing will result.

What would be an example of an ambiguous definition ? An extreme case would be having a POST with a * for variable name and DOES NOT EXIST. This may result in unexpected processing behavior

What are some examples of overlapping definitions? These include definitions that have the same matching rules (such as matching on same URL) or having two regular expressions that can inadvertently match on the same hostname. This may also result in unpredictable processing behavior on which one is matched.

There are some general strategies on building transaction definitions. These are not mutually exclusive.
1) Have a catch all rule (such as path is * or /* or /MyWebPage/* for a particular site). There are at least two reasons to do this -- to determine which transactions are not defined (such as the result of a new release.) Or to gather statistics for all URLs. Remember this will not be matched if there is a more specific (hint -- longer) definition.
2) Build a set of related rules for a particular function (Such as one definition matching on OP=SEARCH to cover all search operations, and a set of definitions to cover more specific rules -- e.g. OP=SEARCH, STATE=CA, OP=SEARCH,COMPANY=CIRCULAR LOGIC INC etc.)
3) Build a full set of similar rules that are slightly different for each environment, customer, etc. that would be stored under different business applications or business services.
4)Use Business Services/Business Transactions to group definitions
- Try building a sandbox business service/transaction to define and optimize definitions before moving to production. The same
thing could be done with muliple testing environments before migrating definitions to production.
- Placing basically the same set of definitions under different business services/transactions for different locations,
customers, types of devices (such as mobile, electronic kiosk, and desktop computers) application environments, language, and
other factors.
5) Use Business Services to differentiate special type of transactions such as Siebel,SAP,FLEX etc.
6) With APM 9.1 there is the additional flexibility of defining
- Request Only
- Response Only
- Request and Response

For responses this is based on the HTTP status code, HTTP Response parameters/values, or HTTP/Flex parameters that appear in the response body. This allows you to build powerful definitions that can better capture the application transaction round trip.

7) One or more HTTP Plug-ins can be created to define the special transaction definition parameters that cannot be created out of the box

This is the tip of the iceberg. Next month, we will go into more specifics on building definitions.

Discussion Questions:
- Which of the above application/transaction strategies are you using? Are there others not listed above that you are going to use.
- How are you planning to use the new APM 9.1 response definition capability?
- What additional functionality would you like to see added to make transaction definitions easier?

Don't miss the CA Wily/APM Global User Community webcast on January 19, 2012.

Topics include: Is an Upgrade Right For You? Why you should consider a move to APM 9.1

Outcomes