Business Transactions

A business transaction represents the end-to-end processing path used to fulfill a service request in the monitored environment.  When you connect agents to a Controller, the Controller automatically generates a list of business transactions based on the activity that the agents detect.

While the default business transaction list can bring you a long way towards having a useful list of services to monitor, you should review the list and make any adjustments needed based on your unique requirements and environment.

You can modify existing business transactions and the automatic detection settings used to generate them.  

Business Transaction Correlation

AppDynamics creates business transactions by detecting incoming requests at an entry point and tracking the activity associated with request at the originating tier and across distributed components in the application environment. A default detection scheme exists for each type of framework associated with an entry point (such as a Web Service). 

Consider, for example, the fictional ACME Online application. The application exposes a checkout service at http://acmeonline.example.com/checkout.  

A user request to the service triggers the following distributed processing flow and actions:

1. The business transaction entry point at the originating tier is /checkout URI, which is mapped to a Servlet called CheckoutServlet.
2. The request results in the originating tier invoking the createOrder method on a downstream tier, the inventory server.
3. The inventory tier application calls backend databases, exit points for the business transaction. The request context is maintained across tiers, including calls to backend tiers.
   
   
4. Any user request on the entry point is similarly categorized as this business transaction, the Checkout business transaction. 

To enable detection of all the components in a distributed business transaction, downstream agents must be at the same AppDynamics release or newer than upstream agents. This is true whether the tiers are all built on the same platform (for example all Java) or multiple platforms (a Node.js tier calling a Java tier, calling a .NET tier and so on).

Planning your Business Transactions

Refining your business transactions to best effect requires a solid understanding of the important business processes in your environment. Identify the 5 to 20 operations in the application that the teams who will be using AppDynamics consider to be the most important. These are the key operations that must work well for the application to be successful. Map those operations to their business transaction entry points. 

Important services can also be indicated by the number of calls or calls per minute received by the business transactions generated for the services. Accordingly, it may make sense to refine the transaction list by excluding seldom-used transactions and adding frequently invoked transactions manually or allowing them to be discovered.

You can add business transactions manually from a virtual business transaction called "All Other Traffic", which is populated with transactions once the business transaction registration limits are reached, as described below. 

Refining Business Transactions

At a high level, the steps for organizing and refining business transactions.

• Review the business transactions AppDynamics automatically discovered: As your application or business requirements change over time, you may find it helpful to review business transactions regularly to make sure your business transactions still reflect your changing application environment most effectively.
• Modify automatic discovery rules: While AppDynamics discovers many business transactions automatically, you may need to refine these mechanisms for additional transactions or to split transactions. For example, you may want to split a login request into two transactions based on whether the request branches to a new-user or existing-user operation. Other reasons to modify the automatic discovery criteria are: 
  
  • Add a rule for applications not automatically discovered, for example, for a framework that is not supported by default  
  • Combine business transactions 
  • Modify the default naming scheme for discovered business transactions
  • Exclude Business Transactions
• Rename business transactions: The Controller identifies discovered business transactions using default naming schemes that are specific to the type of technology. You can change the label associated with the name (or change the default naming patter for the discovery rule). Use the Action > Rename menu in the Business Transaction Dashboard or the Business Transaction List to give a user-friendly name to the transaction.
• Group business transactions: When multiple business transactions are similar and you want to roll up their metrics, you can put multiple business transactions into a group. You get metrics for each transaction and for the group as a whole. Grouping in the UI makes your lists and flowcharts easier to read by reducing visual clutter. 
• Delete unwanted business transactions: After you have modified the business transaction discovery configurations, you need to delete the old, unwanted business transactions. If you delete a transaction and you have not changed the configuration, it will be rediscovered. However, when you have revised the transaction discovery rules properly for what you want to see and then delete the unwanted business transaction, it won't be rediscovered.
• Lock down business transactions: After you have assembled the set of business transactions that you want to monitor based on detection refinements or manual changes, you can prevent additional changes from occurring automatically by locking down business transactions. This prevents changes to the list of business transactions due to application changes, upgrades to the agent software, or other changes in the monitored environment. See Business Transaction Detection. 

Business Transaction Limits

When reviewing and refining your business transaction limits, it's important to consider the business transaction limits for the Controller and app server agents. Business transaction limits prevent boundless growth of the business transaction list.  

The default limits are: 

• Business Application Limits: Each application is limited to 200 registered business transactions.
• App Server Agent Limits: Each agent is limited to 50 registered business transactions.

There is no limit at the tier level.

Also note that the app agent limit applies to each app agent, not to the machine. If you have multiple app agents on a single machine, the machine the business transactions originating from the machine could be up to the number of agents times 50.

For an on-premise Controller, it is possible to increase the default limits, but this should be done only in consultation with your AppDynamics representative. If changing business transaction limits or making other configuration change that can affect the agent, you need to carefully assess and monitor memory consumption by the agent. At a high level, assessing agent memory consumption involves these general steps: 

• After the agent discovers 50 transactions, compare the current memory footprint of the JVM or CLR with that of the agent.
• Then compare this data with the memory available for the agent.

About the "All Other Traffic" Business Transaction

What happens to additional business transactions once the limits are reached? Additional transactions—that is, what would be 51st detected business transaction for the agent or the 201st detected business transaction for the application—are collected in a sort of virtual business transaction named "All Other Traffic - tier_name" . As implied, there's an All Other Traffic collection for each tier on which the limit is reached. 

In addition to collecting transactions when the business transaction registration limit is reached, the "All Other Traffic" collects new business transactions detected after business transaction lock down is enabled. Business transaction lock down is an option you can enable to prevent additional changes from being made to the existing business transaction list as a result of business transaction detection.

If the 50 business transaction registration limit has not been reached yet for the agent and business transaction lock down is enabled, you can promote a transaction from the list of All Other Traffic by registering it from the Traffic Details window.

When refining business transactions, it's likely that you'll want to move certain transactions from the All Other Traffic bucket to make them first class business transactions. You can keep within the limits by deleting or excluding other business transactions, such as those that have little or no load, by using a custom exclude rule. 

The "All Other Traffic" business transactions appears alongside the other business transactions in the Business Transactions list. Like any business transaction, you can select an All Other Traffic business transaction in the Business Transactions list, view its dashboard, and see its key performance metrics in the Metric Browser. 

To view incoming calls categorized in the All Other Traffic transaction, open the dashboard for the All Other Traffic business transaction and click the View Traffic Details link. 

The Traffic Details window lists transaction entry points that were hit by incoming requests after the registration limits were exceeded or after business transaction detection was locked down. The Business Transaction Name column contains auto-generated names for the transactions. The Call column shows the number of instances of the transaction and the Type column shows the entry point type.

You can promote a particular transaction from the All Other Traffic collection to be a first class business transaction by finding the transaction in the Traffic Details window. For details, see Organize Business Transactions. 

If the Fetch more link appears, click it to see more calls. This results in up to 600 calls being retrieved each time you click the link. If the Fetch more link does not appear, there are no more calls to retrieve for the selected time range.