AppDynamics automatically detects requests to servlet-based entry points and generates business transactions based on the requests. For general information on how to customize automatic transaction detection, see URI Based Entry Points.

Frameworks Supported as Servlets or Servlets Filter

AppDynamics supports many web frameworks based on servlets or servlet filters. The servlet configuration settings in AppDynamics apply to these frameworks as well as to plain servlets. Frameworks include:

  • Spring MVC
  • Wicket
  • Java Server Faces (JSF)
  • JRuby
  • Grails
  • Groovy
  • Tapestry
  • ColdFusion

Custom Match Rules for Servlet Transactions

Custom match rule let you control how business transactions are generated for Servlet-based requests. 

Match Conditions

Match conditions can be based upon the URI, HTTP method, hostname, servlet name, or other characteristics of the request.

For HTTP Parameter conditions, you can add more than one. If you configure more than one HTTP Parameter match criteria, they must all be met by a request to be subject to this business transaction identification and naming rule, as must all conditions you configure for the rule.  

Some of the options have NOT conditions that you can choose to negate the configured condition. Choose this option in the gear icon next to the condition.

Splitting Transactions using Request Data or Payload

If you match by URI, you can have the transaction identified (or split) based on values from the request, such as URI patterns, request data, or payload. See URI Based Entry Points for information on naming or splitting transactions by the request elements.

When you create the rule, it appears in the Custom Match Rule list, where you can enable, disable, edit or remove the rule.

See Split Servlet Transaction by Payload Examples for use case examples.

POST Request Body Parameter Matching Considerations

You can configure Servlet-based custom match that match POST requests based on HTTP body parameter values. To avoid interfering with the operation of the application, the Java Agent applies some special processing measures and limits on how it accesses the body parameters. This behavior can affect whether requests can be matched by POST body parameters for your particular application. If you are having trouble configuring matching by HTTP parameter in POST requests, you should understand this behavior. 

Transaction Naming Match Criteria 

For transaction match criteria, match conditions for HTTP parameters work under these conditions:

  • If the parameter is a query string in the URL of the POST request, as opposed to the request body. 
  • If the Servlet Request body parameters have already been read and parsed by the application prior to the invocation of the servlet. A Servlet Filter, for example, may do this. 

Otherwise, custom servlet match rules do not match HTTP parameter values in POST requests.

Transaction Splitting 

For transaction split rules based on parameter matching in POST requests, the Java Agent defers transaction naming for incoming requests until the application servlet has accessed the request parameters.

The Java Agent considers the parameters "accessed" once the application invokes getParameterMap(), getParameter(), getParameterNames(), or getParameterValues() on the ServletRequest object. If the servlet does not call one of these methods, the agent will not apply the split rule and the transaction will not be named. 

Exclude Rules for Servlets

To prevent specific Servlet methods from being monitored, add a custom exclude rule. The controls for selecting Servlets to exclude are the same as those for custom match rules.