Enhanced Consumption Visibility and Service-Level Metering for webMethods Transaction-Based Licensing

With the transition to the new consumption-based licensing model, integration architects, platform owners, and operations teams require deep visibility into transaction usage to manage budgets, prevent overages, and optimize architecture.

The current metering dashboard only provides high-level daily aggregates at the runtime level. In a mixed environment utilizing both inbound APIs and internal pub-sub/batch integrations, this abstraction makes it impossible to identify the root cause of consumption spikes. Without granular data, we cannot pinpoint which specific service, trigger, or client application is driving our costs, leaving us unable to actively manage or optimize our footprint.

How should it work? We propose the following functional enhancements to the metering dashboard:

Service and Asset-Level Granularity: Provide a drill-down capability from the Runtime level into specific Top-Level Services, webMethods Packages, and Triggers to easily identify top-consuming assets.

Integration Pattern Separation: Add filters to separate transactions generated by Inbound API Gateway traffic (HTTP/REST/SOAP) from Internal Async/Event traffic (Pub-Sub Triggers, JMS, File Polling, Scheduled Tasks).

Intraday Time-Frequency Analysis: Allow users to break down daily transaction totals into hourly or 15-minute intervals for any selected date range to pinpoint the exact timing of usage spikes.

Consumer & Contextual Metadata: 

 For APIs: Display the API Name, Endpoint path, and API Gateway Application/Consumer ID.

For Events: Display the Trigger Name, Document Type, or Queue/Topic Name.

Predictive Forecasting & Threshold Alerting: Include an automated "burn-rate" calculator projecting if current trends will exhaust the yearly allocation early, alongside customizable email alerts when a runtime exceeds its monthly baseline.

Operational Status Breakdown: Visually distinguish between transactions that completed successfully and those that failed with errors/exceptions to quickly identify error-retry loops.