On this page:

Related pages:

A custom match rule lets you control how AppDynamics generates and names business transactions based on entry point requests. 

Evaluation Priority

After you configure custom match rules, it's possible that an incoming request can be matched by more than one of the configured detection rules in AppDynamics. The following sequence shows the order of priority in which transactions are detected and named:

  1. Upon receipt of the request, AppDynamics checks for a match against a custom match rule. If a custom match rule exists, the business transaction is named based on that rule.
  2. If no custom match rule exists, AppDynamics checks the custom exclude rules. If the custom exclude rule exists, the transaction is excluded from discovery.
  3. If no custom exclude rule exists, AppDynamics check the request against the default detection rules, and applies auto-detection naming scheme to the transaction.

The following illustration shows the sequence for the transaction discovery process:

If you want to reverse the order in which the Java and .NET agents evaluate rules so that exclude rules are evaluated before match rules, set the check-bt-excludes-early node property to true. By default it is false.

Creating Custom Match Rule

A custom match rule directs AppDynamics to generate business transactions based on the match conditions you configure. The business transactions are named with the name of the match rule. Using them involves:

You can create a custom match rule from the Transaction Detection tab under Configuration > Instrumentation

You then choose the Entry Point type for which you want to create the custom match rule and the specific match settings for that type of entry point.

Configuring Custom Match Rules

The following example is a custom match rule that generates business transactions for Web Service GET requests in which the URI begins with "/cart/" followed by a number. The business transaction will be named cart.GET

You can add conditions to the match rule to match based on specific HTTP parameters or hostnames.

For certain HTTP-based request types, such as Servlets or ASP.NET, a match rule can have more than one HTTP Parameter match condition. A request must match all HTTP Parameter conditions to match this rule. (That is, there is an implicit AND operator between the parameters rather than an OR operator.) 

You can use more complex regular expression matching. For example, for the following request URLs: 

To match any incoming request URL to this business transaction, use the following:


Any request to a URL that includes mysite.com followed by letters (upper or lowercase) and numbers would be matched to this business transaction detection rule. A URL that has no digits after the letters, mysite.com/z.aspx, would not be matched. 

See Using Regular Expressions for more information on using regular expressions in the UI.  

Setting Match Rule Priority

If more than one match rule applies to a business transaction, the Priority field determines the order of precedence for the rules. The priority applies from highest number to lowest number, with 0 being the lowest priority. The app agent matches the rule with the highest number first.

In versions up to 4.2.2, the Python Agent applied match rules in reverse order, with 0 being the highest priority. As of 4.2.3, 0 is the lowest priority as it is for other agent types.


Configure Transaction Splitting

For URI based matches, you can configure business transaction splitting. With splitting, you can configure a set of requests that are matched by URI to be resolved into separate business based on a dynamic part of a request. So, for example, incoming requests with the following request URLs:

Could be resolved to two different business transactions, named:

Notice that the transaction is named as:

<custom match rule name>.<name derived from the split configuration>

To specify this configuration, use category as the parameter on which to split transactions: