Event Configuration Information (ECI) processing involves two steps:

  • Determining whether a raw event should be processed to create an unpublished notification that is passed to notification processing (that is, filtering events at the lowest level possible).

  • Determining the instance/class/event name of the notification that should be created if the event is processed.

    ECI processing and NCI processing steps within Smarts NOTIF shows the overall flow of ECI processing steps. Chapter 3, Notification Configuration Information Processing. provides details on how ECI processing steps relate to the NCI processing steps.

    Figure 1. ECI processing and NCI processing steps within Smarts NOTIF

    Event information is passed to Smarts NOTIF through a common structure. This packaging allows for common information to logically identify an event and pass additional information that may be used to further convert raw information into a specific notification.

    The packaging of the event data is performed by the specific adapter and should be referenced by the individual adapter documentation. The general format of the wrapper is explained in “Raw event normalization” on page 26.

    Events are grouped by three identifying fields: baseID, sub1ID, and sub2ID. An event is only processed if an associated ECI is found to match these fields.

    After an ECI matches a given raw event, a series of configuration tests are performed on the raw event to determine if the event should be processed further. Configuration test checks on a raw event include the following parameters:

Event Active

The event must be active in order to be processed.

Is Managed

Un-managed objects are not processed.

< x events in y minutes

Sliding window squelch.

ASL hook

Hard-coded test of other values.

Setting up ECI configuration parameters on page 32provides details on all the available ECI configuration values. Failure of any raw event test prevents the ECI process from determining what unpublished notification will be created or updated.

After basic event tests are complete, the event is formed into a notification. This phase of processing allows the instance, class, event name and all notification values to be changed based upon event data with variable substitution from raw event data. After this point, it is an unpublished notification that is no longer connected to the raw event, though the event data may be passed in the notification.

Note:

ECI configurations are saved as *.ncf files and remain unchanged through the stopping and starting of the Adapter Platform (OI) server.

There are several ways in which ECI objects can be loaded or added into a SAM/Adapter Platform server. ECI objects can be:

  • Defined by *.ncf files provided from other sources (that is, pre-packaged configurations).

  • Created directly from the Smarts NOTIF Editor from the Edit menu.

  • Merged into the Smarts NOTIF Editor based on specifications in the trap_mgr.conf file.

    Additionally, the Smarts NOTIF Editor provides a means to copy an existing ECI object as the basis for another, and to save all defined configurations to an .import file.

    After a raw event arrives and the best ECI object match is found, the behavior of the configuration object is performed relative to the event. If ECI objects are modified with the Smarts NOTIF Editor, the effects of the modifications take place when the next instance of the relevant event arrives.