500-420 Business Transactions

Business Transactions Detailed Explanation

What are Business Transactions?

• Business Transactions (BTs) represent specific user interactions or workflows in your system.
• Each transaction reflects how a user interacts with your application. For example:
  • Logging in to a website.
  • Adding an item to the shopping cart in an e-commerce store.
  • Submitting a payment.

By focusing on Business Transactions, you can monitor how well critical parts of your application perform from the user's perspective.

Transaction Components

Business Transactions consist of multiple components. These work together to form a complete transaction flow:

1. Entry Point

• The starting point of a transaction.
• Common entry points include:
  • HTTP Requests: A web request made by a user (e.g., clicking a "Buy Now" button).
  • Message Queues: A system that handles background tasks (e.g., order processing via a message broker).
  • Web Service Calls: Requests from other systems to your application (e.g., API calls).

2. Backend Dependencies

• Backend Dependencies are the systems or services a transaction relies on to complete its process.
• Examples:
  • Database Calls: Retrieving user details or product information.
  • Caching Services: Fetching data from a cache like Redis to speed up response times.
  • Remote API Invocations: Interacting with external systems, such as payment gateways.

3. Outbound Calls

• Outbound Calls are requests sent to external systems by your transaction.
• Examples:
  • Calling a third-party API to check product availability.
  • Sending an email confirmation via an external mail service.

Types of Transactions

AppDynamics provides flexibility in identifying and managing transactions.

1. Auto-detected Transactions

• AppDynamics automatically detects common transaction types without requiring manual configuration.
• Examples:
  • HTTP Requests to web servers.
  • Calls to known frameworks or APIs like Spring Boot, .NET MVC, or Java Servlets.

2. Custom Transactions

• Users can define specific transactions that are important for their business.
• Examples:
  • Grouping all API calls for "payment processing" under a single transaction.
  • Monitoring a custom entry point, such as a non-standard protocol or message format.
• Why Use Custom Transactions?
  • Allows greater control and focus on critical business workflows.
  • Helps eliminate noise by excluding unimportant transactions from monitoring.

Monitored Data

AppDynamics tracks several key metrics for each Business Transaction to provide insights into application performance.

1. Transactions per Second (TPS)

• Measures the throughput of your application by tracking the number of transactions processed per second.
• Why it’s important:
  • Helps identify peak load periods and ensures the system can handle expected traffic.
  • For example, during a flash sale, TPS may spike, potentially revealing bottlenecks.

2. Transaction Response Time

• Measures how long a transaction takes to complete from start to finish.
• Why it’s important:
  • Helps identify slow transactions.
  • For example, if adding an item to the cart takes 5 seconds instead of 1 second, it might frustrate users and lead to abandonment.

3. Transaction Error Rate

• Tracks the percentage of transactions that fail due to errors.
• Why it’s important:
  • Identifies problem areas in the application.
  • For example, a high error rate during checkout might indicate issues with payment gateway integration.

Optimizing Transactions

Once you’ve identified issues using AppDynamics’ transaction monitoring, optimization becomes the next step.

1. Optimize Code Paths

• What it means:
  • Review and streamline the sequence of steps in a transaction to eliminate unnecessary logic or delays.
• How to do it:
  • Use Snapshots to find methods or processes that take longer than expected.
  • Example: If a product search transaction spends too much time in a filtering loop, refactor the code to improve efficiency.

2. Minimize External Calls

• What it means:
  • Reduce the number of calls to external systems or make them asynchronous to avoid delays.
• How to do it:
  • Identify slow external dependencies using Flow Maps.
  • Implement caching for frequently requested data.
  • Switch synchronous API calls to asynchronous ones where possible.
• Example:
  • Replace repeated database lookups for user permissions with a cache system.

3. Set Transaction Thresholds

• What it means:
  • Define acceptable performance limits for key metrics, such as response time or error rate.
• How to do it:
  • Use Health Rules in AppDynamics to set thresholds for transactions.
  • Trigger alerts when thresholds are breached so you can take immediate action.
• Example:
  • If a transaction's response time exceeds 3 seconds, send an alert to the operations team.

