arser Configuration Specify User properties and Trap based Criteria Fewer Remove Cancel Figure 12.31 Event parser configuration details. based on other properties of an event, which could include user properties aside from the given default event properties. The first column in Figure 142 is for the "name of the property", which could be any valid event property. The second column specifies the matching criteria. The third column specifies the pattern in which the incoming event property must be tokenised. The fourth column defines the output value of the corresponding property in the resultant event. The matching criteria determine whether the event will be parsed by the given event parser. The output of the event parser is an event object, which will be the modified instance of the incoming event. The attributes of the event object are defined by what are specified in the event parser. If an event is generated by a trap, then the associated trap PDU reference will be maintained in the incoming event object. If the event object contains the trap PDU reference, then the properties of the trap can be used within the event parsers. When an event arrives into the fault management system, the event parsers list is checked to see whether the incoming event satisfies the match criteria of the event parser. If the event parser matches, the event is passed through the corresponding event parser. The outgoing event from the parser is then matched with the remain- ing set of parsers. If there are further matches, the event is passed through those parsers. The process continues until no more parsers remain to be scanned. When an event is raised, the user may need to execute certain actions. FMS pro- vides the event filters to perform automatic actions - such as sending an e-mail, suppressing the event or generating traps - upon occurrence of an event. The user can also execute some classes, such as a custom filter action, when an event is gen- erated. These event filters can be configured either dynamically from the fault m