Skip to end of metadata
Go to start of metadata

This topic describes how to configure entry point detection for a particular Servlet-based transaction using a custom match rule. 

To configure at the global application or tier level see Automatic Naming Configurations for Servlet-Based Business Transactions.

For context see Configure Business Transaction Detection and Servlet Entry Points.

Custom Match Rules for Specific Contexts

To handle situations when web contexts represent different parts of the same business application and therefore require different naming configurations, use custom match rules for each of the web contexts or URIs. Custom match rules let you create mutually exclusive business transactions for specific contexts.

See Custom Match Rules for general information. 

 

You can use the transaction splitting option to separate business transactions based on URI patterns, request data, or payload.

To access business transaction detection custom configuration

1. From the left navigation pane select Configure -> Instrumentation.

2. Click the Transaction Detection tab if it is not already selected.

3. Select the tier for which you want to configure the transactions or select the application if you want to configure at the application level. For information about inheritance for transaction detection, see Hierarchical Configuration Model.

4. Click the Java - Transaction Detection subtab.

5. In the Custom Match Rules panel click Add (the + sign).

6. To configure a rule for Servlets, select Servlet the drop-down list and click Next.

The New Business Transaction Match Rule - Servlet window opens.

7. Give the rule a name. 

8. If you have multiple custom match rules, change the priority based on the evaluation order of the rule. Higher numbers will evaluate first, with 0 being the last custom rule to be evaluated. For details see Sequence and Precedence for Auto-Naming and Custom Match Rules.

Match on HTTP Methods

You can use GET, POST, PUT, and DELETE methods to identify a business transaction.

 

Match on URIs

By default AppDynamics automatically discovers and identifies all Servlet-based business transactions using the first two segments of the URI. You can change the global default or use a different pattern for a custom match rule. 

A custom rule can match a URI based on one of the following expressions:

  • Equals
  • Starts With
  • Ends With
  • Contains
  • Matches Reg Ex
  • Is in List
  • Is Not Empty

In addition you can configure a NOT condition:

Split a URI Using Request Data

You can split business transactions by adding attributes to either full or partial URI's for a Servlet request. You can also append a key-value pair to a URI discovered name. This splits the URI into a separate transaction.

  1. First you configure the URI match. See the previous section. 
  2. Select the Split Transactions using Request Data tab and click the Split Transactions using request data option.
  3. Provide the details for dynamically splitting based on the following:

Split Based on the First Segments of the URI

Consider the following request URI: 

http://acmeonline.com/store/checkout

Note that the "first two segments" is the same as the default global configuration. You may want to use a similar custom match rule when you have a few different rules and you want to control the order (Priority) by which the rules execute. 

                  

Split Based on the Last Segments of the URI

Consider the following request URI: 

http://acmeonline.com/web/store/checkout

Using the default global discovery rules, AppDynamics automatically identifies this business transaction as: /web/store. However the default does not accurately identify the functionality used by the store, such as checkout or add to cart etc.

You can reset it to Use the last 2 segments so that the business transaction is named "<Name_Of_The_Custom_Rule>.store.checkout".

Split Based on URI Segment Numbers

You can name your transaction dynamically using a particular segment number.
For example: For ACME Online, the checkout operation has following URL:

http://www.acmeonline.com/shopping/customer1234/checkout

To correctly identify the user requests for "checkout" functionality, provide the segment numbers ("1,3"). This custom match rule groups all the qualifying requests into a "<Name_Of_The_Custom_Rule>.shopping.checkout" transaction.

For another example:

Split Based on Parameter Values

You can name a business transaction based on the value of a particular parameter in the request data.
For example, ACME Online's checkout action results in following URL:

http://acmeonline.com/orders/process?type=creditcard

You want to use the combination of the parameter value for the parameter "type" and the last two segments to identify a business transaction called  "/orders/process.creditcard". This ensures that the credit card orders are differentiated from other orders.On the "Transaction Match Criteria" section, select the matching option for URI (in this case, "orders").

  1. Define the URI.
  2. For the Split Transactions using Request Data option, enter the parameter name ("type").

This custom rule will group all those requests for which the value of parameter "type" is "creditcard" into a "<Name_Of_Custom_Rule>.creditcard" business transaction. 

A custom rule may also identify other requests that use the same parameter. You can later choose to exclude these transactions.

You can split based on multiple parameters by entering the comma-separated names of those parameters.

Split Based on Header Values 

You can also name your transaction based on the value of header(s) of your request data, including the host name.

