1. User's Guide
  2. Key Concepts
  3. Business Transaction Monitoring Metrics

Business Transaction Monitoring Metrics

BTM helps you understand and manage the performance of your transaction processing system. Transaction response times give a sense of the performance of your services and environments, and can indicate potential or actual issues. BTM can help you profile use, identify issues related to performance, and investigate the cause of failing components in a business process.

Transactions are typically business functions, such as running the monthly payroll for a company. Each transaction is a sequence of operations that you want to monitor as a single unit. Where the user completes some or all of these operations, the transaction is a user interaction. Where all operations are completed without user input, the transaction is a batch job. Oracle Pulse provides users with separate reports for Oracle® E-Business Suite and PeopleSoft batch jobs, while continuing to support user interactions. Moreover, Oracle Pulse analyzes and monitors the status and health of the targets the Oracle Service-Oriented Architecture (SOA) suite runs on.

Note:

The Transactions dashboard is displayed in the navigation menu only for services where BTM has been enabled.

If BTM has not been enabled, the Transactions dashboard is hidden at the Customer and Service levels.

BTM metrics are sourced from Oracle® Enterprise Manager, which, in turn, interrogates the supported Oracle applications. BTM supports Oracle® E-Business Suite and PeopleSoft batch jobs, which are taken from Oracle® E-Business Suite and PeopleSoft.

Oracle Pulse can be configured to report on specific targets that Oracle® Enterprise Manager monitors. Your Oracle Service Delivery Manager (SDM) can work with you to set up and identify your key business transactions for monitoring.

About Transaction Metrics in Oracle Pulse

The Pulse Dashboard provides an overview of the stability and performance metrics for all your organization's services at application, data center (both local and remote), batch and customer center level.

Stability metrics are calculated based on the most recent capture of the concurrent manager metrics for the customer's Oracle® E-Business Suite environments or for any of the PeopleSoft schedulers that manage jobs monitored by Oracle Pulse. Stability uses the last execution of the BTM login transaction successfully executed to completion to indicate whether the service application is available to the users. For batch transactions, stability indicates if the concurrent manager(s) and/or processor monitor(s) are running as expected and within the defined thresholds.

Performance metrics for Oracle® E-Business Suite concurrent managers and PeopleSoft schedulers are calculated based on the two most recent data captures for any job monitored by Oracle Pulse. Performance indicates if the transactions executed for the service from the selected beacon execute within the tolerance of the BTM defined metrics (i.e., median value) or within the defined warning thresholds for batch transactions. The indicator for performance alters once two concurrent transactions executions both exceed the transaction median value.

The Transactions dashboard at Customer Level shows all the transactions for your organization's services, providing separate reports for User Experience by Location, Oracle® E-Business Suite and PeopleSoft. You can filter the transactions displayed by transaction type: EBiz Suite batch job, PeopleSoft batch job, or user interaction. Each transaction record links to more detailed reports of recent and historical metrics.

Similarly, the Transactions dashboard at Service Level provides both summaries and detailed metrics reports for all batch jobs and user interactions associated with the service. Finally, the Transactions dashboard summarizes all transaction information for the selected environment.

About Batch Jobs

Processed as a series of concurrent programs, batch jobs are data-intensive and long running. They are typically run asynchronously, when users are least active on the system. Each request to run an immediate or scheduled batch job transaction as a concurrent program is known as a concurrent request. The request usually includes start and end dates, and the frequency of resubmission if the request is recurring. For each concurrent request, BTM measures the time from when the environment's start message is observed until its end message is observed. This is the response time for the concurrent request.

Note:

The terms batch job and concurrent program are used interchangeably in Oracle Pulse.

To help you evaluate the performance of batch job transactions, Oracle Pulse collects both the max runtime and the avg runtime for the batch job transaction for all collected data from Oracle® E-Business Suite or PeopleSoft. The max runtime is the maximum time taken to run the batch job transaction from all runs recorded. The avg runtime is the mean time the batch job took to complete. All completed requests are counted in the response time, regardless of whether condition alerts occurred. If the batch job response approaches or exceeds the maximum runtime, or if the average runtime is higher than expected, further investigation is needed.

You can use Oracle Pulse to identify anomalies in concurrent program runs, and when and why these anomalies occurred. Open the detailed reports to review information about the Oracle® E-Business Suite or PeopleSoft job systems - that is, the Oracle® E-Business Suite or PeopleSoft environment running the batch jobs. Such information include the longest running concurrent requests currently running in the Oracle® E-Business Suite job system, the jobs in alert state at a particular point in time, and the jobs in alert state within the 7 days preceding the last data collection for your PeopleSoft job system, as well as the jobs currently queued in the PeopleSoft job system.

