You can apply best practices for the BT configuration to be a smooth and orderly process. This page explains the best practices about how to identify your application’s critical business transactions to get the most out of AppDynamics and your application and infrastructure.

  • Business Transaction naming and BT limit usage
    The default BT name is based on the first two segments of a URI. More URI or segments may result in the overflow of BTs and some of the useful BTs may fall under All other traffic - <tier>.

  For example, you want to monitor these URIs for /eCommerce/login:

    • /eCommerce/order
    • /eCommerce/checkout
    • /eCommerce/feedback

However, /order contains many URI patterns and if it uses more than two segments, then it may reach the 200 BT limit and might result in priority BT such as /eCommerce/checkout under All Other traffic - <tier> overflow BT. Additionally, /order results in many URIs that need to be monitored, (which are not required for the users):

    • /eCommerce/order/1/add
    • /eCommerce/order/list
    • /eCommerce/order/2/add

Therefore, instead of enabling the full URI for servlet naming, it is recommended that you use Custom Servlet rules for any specific full URI pattern to group the BTs and use the BT space limit more efficiently. Although you can increase the BT limit at the Controller level, you can use the Service Endpoint feature as another alternative.

  • Exclude BTs that are not required- Agent snapshots collection depends on the number of unique BTs in the BT list monitored from the target tier. Therefore, it is recommended to review the Business transactions list to check if any BTs listed as part of the auto-discovered transactions are not required. You can use the Exclude Transactions option to temporarily exclude such BTs. If you do not want to collect the snapshots but want only the KPI metrics, then you can monitor the BTs as Service Endpoint.

  • Use BT split and Service Endpoints- If there are too many variant results for BT naming, it is recommended that you do not use the split option for any entry point. If you need to use the split feature, then you should use the exclude result value in the split option. 

    Exclude split is only available for some entry points, such as Servlet and POJO.

    If you have many outputs for split, then you should use the split feature for Service Endpoint instead of BT.

  • Monitor the user transactions using the BT feature and know when to use Service Endpoints- Every BT has an associated snapshot or a call graph collection based on the periodic or slow thresholds, which results in additional data collection (call graph, request details, remote services, and so on). In addition to basic KPI (calls per minute, ART, errors per minute, slow or very slow calls) metrics data collected, if the requirement for any specific API or URI transaction is to only retrieve basic KPI metrics (but not the request details), and call graph is part of BT snapshot collection, then it is recommended that you monitor URI or API using the Service Endpoint feature. For example, when a user wants to know the response time of a particular API.
  • Monitor nested transactions with Service Endpoint due to the limitations in BTs- BT includes a snapshot collection feature in which all sub-calls are tracked as part of a single entry point API or URI that is part of the user transactions. For example: 

          CheckoutServletClass => OrderTransaction_WS|SOAP_EndPointAPI => JDBC Exit calls

  • If you need to monitor both CheckoutServletClass and OrderTransaction_WS API as separate BTs, then the BTs for OrderTransaction_WS are treated as a masked or child transaction of entry point CheckoutServletClass. 
  • The Service Endpoint (SEP) feature is best suited because the SEP does not have nested transaction limitations as in BT. You can monitor all sub-calls as separate endpoints to retrieve basic KPI metrics as in BT.
  • Use SEP drill down and BT snapshots - Though SEP does not specifically collect snapshots, you can see snapshots collected as part of the BT when the SEP dashboard for either the API or URI is part of the target snapshot. This provides users the benefit of snapshot level tracking of SEP if monitored SEP is part of the monitored BT sub calls.
  • Before you toggle entry points with auto-discovery disabled:
    • You must configure some settings for transaction detection rules for certain entry types (EJB or Spring), in which you must disable auto-discovery
    • If the user application is EJB or Spring based, then it is recommended that you define custom EJB or Spring-based rules instead of enabling the auto-discovery option in the "java auto-discovery rule" UI under the Transaction Detection tab.
  • Analyze which API or URI to monitor with the knowledge of the app code flow - You can use Service Endpoint auto-discovery for all entry points instead of the option for BT detection auto-discovery. This helps you capture which APIs are used by your application when the transactions occur. You determine which transactions to monitor as BT and which endpoints to monitor as SEP.