Your integration server is processing thousands of messages per hour across dozens of flows. Everything seems fine—until your business stakeholders ask a simple question: "Which of our integration flows are performing well, and which ones need attention?"

You check your monitoring tools. They show server-level metrics: CPU usage, memory consumption, network throughput. All healthy. But they don't answer the actual question: How is each individual message flow performing? Which flows have high error rates? Where are the bottlenecks?

What if you could simply ask your integration server, "Show me how all my flows are performing right now," and get an instant, comprehensive answer? What if monitoring integration performance was as simple as making an Admin REST API call?

That's exactly what the Statistics Summary API delivers.

Introduction

When your integration server is processing thousands of messages, knowing which flows are healthy and which are struggling is the difference between proactive and reactive operations. IBM App Connect Enterprise (ACE) has introduced a new capability that revolutionizes how developers and administrators monitor integration performance: the Statistics Summary API.

This Admin REST API provides aggregated, real-time statistics about message flow execution, enabling you to gain instant visibility into your integration server's performance.

What is the Statistics Summary API?

The Statistics Summary API is a lightweight Admin REST API that exposes aggregated performance metrics for message flows running in your ACE integration server. Unlike traditional statistics collection that writes data to files such as CSV, MQ, user trace etc, the Summary API maintains statistics in memory and makes them instantly accessible through simple HTTP requests.

Key Features

Multi-Level Visibility: Access statistics at multiple hierarchical levels:

• Server Level: View aggregated statistics for all message flows across the entire integration server.
• Resource Level: Filter by specific applications, services, or REST APIs.
• Message Flow Level: Drill down to individual flows within a resource.
• Library Level: Access flows deployed within shared libraries.

Real-Time Data: Statistics are collected and aggregated in memory as messages flow through your integrations, providing up-to-the-second performance insights without file I/O overhead.

Comprehensive Metrics: Each summary record includes:

• Flow-level metrics: Message throughput, timing statistics (elapsed time, CPU time, min/max/total), error counts, and transaction metrics (commits, backouts).
• Node-level metrics: Performance breakdown for each node in the flow, including invocation counts and processing times.

Dynamic Configuration: Enable or disable statistics collection on-the-fly using Admin REST API PATCH operations without restarting your integration server.

Accounting Origin Support: Statistics are automatically segmented by accounting origin, allowing you to distinguish performance data across different message sources, business contexts, or client types within the same flow. Each summary record carries an AccountingOrigin field, making it straightforward to compare how a flow performs for different categories of traffic.

Configuration

The Summary API is configured through your server.conf.yaml file under the Statistics section:

Using the Statistics Summary API

Accessing Statistics

The API integrates seamlessly with ACE's existing Admin REST API structure. The Summary API is available at multiple levels, giving you flexibility to query exactly the scope you need:

Server-Level Statistics

Behavior: Returns aggregated statistics for all message flows across the entire integration server, regardless of application, service, or REST API.

Application-Level Statistics

Behavior: Returns statistics for all message flows within the specified application.

REST API-Level Statistics

Behavior: Returns statistics for all message flows within the specified REST API.

Service-Level Statistics

Behavior: Returns statistics for all message flows within the specified service.

MessageFlow-Level Statistics

Behavior: Returns detailed statistics for a single message flow within an application.

REST API Message Flow Statistics

Behavior: Returns detailed statistics for a single message flow within a REST API.

Service Message Flow Statistics

Behavior: Returns detailed statistics for a single message flow within a service.

Library-Level Statistics

Behavior: Returns detailed statistics for message flows deployed within shared libraries, accessed through their parent application, REST API, or service context.

This hierarchical structure allows you to navigate from broad server-wide views down to individual flows, whether they're deployed directly or within libraries. Each level provides progressively detailed information, enabling you to quickly zoom in on problem areas.

Dynamic Configuration Updates

You can enable or disable statistics collection without restarting your server using a PATCH request. The PATCH API supports two properties:

Available Properties:

• summaryOn: Controls whether summary statistics are collected and stored in memory.
  • "active" — enables in-memory statistics collection.
  • "inactive" — disables collection. Default: "active".
    
    
• clearRecordsOnStop: Determines what happens to accumulated statistics when a statistics collection is stopped, or when the flow itself is stopped, undeployed, or deleted.
  • true (default) — all statistics for that flow are cleared from memory, ensuring a clean slate when collection resumes.
  • false — statistics are preserved in memory, so you can still view the data recorded before the stop.

