Consumer Event Aggregation

FTM supports event aggregation at the source. For example, at the unit of work the events are raised in. For FTM V3.0.0, Fix Pack 7 and later, aggregation at consumption is also supported where the events are not already aggregated as they are read from IBM® MQ by the event processing flow.

The APIs used to raise events is enhanced to detect events that are written to IBM MQ that are not aggregated. These events are tagged with a hash value on the IBM MQ CorrelId field.

When the FTM reads events, it inspects the CorrelId and, if a hash value is set in the CorrelId field, it attempts to read a second message from the queue with a matching correlation ID. This secondary read request does not wait. If there is no matching message, it returns immediately.

If a second event message is found, the event processing flow attempts to merge the two events. If the merge is successful, FTM checks the aggregation count and might attempt to retrieve another event from the queue.

Events are read from the queue and merged until:
  • The aggregation threshold is reached.
  • The latest event cannot be merged.
  • The read returns with no event.

The following figure shows this process.

Figure 1. Consumer event aggregation process
eventaggregconsumer.jpg

Configuration

Event aggregation at the consumer is enabled and controlled by the value table entries that are shown in the following table.

Table 1. Value table entries
Category Key Value Description
CORE ENABLE_EVENT_MERGE N | Y(default) Enables the merging
CORE REAGGR_THRESH_OUT11 1-100(%) When writing an event to queue, events whose aggregation count < the events aggregation setting * % is tagged for merging.
CORE REAGGR_THRESH_IN11 1-100(%) When reading an event from queue, events whose aggregation count < the events aggregation setting * % is considered for merging.
Note:
  1. Typically, these values should be the same. Values below 1 are converted to 1. Values that are approximately 100 are converted to 100.