Deferred filter

Filtering is used to monitor only those transactions required when the resource being monitored is common among different activities in one or more models or has unmonitored activity. The most efficient and best practice is to filter based on message content at the extension.

Using your message format, you can indicate how messages should be filtered. Any transactions that meet the filtering criteria you define are reported. Any transactions that pass through the activity that do not meet the filters are ignored by this activity. (If this activity appears in different transaction pathways, which would be normal for a shared resource, then you would define different filtering criteria in the other transaction pathway.)

An example is a transmission queue (also known as xmitq) used among several different models where a filter might exist on the reply to queue manager.

Unfortunately there are times when the message content doesn't contain enough information to allow filtering at the extension. Without extension filtering, the transaction data is basically broadcast to all the activities and models configured with that resource.

Deferred filtering can be used in situations like this when at least one of the activities within the model does not use a common resource (that is, no filtering) or sufficient filtering occurs for an activity that does use a common resource to uniquely identify a single model.

Deferred filtering occurs at the services. For those activities that you configure for deferred filtering, all transaction data is cached until an activity that does not have deferred filtering identifies the transaction as belonging to the model. After a period of time, the unused transaction data becomes stale and is removed.

Deferred filtering is part of the aliasing functionality. The period of time before data becomes stale is the Create Fragment Delay. Basically, you either have a fragment when deferred filtering is not configured or you have stale data when it is configured.

Generally, you do not want your first activity of a model to have deferred filtering configured. However, if you do, the transaction is delayed by the Create Fragment Delay before it is displayed on the view.

Deferred filtering can be configured for an entire activity or configured per link.

Deferred filtering occurs before the transaction data is provided to other components such as history, SLA and events. However, as the updates are duplicated for each activity with deferred filtering additional bandwidth is required between the extension and TMTM Topic Service as well as additional memory used by the TMTM Topic Service to maintain the data until the filtering is complete. In high volume environments this overhead should be considered when sizing the installation.

You can still filter at the extension to limit the number of transactions that require deferred filtering.