Accounting Origin Configuration

Accounting origin for summary statistics is activated when any one of the active Statistics Accounting Origin settings for a flow is set to basic, or you can configure it via the PATCH API of active statistics.

To set up accounting origin in the flow, refer to: IBM Documentation of Accounting origin

How It Works: Statistics Lifecycle

This section walks through a real example and explains how the different lifecycle events affect what you see in the API response.

A Worked Example: Identifying a Performance Bottleneck in Order Processing

Imagine a retail company that processes all internal purchase orders through a single ACE integration flow — ESQLPerfTestFlow. Orders from every department hit the same HTTP endpoint and pass through the same pipeline. The operations team is seeing occasional slowdowns but can't tell where in the flow the delays are occurring or whether certain types of requests are worse than others.

The flow has four nodes as shown in the image below:

What this flow does: Messages enter via the HTTP Input node and are passed through two sequential Compute nodes before a reply is sent.

The first Compute node (Compute) simulates a periodic heavy operation — every 50th message it introduces a 20-second delay, representing something like a slow downstream call or a blocking cache refresh. It also stamps the DepartmentName from each incoming JSON request as the accounting origin, so the Summary API automatically tracks Finance, Sales, and anonymous requests as separate records within the same flow.

The second Compute node (Compute1) handles a lighter secondary operation — every 25th message it introduces a 2-second delay, representing a periodic lighter operation such as a cache lookup or secondary validation.

This makes ESQLPerfTestFlow a realistic stand-in for any integration flow where processing cost is uneven across requests — the heavy spike in Compute dominates the flow's MaximumElapsedTime, while Compute1 contributes a steady secondary cost visible in its own node-level timing.

Response Format

The API returns JSON-formatted data with a consistent structure. Each response contains a count field indicating the number of records, and a records array where each entry represents statistics for a distinct accounting origin within the same flow.