Historical reports for the Oracle® E-Business Suite job systems show the longest running concurrent programs or the concurrent program with the highest count of requests, during any 24-hour interval from the specified date, while historical reports for the PeopleSoft job systems show the number of job requests of various statuses within the last 24 hours.

BTM also tracks the phase and status of all ongoing and historical monitored concurrent requests, helping you identify performance or runtime issues with monitored Oracle® E-Business Suite or PeopleSoft batch job requests that are running or were run over the reported interval (the last hour, the last 24 hours, or the last 31 days).

Historical reports for the Oracle® E-Business Suite jobs can be filtered to show concurrent request behavior for any 24-hour interval. You can open a list of all monitored concurrent requests, of the requests that completed with errors (Requests Completed with Error filter) or warnings (Requests Completed with Warning filter), of the requests that were in pending phase (Pending Requests filter) or that spent longer than expected in pending state (Long Pending Requests filter), or you can review all requests that completed successfully (Requests Completed Successfully filter).

About User Interactions

In contrast, user interaction transactions are evaluated on performance time only. BTM records the time that the last set of operations comprising the user interaction takes to complete. This is the last response time for the transaction.

For user interaction transactions, BTM compares the last response time with the 30-day average runtime. This value is the running average of all runtimes recorded for an user interaction over the preceding 30 days. All completed runs are counted in the response time. BTM also shows the difference between the transaction's last response time and the agreed threshold. The threshold is the longest acceptable response time for the user interaction. It is defined in Oracle® Enterprise Manager in consultation with your Oracle SDM.

To analyse the performance of any user interaction, open the detailed report. The performance chart compares the response time for an user interaction against both the threshold and the historical median. The historical median is the value lying at the midpoint of the range of response times measured. Flip to the table view to see the values underlying the chart.

The details in the Sustained Stress tab assist the user in identifying impactful performance degradation on key business transactions, and identify the possible causes of that degradation, enabling faster resolution times. The chart in this tab highlights periods of performance degradation where the response times of the transaction are trending significantly above or below the normal response times for that transaction over a sustained period. These periods of sustained stress are correlated with events (including change requests, service requests, and functional events) that have occurred around and during the identified stress period, as these are possible contributors to the performance degradation itself.

About LTM Transactions

Login Transaction Management (LTM) transactions are now part of the core Oracle services monitoring setup for production applications. The goal of LTM transactions is to detect application access issues that may arise in relation to infrastructure components, capacity, performance, and access.

Using a restricted-access user account, an LTM transaction simply logs into the application home page and immediately logs out - this simple action allows the LTM transaction to track the aforementioned issues. LTM transactions are expected to have no impact on the capacity or performance of the production environment. For more information on LTM transactions, please contact your Service Delivery Manager.

About SOA Services

Oracle Service-Oriented Architecture (SOA) services provide connectivity between applications deployed in a service-oriented architecture. Connectivity between these services is essential for a business to continue to run effectively and support its goals.

Composite applications, also referred to as composites, are software applications built by combining multiple existing functions into a new application. The composite target is made up of building blocks that you use to construct a SOA composite application, called service components (BPEL process, business rule, human task, spring, and mediator).

Use Oracle Pulse to analyze the status of the targets the SOA suite runs on, and to pro-actively monitor the health of composites (status, usage and other metrics), which plays an important part in foreseeing and understanding the growth and impact of composites on performance and storage. Moreover, Oracle Pulse can also report on the status of SOA composites, which further allows you to maintain data synchronization and minimize any potential delta between the systems. For example, for intensively used composites, when a high level of audit logging is set for a set of composites in order to maintain error, warning and other details, this may mean that a high volume of data is kept in the database. Insufficient log purging activity can cause major performance issues and storage space issues, affecting further activities in the service.

SOA composites can be deployed into separate sections of the SOA infrastructure, known as partitions. Deploying to partitions enables you to logically group SOA composites and perform bulk lifecycle management tasks on all SOA composite applications within a specific partition.The smooth and timely interaction between integration points in a SOA service is critical to the success of overall business process flows. The BTM functionality in Oracle Pulse provides the ability to:

  • view SOA composite health and diagnostic information

  • get early visibility to allow the timely resolution of incidents

  • understand trend data related to SOA interfaces, which ensures better insight into the overall business process volumetrics, and provides data insights into areas that are performing outside expected norms