Example Scenario: Monitoring a Checkout Process

Let’s consider an example to tie it all together:

1. Identify the Business Transaction:

   • The "Checkout" process is defined as a transaction starting from when a user clicks "Proceed to Checkout" and ending when the payment is confirmed.

2. Break Down Components:

   • Entry Point: HTTP Request for the "Checkout" page.
   • Backend Dependencies:
     • Database call to fetch cart details.
     • API call to calculate shipping costs.
   • Outbound Calls:
     • Third-party payment gateway API.

3. Monitor Metrics:

   • Use AppDynamics to monitor TPS, response time, and error rate.
   • For example:
     • TPS during peak hours shows 200 transactions per second.
     • Response time averages 2 seconds, but occasionally spikes to 10 seconds due to database delays.

4. Optimize:

   • Optimize slow database queries by adding indexes.
   • Cache shipping cost calculations to reduce API dependency.

Summary

Business Transactions provide a user-centric view of your application’s performance. By monitoring key metrics such as TPS, response time, and error rate, and by optimizing transactions through code improvements, external dependency reduction, and alert thresholds, you can ensure smooth application functionality and a positive user experience.

Business Transactions (Additional Content)

1. Business Transaction (BT) Naming and Grouping Best Practices

Business Transactions are a core concept in AppDynamics, representing critical user workflows. However, without consistent naming and grouping, BTs can become difficult to manage or interpret—especially in complex applications.

a. Why Naming Matters

• In AppDynamics, each Business Transaction is represented in the Controller UI with a unique name.

• If naming is too generic, such as simply "GET /service", or "POST /api", then:

  • It becomes difficult to differentiate between real business activities.

  • Multiple unrelated transactions might appear under a single name, obscuring performance patterns.

b. Best Practices for Naming BTs

Practice	Description
Be specific	Include meaningful identifiers (e.g., /checkout, /login, /addToCart)
Reflect business intent	Use names that describe user actions, not just technical routes
Use segments or parameters when appropriate	Configure AppDynamics to use URL segments, request payload, or headers for naming
Avoid dynamic values	Do not use IDs or timestamps in BT names, as this can cause BT explosion (too many unique BTs)

c. Custom BT Naming Rules

• AppDynamics allows you to define Custom Match Rules:

  • Match based on URL patterns, HTTP parameters, Java method signatures, etc.

  • Set custom names like "Payment Submission" or "Shipping Calculator"

• This helps organize BTs by functional domain rather than technical specifics.

Example:

Instead of having a BT named:

• POST /api/v1/order/submit/8430293

Use a naming rule to generalize it as:

• POST /api/v1/order/submit → "Order Submission"

2. Excluding Unimportant Business Transactions

AppDynamics automatically detects many BTs, including some that may not be useful for performance monitoring. If left unchecked, low-value, high-frequency BTs can pollute your data and consume license resources.

a. Why Exclude BTs?

• To reduce data noise and storage consumption

• To keep the BT list focused on meaningful user journeys

• To improve Controller performance

• To stay within BT count limits defined by your license

b. Examples of BTs to Exclude

• Health check pings (e.g., /ping, /status)

• Static content or resource requests (e.g., /favicon.ico, /robots.txt)

• Third-party monitoring requests

• Background system calls with no direct user impact

c. How to Exclude BTs

• Use BT Exclusion Rules in the AppDynamics Controller:

  • Define rules by HTTP method, URI, headers, or parameters

  • Choose to drop, rename, or group unwanted BTs under a common name like “Excluded Transactions”

• You can also limit automatic detection by setting a threshold (e.g., only detect the top 50 BTs by volume)

Example:

You notice that /heartbeat is being detected as a BT and triggered every 5 seconds.
Exclude it using a BT exclusion rule based on the URI path to prevent unnecessary monitoring.

Summary of Best Practices

Practice Area	Best Practice Description
BT Naming	Be specific, use business-aligned names, avoid dynamic values
BT Grouping	Use custom rules to group similar transactions logically
BT Exclusion	Exclude high-frequency, low-value BTs (e.g., pings, static files)
Result	Cleaner dashboards, focused troubleshooting, and better resource usage