IBM Tivoli Monitoring > Version 6.3 Fix Pack 2 > Installation Guides > Installation Guide > Set up event forwarding to Netcool/OMNIbus > Understanding and Customizing the Event Contents
IBM Tivoli Monitoring, Version 6.3 Fix Pack 2
Generic mapping for agent-specific slots
Generic mapping is used for events for which there is no event mapping file and is based on the target event class that is identified by the situation definition.
For situation events that do not have a custom event mapping specified for the forwarded event, an event is generated with a unique ClassName value based on the attribute group used in the situation. The ClassName attribute of the EIF event is set to a combination of ITM_ plus the attribute group name associated with the situation. For example, a situation using the NT_Process attribute group generates an EIF event with ClassName set to ITM_NT_Process. The EIF event contains the base attribute slots described in Table 1.
Additional agent-specific event slot values are populated with attribute values from the situation event data. The EIF slot names are the attribute names from the attribute group. For example, a situation using the Process_CPU attribute causes generation of a slot called process_cpu in the EIF event forwarded to the OMNIbus EIF probe. If an agent-specific attribute name conflicts with a slot name in the Tivoli Enterprise Console EVENT class or Omegamon_Base class, then the agent product code associated with the attribute group, for example: knt_, is prepended to the attribute name to form a unique slot name.
By default, the agent specific EIF event slots are not mapped to OMNIbus attributes. However, you can perform custom mapping of these EIF slots to OMNIbus attributes in the itm_custom_override.rules file. You can either map the agent specific EIF slots to name-value pairs in the ExtendedAttr OMNIbus attribute, or map them to a new OMNIbus attribute. Also some agents, for example, ITCAM for Transactions agents, might provide their own rules and .sql file for mapping agent specific attributes to new or existing OMNIbus attributes. (If you create a new OMNIbus attribute, you must add the attribute to the ObjectServer alerts.status table before updating the rules file.) However, it is important to note that the agent specific slot values are only included in the EIF event that is sent when the event is opened and not in any subsequent status update events, for example when the event is acknowledged or closed. If you are using bidirectional event synchronization between the monitoring server and Netcool/OMNIbus and you map agent specific slots to a new OMNIbus attribute, you must also update the IBM Tivoli Monitoring table and triggers that are used to cache sampled events that are cleared or deleted in the OMNIbus UI. The event data is cached so that it can be used to fully populate a new event if the event is re-opened when the acknowledge timeout expires in the monitoring server. See Table 1 for more information about the behavior of events originating from a hub monitoring server.
- Customize the list of OMNIbus attributes that are cached
Perform the procedure in this section to customize the list of OMNIbus attributes that are cached when a sampled event is cleared or deleted after the new attribute has been added to the ObjectServer alerts.status table.
Parent topic:
Understanding and Customizing the Event Contents