{
    {
    "name": "Summary",
    "type": "Summary",
    "uri": "http://localhost/apiv2/applications/ESQLPerfStat_HTTP/messageflows/ESQLPerfStat_HTTPFlow/statistics/summary",
    "count": 3,
    "records": [
        {
            "WMQIStatisticsAccounting": {
                "RecordType": "Summary",
                "RecordCode": "Summary",
                "MessageFlow": {
                    "BrokerLabel": "integration_server",
                    "BrokerUUID": "",
                    "ExecutionGroupName": "TEST_SERVER2",
                    "ExecutionGroupUUID": "00000000-0000-0000-0000-000000000000",
                    "MessageFlowName": "ESQLPerfStat_HTTPFlow",
                    "MessageFlowURI": "/apiv2/applications/ESQLPerfStat_HTTP/messageflows/ESQLPerfStat_HTTPFlow",
                    "ApplicationName": "ESQLPerfStat_HTTP",
                    "StartDate": "2026-07-23",
                    "StartTime": "15:16:57.883579",
                    "GMTStartTime": "2026-07-23T09:46:57.883+00:00",
                    "EndDate": "2026-07-23",
                    "EndTime": "15:35:10.601417",
                    "GMTEndTime": "2026-07-23T10:05:10.601+00:00",
                    "TotalElapsedTime": 0,
                    "MaximumElapsedTime": 0,
                    "MinimumElapsedTime": 0,
                    "TotalCPUTime": 0,
                    "MaximumCPUTime": 0,
                    "MinimumCPUTime": 0,
                    "CPUTimeWaitingForInputMessage": 3380,
                    "ElapsedTimeWaitingForInputMessage": 1041385197,
                    "TotalInputMessages": 0,
                    "TotalSizeOfInputMessages": 0,
                    "MaximumSizeOfInputMessages": 0,
                    "MinimumSizeOfInputMessages": 0,
                    "NumberOfThreadsInPool": 1,
                    "TimesMaximumNumberOfThreadsReached": 0,
                    "TotalNumberOfMQErrors": 0,
                    "TotalNumberOfMessagesWithErrors": 0,
                    "TotalNumberOfErrorsProcessingMessages": 0,
                    "TotalNumberOfTimeOutsWaitingForRepliesToAggregateMessages": 0,
                    "TotalNumberOfCommits": 0,
                    "TotalNumberOfBackouts": 0,
                    "AccountingOrigin": "Anonymous"
                },
                "NumberOfNodes": 4,
                "Nodes": [
                    {
                        "Label": "Compute",
                        "Type": "ComputeNode",
                        "TotalElapsedTime": 0,
                        "MaximumElapsedTime": 0,
                        "MinimumElapsedTime": 0,
                        "TotalCPUTime": 0,
                        "MaximumCPUTime": 0,
                        "MinimumCPUTime": 0,
                        "CountOfInvocations": 0,
                        "NumberOfInputTerminals": 1,
                        "NumberOfOutputTerminals": 6
                    },
                    {
                        "Label": "Compute1",
                        "Type": "ComputeNode",
                        "TotalElapsedTime": 0,
                        "MaximumElapsedTime": 0,
                        "MinimumElapsedTime": 0,
                        "TotalCPUTime": 0,
                        "MaximumCPUTime": 0,
                        "MinimumCPUTime": 0,
                        "CountOfInvocations": 0,
                        "NumberOfInputTerminals": 1,
                        "NumberOfOutputTerminals": 6
                    },
                    {
                        "Label": "HTTP Input",
                        "Type": "WSInputNode",
                        "TotalElapsedTime": 0,
                        "MaximumElapsedTime": 0,
                        "MinimumElapsedTime": 0,
                        "TotalCPUTime": 0,
                        "MaximumCPUTime": 0,
                        "MinimumCPUTime": 0,
                        "CountOfInvocations": 0,
                        "NumberOfInputTerminals": 0,
                        "NumberOfOutputTerminals": 4
                    },
                    {
                        "Label": "HTTP Reply",
                        "Type": "WSReplyNode",
                        "TotalElapsedTime": 0,
                        "MaximumElapsedTime": 0,
                        "MinimumElapsedTime": 0,
                        "TotalCPUTime": 0,
                        "MaximumCPUTime": 0,
                        "MinimumCPUTime": 0,
                        "CountOfInvocations": 0,
                        "NumberOfInputTerminals": 1,
                        "NumberOfOutputTerminals": 2
                    }
                ]
            }
        },
        {
            "WMQIStatisticsAccounting": {
                "RecordType": "Summary",
                "RecordCode": "Summary",
                "MessageFlow": {
                    "BrokerLabel": "integration_server",
                    "BrokerUUID": "",
                    "ExecutionGroupName": "TEST_SERVER2",
                    "ExecutionGroupUUID": "00000000-0000-0000-0000-000000000000",
                    "MessageFlowName": "ESQLPerfStat_HTTPFlow",
                    "MessageFlowURI": "/apiv2/applications/ESQLPerfStat_HTTP/messageflows/ESQLPerfStat_HTTPFlow",
                    "ApplicationName": "ESQLPerfStat_HTTP",
                    "StartDate": "2026-07-23",
                    "StartTime": "15:34:14.270415",
                    "GMTStartTime": "2026-07-23T10:04:14.270+00:00",
                    "EndDate": "2026-07-23",
                    "EndTime": "15:34:43.474727",
                    "GMTEndTime": "2026-07-23T10:04:43.474+00:00",
                    "TotalElapsedTime": 24047600,
                    "MaximumElapsedTime": 22000890,
                    "MinimumElapsedTime": 318,
                    "TotalCPUTime": 47874,
                    "MaximumCPUTime": 3527,
                    "MinimumCPUTime": 312,
                    "CPUTimeWaitingForInputMessage": 14417,
                    "ElapsedTimeWaitingForInputMessage": 3103847,
                    "TotalInputMessages": 60,
                    "TotalSizeOfInputMessages": 29022,
                    "MaximumSizeOfInputMessages": 484,
                    "MinimumSizeOfInputMessages": 482,
                    "NumberOfThreadsInPool": 1,
                    "TimesMaximumNumberOfThreadsReached": 60,
                    "TotalNumberOfMQErrors": 0,
                    "TotalNumberOfMessagesWithErrors": 0,
                    "TotalNumberOfErrorsProcessingMessages": 0,
                    "TotalNumberOfTimeOutsWaitingForRepliesToAggregateMessages": 0,
                    "TotalNumberOfCommits": 0,
                    "TotalNumberOfBackouts": 0,
                    "AccountingOrigin": "Finance"
                },
                "NumberOfNodes": 4,
                "Nodes": [
                    {
                        "Label": "Compute",
                        "Type": "ComputeNode",
                        "TotalElapsedTime": 20017942,
                        "MaximumElapsedTime": 19995726,
                        "MinimumElapsedTime": 146,
                        "TotalCPUTime": 23980,
                        "MaximumCPUTime": 2066,
                        "MinimumCPUTime": 145,
                        "CountOfInvocations": 60,
                        "NumberOfInputTerminals": 1,
                        "NumberOfOutputTerminals": 6
                    },
                    {
                        "Label": "Compute1",
                        "Type": "ComputeNode",
                        "TotalElapsedTime": 4015363,
                        "MaximumElapsedTime": 2004338,
                        "MinimumElapsedTime": 76,
                        "TotalCPUTime": 10212,
                        "MaximumCPUTime": 637,
                        "MinimumCPUTime": 76,
                        "CountOfInvocations": 60,
                        "NumberOfInputTerminals": 1,
                        "NumberOfOutputTerminals": 6
                    },
                    {
                        "Label": "HTTP Input",
                        "Type": "WSInputNode",
                        "TotalElapsedTime": 4732,
                        "MaximumElapsedTime": 607,
                        "MinimumElapsedTime": 20,
                        "TotalCPUTime": 4584,
                        "MaximumCPUTime": 605,
                        "MinimumCPUTime": 20,
                        "CountOfInvocations": 60,
                        "NumberOfInputTerminals": 0,
                        "NumberOfOutputTerminals": 4
                    },
                    {
                        "Label": "HTTP Reply",
                        "Type": "WSReplyNode",
                        "TotalElapsedTime": 9563,
                        "MaximumElapsedTime": 730,
                        "MinimumElapsedTime": 49,
                        "TotalCPUTime": 9098,
                        "MaximumCPUTime": 542,
                        "MinimumCPUTime": 49,
                        "CountOfInvocations": 60,
                        "NumberOfInputTerminals": 1,
                        "NumberOfOutputTerminals": 2
                    }
                ]
            }
        },
        {
            "WMQIStatisticsAccounting": {
                "RecordType": "Summary",
                "RecordCode": "Summary",
                "MessageFlow": {
                    "BrokerLabel": "integration_server",
                    "BrokerUUID": "",
                    "ExecutionGroupName": "TEST_SERVER2",
                    "ExecutionGroupUUID": "00000000-0000-0000-0000-000000000000",
                    "MessageFlowName": "ESQLPerfStat_HTTPFlow",
                    "MessageFlowURI": "/apiv2/applications/ESQLPerfStat_HTTP/messageflows/ESQLPerfStat_HTTPFlow",
                    "ApplicationName": "ESQLPerfStat_HTTP",
                    "StartDate": "2026-07-23",
                    "StartTime": "15:34:41.426580",
                    "GMTStartTime": "2026-07-23T10:04:41.426+00:00",
                    "EndDate": "2026-07-23",
                    "EndTime": "15:35:05.598220",
                    "GMTEndTime": "2026-07-23T10:05:05.598+00:00",
                    "TotalElapsedTime": 24042000,
                    "MaximumElapsedTime": 22005557,
                    "MinimumElapsedTime": 452,
                    "TotalCPUTime": 36387,
                    "MaximumCPUTime": 1879,
                    "MinimumCPUTime": 450,
                    "CPUTimeWaitingForInputMessage": 10208,
                    "ElapsedTimeWaitingForInputMessage": 124458,
                    "TotalInputMessages": 40,
                    "TotalSizeOfInputMessages": 19280,
                    "MaximumSizeOfInputMessages": 482,
                    "MinimumSizeOfInputMessages": 482,
                    "NumberOfThreadsInPool": 1,
                    "TimesMaximumNumberOfThreadsReached": 40,
                    "TotalNumberOfMQErrors": 0,
                    "TotalNumberOfMessagesWithErrors": 0,
                    "TotalNumberOfErrorsProcessingMessages": 0,
                    "TotalNumberOfTimeOutsWaitingForRepliesToAggregateMessages": 0,
                    "TotalNumberOfCommits": 0,
                    "TotalNumberOfBackouts": 0,
                    "AccountingOrigin": "Sales"
                },
                "NumberOfNodes": 4,
                "Nodes": [
                    {
                        "Label": "Compute",
                        "Type": "ComputeNode",
                        "TotalElapsedTime": 20023598,
                        "MaximumElapsedTime": 20004111,
                        "MinimumElapsedTime": 215,
                        "TotalCPUTime": 18885,
                        "MaximumCPUTime": 843,
                        "MinimumCPUTime": 213,
                        "CountOfInvocations": 40,
                        "NumberOfInputTerminals": 1,
                        "NumberOfOutputTerminals": 6
                    },
                    {
                        "Label": "Compute1",
                        "Type": "ComputeNode",
                        "TotalElapsedTime": 4006975,
                        "MaximumElapsedTime": 2000935,
                        "MinimumElapsedTime": 83,
                        "TotalCPUTime": 6669,
                        "MaximumCPUTime": 717,
                        "MinimumCPUTime": 83,
                        "CountOfInvocations": 40,
                        "NumberOfInputTerminals": 1,
                        "NumberOfOutputTerminals": 6
                    },
                    {
                        "Label": "HTTP Input",
                        "Type": "WSInputNode",
                        "TotalElapsedTime": 3788,
                        "MaximumElapsedTime": 490,
                        "MinimumElapsedTime": 38,
                        "TotalCPUTime": 3345,
                        "MaximumCPUTime": 143,
                        "MinimumCPUTime": 38,
                        "CountOfInvocations": 40,
                        "NumberOfInputTerminals": 0,
                        "NumberOfOutputTerminals": 4
                    },
                    {
                        "Label": "HTTP Reply",
                        "Type": "WSReplyNode",
                        "TotalElapsedTime": 7639,
                        "MaximumElapsedTime": 405,
                        "MinimumElapsedTime": 100,
                        "TotalCPUTime": 7488,
                        "MaximumCPUTime": 405,
                        "MinimumCPUTime": 100,
                        "CountOfInvocations": 40,
                        "NumberOfInputTerminals": 1,
                        "NumberOfOutputTerminals": 2
                    }
                ]
            }
        }
    ]
}

Here is what the data tells us:

Flow-level summary (per accounting origin):

Node-level breakdown (Finance, 60 messages):

Node-level breakdown (Sales, 40 messages):

What we can conclude:

• Compute is the dominant cost node — it accounts for ~83% of total elapsed time in both Finance and Sales. Its MaximumElapsedTime of ~20 seconds pinpoints exactly where the periodic heavy operation fired. Without node-level data, this would be invisible behind the flow's aggregate number.
• Compute1 contributes a measurable secondary cost — ~4 seconds total in both departments, with a MaximumElapsedTime of ~2 seconds confirming the lighter periodic operation fired at least once per department within the 25-message window.
• HTTP Input and HTTP Reply are negligible — sub-millisecond averages across all messages, confirming the HTTP layer is not a bottleneck.
• Both Finance and Sales hit the 20-second spike — the periodic heavy operation in Compute fired for at least one message in each department, driving the MaximumElapsedTime to ~20 seconds in both records.
• Sales has a higher average (~601ms) than Finance (~401ms) despite fewer messages — the spike landed disproportionately on Sales' smaller batch of 40 messages, pulling its per-message average up more steeply than Finance's across 60 messages.
• Anonymous record exists with 0 messages — the API returns an Anonymous record.

Data Visibility During Normal Operation

Statistics are accumulated in memory from the moment a message flow starts processing its first message. Every time a message passes through a flow, the counters and timing values are updated in real time. When you call the Summary API, you receive a snapshot of everything collected up to that instant.

What Happens When a Flow Is Stopped or Undeployed

When a message flow is stopped, undeployed, or deleted, its statistics records are removed from memory and will no longer appear in API responses. The API only returns data for flows that are currently running.

This means:

• A GET on a specific stopped flow returns an empty result.
• A server-level or application-level GET simply excludes that flow from the response — the count and records reflect only the flows that are currently active.

When the flow is restarted or redeployed, its statistics begin fresh. There is no carry-over from the previous deployment.

Controlling Data Retention with clearRecordsOnStop

The clearRecordsOnStop property controls what happens to accumulated statistics when statistics collection is stopped, or when a flow is stopped, undeployed, or deleted:

When clearRecordsOnStop: true — the default. When statistics are stopped, all records are immediately cleared from memory. When collection resumes, it starts from zero — a clean slate with no data carried over from before the stop.

When clearRecordsOnStop: false — when statistics are stopped, the data collected up to that point is preserved in memory. You can still query the API and see the records from before the stop. When collection resumes, it starts fresh from zero — the retained data remains visible but new data begins accumulating independently.

Conclusion

Whether you're managing a handful of message flows or orchestrating complex integration landscapes, the Statistics Summary API gives you the insights you need to ensure your integrations run smoothly and efficiently. The API's simplicity and Admin REST API design make it ideal for integration with modern AI agents, opening up exciting possibilities for intelligent, conversational operations management.