For example, to identify the requests based on the host name for ACME Online:

    1. Define the URI.
    2. For the Split Transactions using Request Data option, enter the header name ("Host"). 

This custom rule will put qualifying requests into a business transaction named "<Name_Of_Custom_Rule>.<Host_Name>".

You can also name your transaction based on multiple headers by entering the comma-separated names of those headers.

Split Based on Cookie Values

You can also name your transaction based on the value of a particular cookie in your request data.

For example, you can identify only those business transactions where the "Gold" customers invoke the checkout operation.
To do this, specify a custom rule as follows:

    1. Define the URI.
    2. For the Split Transactions using Request Data option, enter the name of the cookie.

This configuration will also return those transactions for which the customer priority is not "Gold". You can choose to exclude such transactions.

You can also name your transaction based on multiple cookies by providing the comma-separated names of those cookies.

Split Based on an HTTP Method

You can name a business transaction based on GET/POST/PUT methods.

To do this, specify a custom rule as follows:

    1. Define the URI.
    2. For the Split Transactions using Request Data option, select Use request methods (GET/PUT/POST) in the transaction names.

Split Based on the Request Host

You canname a business transaction based on the request host.

  1. Define the URI.
  2. For the Split Transactions using Request Data option, select Use request host in transaction names.

Split Based on the Request Originating Address

You can name a business transaction based on the request's originating address.

    1. Define the URI.
    2. For the Split Transactions using Request Data option, select Use the request originating address in transaction names.

Split Based on a Custom Expression

You can use a custom expression to name a business transaction.  

  1. Define the URI.
  2. For the Split Transactions using Request Data option, select Apply a custom expression on HTTPServletRequest and use the result in Transaction Names.
  3. Enter the custom expression. See Custom Expressions for Naming Business Transactions.

Match on an HTTP GET or POST Parameter

To identify transactions based on the POST parameter

For example, ACME Online's checkout operation for any item in the "Book" category results in a POST parameter ("itemid") whose value is "Book".

To identify only those requests that belong to a "BuyBook" business transaction, configure the custom match rule:

  1. In the Transaction Match Criteria tab, define the URI as "/shopping".
  2. In the same tab, check the HTTP Parameter option.
  3. Select Check for parameter value.
  4. Enter the Parameter Name; in this example it is "itemid".
  5. Set Value Equals to "Book".

With this custom match rule, every time a request matches the custom parameter rule it is identified as part of the BuyBook business transaction.

Match on a Header Parameter Name or Value

A custom rule can match on a header parameter name.

  1. In the Transaction Match Criteria tab, check Header.
  2. Select Check for parameter existence and enter the parameter name. 

A custom rule can match on a header parameter name and value. 

  1. In the Transaction Match Criteria tab, check Header.
  2. Select Check for parameter value and enter the parameter name. 
  3. Enter a Value based on one of the following expressions:
  • Equals
  • Starts With
  • Ends With
  • Contains
  • Matches Reg Ex
  • Is in List
  • Is Not Empty

Match on a Hostname or Port

A custom rule can match a hostname or port based on one of the following expressions:

  • Equals
  • Starts With
  • Ends With
  • Contains
  • Matches Reg Ex
  • Is in List
  • Is Not Empty

In addition you can configure a NOT condition.

Match on a Class or Servlet Name

A custom rule can match a class name or Servlet name on one of the following expressions:

  • Equals
  • Starts With
  • Ends With
  • Contains
  • Matches Reg Ex
  • Is in List
  • Is Not Empty

In addition you can configure a NOT condition.

Match on a Cookie Name or Value

A custom rule can match on a cookie name.

  1. In the Transaction Match Criteria tab, check Cookie.
  2. Select Check for cookie existence and enter the cookie name. 

A custom rule can match on the value of a cookie. 

  1. In the Transaction Match Criteria tab, check Cookie.
  2. Select Check for cookie value and enter the cookie name. 
  3. Enter a Value based on one of the following expressions:
  • Equals
  • Starts With
  • Ends With
  • Contains
  • Matches Reg Ex
  • Is in List
  • Is Not Empty

Match on Information in the Body of the Servlet Request

In certain situations, you might have an application that receives an XML/JSON payload as part of the POST request.

If the category of processing is a part of the XML/JSON, neither the URI nor the parameters/headers have enough information to name the transaction. Only the XML contents that can provide correct naming configuration.
See Identify Transactions Based on DOM Parsing Incoming XML Payload and Identify Transactions for Java XML Binding Frameworks.

Learn More