This documentation applies to the 8.1 version of Remedy Action Request System, which is in "End of Version Support."

To view the latest version, select the version from the Product version menu.

Filter log

The filter log file shows all of the filters that were checked during an operation. If a filter was executed, the log also provides a list of the operations performed. By default, the log file is named arfilter.log.

This log is especially useful for checking the interaction of your filters and for verifying whether a filter is performing correctly.

The filter log format is similar to the SQL log format, but the information in the filter log is displayed over multiple lines. The log has the following characteristics:

  • Each line starts with a tag that identifies it as being a filter logging line (<FLTR> ).
  • A time stamp line is written for every operation that can trigger filters.
  • A line indicates that processing has started and the operation is being performed. This line now includes the filter stack level and filter number within the stack.
  • As each filter is checked, a message is written that includes the name of the filter, its escalation order, an indication of whether the filter passed the qualification, and any actions taken with the results of those actions.
  • The last line contains a closing time stamp.

Phases 1, 2 and 3 of filter processing appear in the filter log. As BMC Remedy AR System checks filters, all notify and run process actions are deferred to phase 3. When phases 1 and 2 are completed, and the database has been updated, phase 3 begins. In phase 3, all deferred filter actions are run. This information enables you to track which filters are being checked, which filters are running, and the actions that are being performed. For more information about filter processing, see Filter processing in BMC Remedy AR System server.

Following is a sample filter log file:


<FLTR> <TID: 0000000625> <RPC ID: 0000014210> <Queue: Admin> <Client-RPC: 390600   > <USER: Demo> /* Sat Jun 09 2007 08:38:59.4530 */ Filter Trace Log -- ON
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo> /* Sat Jun 09 2007 08:44:12.7030 */ Start filter processing -- Operation - CREATE
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo>       form1 - <NULL>
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo>  Checking AR System Sample Filter (500)
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo>     --> Passed -- perform actions
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo>          0: Message
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo>                This is a sample message
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo>          1: Notify
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo>                <deferred to phase 3>
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo> /* Sat Jun 09 2007 08:44:12.7180 */      End of filter processing (phase 1)
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo> /* Sat Jun 09 2007 08:44:13.0620 */      Restart of filter processing (phase 3)
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo>          1: Notify
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo>                Priority: 0   Mechanism: Alert
To: User
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo>                This is a sample notification
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo> /* Sat Jun 09 2007 08:44:13.2030 */ Start filter processing -- Operation - CREATE
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo>       Alert Events - <NULL>
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo> /* Sat Jun 09 2007 08:44:13.2030 */      End of filter processing (phase 1)
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo> /* Sat Jun 09 2007 08:44:13.3750 */      Restart of filter processing (phase 3)
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo> /* Sat Jun 09 2007 08:44:13.3750 */ Stop filter processing
<FLTR> <TID: 0000000625> <RPC ID: 0000014330> <Queue: Admin> <Client-RPC: 390620   > <USER: Demo> /* Sat Jun 09 2007 08:44:13.3750 */ Stop filter processing



The filter in the example log performed two actions, a message and an alert. The alert was deferred to phase 3 filter actions. The log also shows the execution of another filter, Alert Events, which created the alert performed by the original filter. The execution of another filter will also occur on a Push Fields action. When the log indicates a failed qualification, this does not mean that the filter malfunctioned. This means that the qualification was not met for this operation, so the else action runs if present.

Tracking filter overlays

When the server executes a filter overlay, the filter log uses the real name of the overlay (<filterObjectName__o>). It also records this message:

skipping overlaid object <filterObjectName>

When overlays are disabled on the server and the server executes an overlaid filter object, it records this message:

skipping overlay object <filterObjectName__o>

For information about overlay objects, see Customizing applications using overlays and custom objects.

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Comments