Not all business processing can be implemented using Web entry points for popular frameworks. Your application may perform batch processing in all types of containers. You may be using a framework that AppDynamics does not automatically detect. Or maybe you are using pure Java.

In these situations, to enable detection of your business transaction, configure a custom match rule for a POJO (Plan Old Java Object) entry point. The rule should be defined on the class/method that is the most appropriate entry point. Someone who is familiar with your application code should help make this determination. See Considerations for Defining a POJO Entry Point.

AppDynamics measures performance data for POJO transactions as for any other transactions. The response time for the transaction is measured from the POJO entry point, and the remote calls are tracked the same way as remote calls for a Servlet's Service method.

Considerations for Defining a POJO Entry Point

The POJO entry point is the Java method that starts the transaction.

The most important consideration in defining a POJO entry point is to choose a method that begins and ends every time the specific business transaction is invoked.

For example, consider the method execution sequence:

com.foo.threadpool.WorkerThread.run()
    calls com.foo.threadpool.WorkerThread.runInternal()
        calls com.foo.Job.run()

The first two calls to run() method are the blocking methods that accept a job and invoke it.

The Job.run() method is the actual unit of work, because Job is executed every time the business transaction is invoked and finishes when the business transaction finishes.

Methods like these are the best candidates for POJO entry points.

Defining a POJO Entry Point

To define a POJO Entry Point

1. Click Configure -> Instrumentation.

2. In the Transaction Detection tab select the tier.

3. Click Use Custom Configuration for this Tier.

4. Scroll down to the Custom Rules panel and click Add (the plus sign).

5. From the Entry Point Type dropdown menu select POJO and click Next.

6. In the New Business Transaction Match Rule - POJO window set the criteria for identifying the entry point.

7. Save the configuration.

If you are running on IBM JVM v1.5 or v1.6, you must restart the JVM after defining the custom match rules.

You may optionally refine the naming of a POJO-based transaction by transaction splitting.

See the following sections for examples:

• Defining an Entry Point for a Method Using the Fully-Qualified Class Name
• Defining an Entry Point for a Method Using a Superclass
• Defining an Entry Point for a Method Using an Interface
• Defining an Entry Point for a Method Using Annotations
• Identify a POJO Transaction as a Background Task

See also Custom Match Rules.

Defining an Entry Point for a Method Using the Fully-Qualified Class Name

For the class named "Foo" and method doWork(), match on the fully-qualified class name and method name:

After you define and save the custom match rule for the POJO transaction, performance data for it displays in the Business Transactions List.

The name of the POJO-based business transaction is the name of the custom match rule or entry point definition.

In the example above. AppDynamics shows that the "doWork" method of class "Foo" was invoked 260 times and had an average response time of 678 ms (for the selected time range). Out of the total invocations, 62 invocations were slow and 22 invocations were very slow (these slow or very slow identification is based on the thresholds set for the business transaction).

class A
{

    public void m1();

    public void m1(String a);

    public void m1(String a, com.mycompany.MyObject b);

}

Defining an Entry Point for a Method that Extends a Super Class

For example, the entry point is based on the com.acme.AbstractProcessor super class, which defines a process() method, which is extended by its child classes: SalesProcessor, InventoryProcessor, BacklogProcessor.

Define the custom rule on the method defined in the super class:

Defining an Entry Point for a Method Using an Interface

Define a custom rule matching on an interface named com.acme.IProcessor, which defines a process() method that is implemented by the SalesProcessor, InventoryProcessor, BacklogProcessor classes.

Defining an Entry Point for a Method Using Annotations

For example, if all processor classes are annotated with "@com.acme.Processor", a custom rule should be defined using annotation.

By default, in these cases the business transaction started when any process() is invoked is named Process, based on the name of the custom rule. To refine the transaction name to reflect the specific method called (Process.SalesProcessor, Process.InventoryProcessor, Process.BacklogProcessor) use transaction splitting.

Dynamically Identifying POJO Transactions Using Transaction Splitting

By default, when you create a custom match rule for POJO transactions, all the qualifying requests are identified by the name of the custom match rule.

However, in many situations it is preferable to split POJO-based transactions, especially for nodes that execute scheduled jobs.

For example, if multiple classes have the same method and are instrumented using the same rule, when the method is invoked the class name of the instance being invoked can be used to classify the request.

If you split the transaction based on the simple class name, instead of one business transaction named Process, the transaction that is started when the process() method is invoked is named based on the rule name combined with the class name: either Process.SalesProcessor, Process.InventoryProcessor, or Process.BacklogProcessor.

Defining an Entry Point based on a Parameter Value

In some cases you want to split the transaction based on the value of a parameter in the entry point method. For example, you could configure the split on the following process() method:

public void process(String jobType,String otherParameters...)

where the jobType parameter could be Sales, Inventory or Backlog.

You can name POJO transactions dynamically using the following mechanisms:

• method parameter
• POJO object instance
• fully qualified class name
• simple class name
• thread ID
• thread name
• method name
• simple class name and method name
• full class name and method name

In all cases, the name of the rule is prepended to the dynamically-generated name to form the business transaction name.

To configure transaction splitting

1. In the Transaction Splitting tab of the New Business Transaction Match Rule - POJO window, click Split POJO Transactions using one of the following mechanisms...

2. Click the mechanism to use to split the transaction.

• If you are specifying a method parameter, enter the zero-based parameter index of the parameter.
• If the parameter is a complex type, specify the getter chain to use used to derive the transaction name.
• If you are specifying a POJO object instance, specify the getter chain. See Getter Chains in Java Configurations.

3. Click Save.

Using a Method parameter for dynamically naming the transactions

Suppose in the ACME Online example, instead of the super-class or interface, the type of the processing is passed in as a parameter.

For example:

public void process(String jobType,String otherParameters...)

In this case, it would be appropriate to name the transaction based on the value of Job type. This Job type is passed as the parameter.
To specify a custom rule for method parameter:

1. Specify the details for the custom rule in the Transaction Match Criteria tab.

2. Click the Transaction Splitting tab.

3. Click Split POJO Transactions using one of the following mechanisms...

4. Select the option for the method parameter.

5. Specify the details for the parameters.

You can use a getter chain if the parameter is of complex type in order to derive a string value, which can then be used for the transaction name. See Getter Chains in Java Configurations.

Exclude Rules for POJO Transactions

To prevent configured transaction splitting from being applied in certain situations, create an exclude rule defined on the output of the transaction splitting.

Identifying a POJO Transaction as a Background Task

When you want to specify that a POJO transaction is a background task, check Background Task.

When a request runs as a background task, AppDynamics reports only Business Transaction metrics for the request. It does not aggregate response time and calls metrics at the tier and application levels for background tasks. This is ensures that background tasks do not distort the baselines for the business application. Also, you can set a separate set of thresholds for background tasks. See Monitor Background Tasks.

Learn More

Identify Transactions Based on POJO Method Invoked by a Servlet