OMi event attributes

The set of attributes that the probe receives from OMi events depends on whether the events are resynchronization events or notification events. They can be different.

The availability of certain event attributes depends on the following factors:

  • The data inclusion parameters used in the resynchronization query.
  • The data in the OMi event, for example if an OMi event is never annotated, its OprEvent contains no annotation attributes. In notification, each forwarded OprEvent carries all attributes available in the event.

The following table describes which event attributes are included for each of the resynchronization inclusion parameters.

Table 1. Attributes available for each inclusion parameter

Data inclusion setting

Event attributes available

include_annotation=true

$(annotation_list.*)

include_history=true

$(history_line_list_ref.*)

include_cis=true

$(related_ci.configuration_item.*)

$(source_ci. configuration_item.*)

Note: When include_cis=false, the minimal 
$(*.configuration_item.*)
tokens are:
  • *.configuration_item.id
  • *.configuration_item.type
  • *.configuration_item.type_label

include_relationships=true

$(related_ci.configuration_item.part_of.*)

$(source_ci.configuration_item.part_of.*)

Processing considerations

Certain event tokens are indexed by the probe for the convenience of enumerating and safe referencing in the probe rules. Indexed tokens apply to the following attributes:
  • annotation_list
  • forwarding_info_list
  • history_line_list_ref

The range of each event token index is from 0 to (<attribute>.count-1).

The bigger the set of event attributes you include, the bigger the overhead that is incurred and the greater the memory usage in HTTP transactions and OprEvent data extraction. To make the probe work efficiently, include only the attributes relevant to production.

Writing probe rules

When customizing probe rules, you must take care when selecting the fields for the Netcool event’s @Identifier and @Type, the changes made must be able to facilitate event correlation and deduplication in the ObjectServer.

OprEvent’s ID field is the OMi event’s alert key.

OprEventChange’s ID field is the message ID to the OMi event update, event_ref.target_id is the OMi origin event’s alert key. OprEventChange’s id cannot be used in @Identifier, otherwise event correlation will fail.

Although every OprEvent’s ID field is unique, the ID field alone is sufficient to be Netcool event @Identifier, however it is a good practice to combine the ID field with other OMi event attributes to form @Identifier to create a virtual boundary that helps avoid identifier clash, because the ObjectServer might be receiving events from other target systems.