POCO Entry Points

Certain types of applications, such as Windows Services or standalone applications, may not have entry points that are automatically detected by the .NET Agent.

For these cases, you can create custom match rules for Plain Old CLR Objects (POCOs). 

POCO Custom Match Rules Overview

To create a POCO custom match rule, define the custom match rule on the .NET class/method that is the most appropriate entry point for the business transaction. Someone who is familiar with your application code can help make this determination. You can also refer to the Custom Match Rules page.

You can optionally enable the Background Task option to have the transaction monitored as a background task. AppDynamics reports only Business Transaction metrics for background task transactions. It does not aggregate response time and call metrics at the tier and application levels for background tasks. See Monitor Background Tasks for more information.

After you create the rule, AppDynamics detects traffic on the matched entry point method and registers a business transaction for it, naming the transaction with the name of the custom match rule.  

By default, you have to wait one minute and then restart the application to apply instrumentation changes required for new POCO entry points. If you create an application-level POCO that applies to a tier that has not yet registered with the Controller, you may need to restart the application after the tier registers in order to see the business transaction.

You can enable Runtime Reinstrumentation for the .NET Agent so that you don't need to restart your application after instrumentation changes.

As an alternative to defining POCO entry points as described here, you can use the transaction discovery tool to create match rules based on discovered transactions. See Business Transaction Discovery Sessions.

The .NET Agent for Linux supports the configuration of simple POCO business transactions through the Controller UI. See .NET Agent for Linux Business Transaction Configuration

Define a POCO Entry Point

On an originating tier, a POCO entry point is the method that starts the business transaction. If the POCO entry point is on a downstream tier, it may correlate to an upstream exit point. When defining a POCO entry point, it is important to choose a method that begins and ends every time the business transaction executes. See Business Transactions.

Good candidates for POCO entry points include the following:

• A method in a socket application that executes every time a client connects.
• A loop in a standalone application that batch processes records via a web service call. For example, an expense reporting system that loops through approved expenses to submit them for reimbursement.
• A Windows service that regularly executes a database call to check for new jobs to process. In this example, the POCO entry point would be defined on the namespace JobProcessor, class JobProcessorCore and method ProcessJobs:

using System.Threading;
using System;
using System.Threading.Tasks;
using System.Configuration;
using System.Collections.Generic;

namespace JobProcessor {
    class JobProcessorCore {
        public void Process() {
            while(running) {
                ProcessJobs ();

				// run jobs again after 1 minute
				Thread.Sleep(60000);
            }
        }

		private void ProcessJobs() {
            var logic = new JobManagement ();
            var jobs = logic.GetJobs(); // Query Database for a list of jobs to process

            foreach (var job in jobs) {
                logic.ExecuteJob(job); // logic for executing a job
            }                 
        }
    }
}

Task-Based POCO Entry Point Methods

AppDynamics automatically tracks POCO transactions for asynchronous, Task-based method entry points as end-to-end transactions. End-to-end latency metrics reflect the time it takes to complete the asynchronous actions associated with such methods.  

To be tracked as an end-to-end transaction, the method you define as the POCO entry point must return a Task object and use the async modifier. In other words, the method signature should look similar to the following:  

public async Task<int> SearchBestPrice()
{
   ...
}

AppDynamics records the response times for such methods as it does for other types of methods—the response time reflects the time from when the method is called to when it returns control to the calling thread. However, for asynchronous task-based methods, AppDynamics records the time it takes for the asynchronous task to be fulfilled as an end-to-end transaction latency metric. 

For .NET Agents >= 20.3.0, time spent on asynchronous tasks is reported in average response time (ART) but not reported in the end-to-end latency metric.

See End-to-End Latency Performance.