AppDynamics automatically detects entry points for client requests to ASP.NET applications. If the request occurs on an originating tier, the method or operation marks the beginning of a business transaction and defines the transaction name. In most cases, this type of entry point maps to a user request or action such as "Cart/Checkout". AppDynamics allows you to configure transaction naming based upon the ASP.NET request.

For information on how to configure default ASP.NET transaction detection, see URI Based Entry Points.

Custom Match Rules for ASP.NET Transactions

Custom match rules provide greater flexibility for transaction naming. When you define a match rule, AppDynamics uses the rule name for the business transaction name.

See Custom Match Rules for general information on how to create custom match rule.

The .NET Agent for Linux supports the configuration of simple ASP.NET business transactions through the Controller UI. See .NET Agent for Linux Business Transaction Configuration.

When AppDynamics detects a request matching your specified criteria, it identifies the request using your custom name. You can use the following criteria to match transactions:

Method: Match on the HTTP request method, GET, POST, PUT or DELETE.

With automatic discovery for ASP.NET transactions enabled, configuring the match on GET or POST causes the agent to discover both GET and POST requests. If you only want either GET or POST requests for the transaction, consider the following options:

    • Disable automatic discovery for ASP.NET transactions.
    • Create an exclude rule for the method you don’t want: GET or POST.

URI: Set the conditions to match for the URI.

    • For rules on regular expressions for .NET, see .NET Framework Regular Expressions.
    • Optionally click the gear icon to set a NOT condition.
    • You must set a URI match condition in order to use transaction splitting.

HTTP Parameter: Match on HTTP parameter existence or a specific HTTP parameter value.

Header: Match on a specific HTTP header's (parameter's) existence or a specific HTTP header value.

  • Hostname: Match on the server hostname. Optionally click the gear icon to set a NOT condition.
  • Port: Match on the server port number. Optionally click the gear icon to set a NOT condition.
  • Class Name: Match on the ASP.NET class name. Optionally click the gear icon to set a NOT condition.
  • Cookie: Match on cookie existence or specific cookie value.
  • Hostname, Port, and Class Name options are non-functional in the .NET Agent 4.5.9 for Linux.

Split Custom ASP.NET Transactions

AppDynamics lets you further refine ASP.NET custom transaction names using transaction splitting.

  • To use transaction splitting, you must specify URI match criteria for the custom match rule.
  • The Split Transactions Using Request Data options work the like the automatic transaction detection configuration options described in URI Based Entry Points.

For example, you have a custom match rule named MyTransaction that matches the following URL: http://example.com/Store/Inventory?category=electronics. You can split the transaction on the parameter value as follows:

Split Transaction Using Request Data

The .NET Agent names the resulting transaction MyTransaction.electronics.

IIS Integrated Pipeline Instrumentation 

Full IIS pipeline instrumentation can be enabled by setting the node property: aspdotnet-full-iis-pipeline to true for the executing node. With this property enabled, regular ASP.NET instrumentation is disabled. When this mode is enabled, all managed HTTP modules, and handlers can be monitored by the .NET Agent. The aspdotnet-full-iis-pipeline mode is designed to work only for application pools configured to use IIS Integrated Pipeline.

When IIS pipeline instrumentation, as well as MVC area, or Controller naming is enabled, MVC naming will not be applied as it is a function of ASP.NET instrumentation. Also, with IIS pipeline instrumentation, each web request is tracked from the execution of the first HTTP module, or handler through to the end of the last, not only the ASP.NET application portion of the request.