Loading

How Mule Message Count is Calculated for Applications with Multiple Endpoints

Veröffentlichungsdatum: Jun 26, 2026
Beschreibung
Key Principles of Mule Message Counting

  1. Event Source Trigger: A Mule message is counted every time an event source is triggered. This means each inbound request that reaches an application's HTTP listener initiates a Mule message count. This count occurs regardless of whether the request is subsequently rejected by a policy (e.g., Client ID Enforcement) or ends in an error. The focus is on the initial event that starts processing within the Mule application.
  2. Multiple Listener Endpoints: If an application exposes multiple distinct listener endpoints (e.g., /api/v1/resourceA and /api/v1/resourceB), each configured listener acts as an independent event source. Consequently, a single external inbound request might trigger multiple Mule messages if it interacts with different listener endpoints within the same application. For example, an application with two active listener endpoints could effectively count approximately two Mule messages for each single inbound request that triggers both.
  3. Distinction from Monitoring Views: It's important to differentiate between the Mule message count reported in Usage Reports (used for billing and metering) and the "Mule Messages / Requests" widgets found in monitoring tools like Runtime Manager.
    • Usage Reports (Billing/Metering): These reports provide a comprehensive count of all events that trigger an application's event sources, including requests that are rejected by policies or result in errors. This reflects the total processing load initiated by external interactions.
    • Monitoring Widgets: These often primarily reflect successful business traffic or specific metrics configured for operational monitoring, which can lead to a significantly lower reported number compared to the Usage Report.


Factors Not Affecting Count
Once an event source is triggered and a Mule message is initiated, any subsequent processing within that flow, such as through subflows, internal components, or retries, does not increment the Mule message count for billing purposes. The count is tied to the initial trigger of the event source.

Example Scenario
Consider an application with multiple listener endpoints. If this application experiences a high volume of invalid requests targeting different endpoints, even if these requests are immediately rejected by an API policy, each request reaching an HTTP listener will contribute to the Mule message count. This can lead to a significantly higher message count in usage reports than the number of successful business transactions.
Nummer des Knowledge-Artikels

005387787

 
Laden
Salesforce Help | Article