Integration Server 11.1 | Integration Server Administrator's Guide | Simulating Metering in Integration Server | Metering for Event Triggers
 
Metering for Event Triggers
IBM webMethods metering collects data for IBM webMethods product usage, determining transaction metrics for top-level service invocations. Examples of a top-level service invocation include, but are not limited to, invocations that occur via an http request, triggers, email, or the scheduler.
Transaction metrics are time-based. The duration of the service execution determines the number of transactions the IBM webMethods Metering Agent counts for each service invocation. If transaction duration is set to 3 seconds, a service that executes for 9 seconds counts as 3 transactions.
When a top-level service calls other services, the metering agent does not meter the individual child services separately. Instead, the metering agent includes the durations of child service executions as part of the top-level service execution duration. For example, the IBM webMethods Metering Agent considers a JMS trigger service to be a single service execution no matter how many child services the JMS trigger invokes. If the JMS trigger invokes 5 child services, the metering agent includes the execution duration of the 5 child services in the JMS trigger service duration.
IBM webMethods metering determines transaction metrics for an event trigger differently than it does for other triggers.
For JMS triggers, MQTT triggers, and webMethods messaging triggers, the IBM webMethods Metering Agent monitors execution duration for the trigger service and any child services it invokes. The metering log entries include the name of the trigger service and the service duration, which includes the execution time of the trigger service and any child services. The log entries do not list any child services invoked by the trigger services.
However, an event trigger does not have a single trigger service that performs or encompasses all the processing. Instead, an event trigger contains stream processing steps including a TRANSFORM step that invokes the user-defined transform service for each event received. The TRANSFORM step processing is done before the execution of the final processing step. The final processing step includes either INVOKE_SERVICE or FORWARD_TO_TOPIC. The INVOKE_SERVICE step invokes the user-defined target service, while the FORWARD_TO_TOPIC step invokes an internal service. For logging and metering purposes, the metering agent treats the services called by the final processing step as top-level services and the transform service as a child service. The execution duration of the target service includes the execution time of all the transform service executions in the event window.
Consider an event trigger with stream processing logic that includes a TRANSFORM step where the results of transform service are collected and then passed to the target service called by the INVOKE_SERVICE step. If the event trigger processes 500 events in a window, the transform service executes up to 500 times. However, the target service executes only once. IBM webMethods Metering Agent includes the duration of the single execution of the target service and the duration of 500 executions of the transform service in the transaction calculation.
For example, if each transform service executes to completion in 10 ms and the target service takes 100 ms, the IBM webMethods Metering Agent calculates transaction information as follows:
*The total duration for transform service invocations: 500 x 10 ms = 5000 ms
*Target service invocation duration: 100 ms
*Actual duration of target service invocation reported: 5000 + 100 = 5100 ms
*Resulting transaction count: 5.1s/3 =1.7 which IBM webMethods Metering Agent counts as 2 transactions.
Following is a sample of a metering.csv log for target services on an Integration Server where the transaction duration is 3 seconds (3000 ms):

timestamp,svcName,tenant,user,duration(ms),trans_count
2023-11-17 16:57:16 EST,aggregateSensorData.receiveAndProcess.receiveSensorData_:stream_target,,weatherUser,3059,2
2023-11-17 16:57:20 EST,aggregateDrivingData.receiveDrivingData_:streamA_target,,carUser,3069,2