The Event Options tab of the ECI Setup dialog box shown in Event Options tab of the ECI Setup dialog box defines additional event options for the notification.

Figure 1. Event Options tab of the ECI Setup dialog box

The fields in Event Options tab of the ECI Setup dialog box are described below:

  • DisplayName — The display name of the event used in the notification.

  • Description — The description of the event used in the notification.

  • EventType — The type of event used in the notification, either DURABLE or MOMENTARY.

  • ServiceName — The name of the service used in the notification.

  • SysNameOrAddr — The system name or IP address associated with the event used in the notification.

  • ASL — The ASL script called before the posting of this notification.

    Note:

    NOTIF uses the value stored in ASL to determine which file to load. The named ASL script is invoked from the local/rules or /rules directories. For example, if you type icoi-trapd/sample_hook.asl in the ASL field in the NOTIF Editor, NOTIF will look up local/rules/icoi-trapd/sample_hook.asl and rules/icoi-trapd/sample_hook.asl. Appendix B, “ASL and Java Interfacing with VMware Telco Cloud Service Assurance NOTIF” provides more information on how to write ASL scripts for use with NOTIF event processing.

  • Java — The Java class called.

    Note:

    Appendix B, ASL and Java Interfacing with VMware Telco Cloud Service Assurance NOTIF provides more information on how to write Java classes for use with NOTIF event processing.

  • Logfile — The name of the log file recording information about this event.

  • UnknownAgent — The action taken if the agent is unknown, either CREATE which will create the object, or IGNORE which will discard this event.

  • Event Stream — When set, the processor guarantees that all events with a given event stream name will be processed in the order in which they were received. If the Event Stream option is not set, there is no such guarantee. An example of a scenario in which setting the Event Stream for an ECI would be helpful is the following: a particular network component is flapping and is generating onsets and clears for a single alarm very quickly. In this scenario, NOTIF could receive an onset and then a clear within a few milliseconds. When the ECI does not have an Event Stream set, NOTIF could schedule the onset into one processing queue, and the clear into another. Because it is multithreaded, NOTIF could then possibly process the clear first, which would be incorrect. By providing an Event Stream on the ECI, the user is mandating NOTIF to process the onsets and clears in order, and the problem is solved. Many ECIs can have the same Event Stream, and that guarantees that all of the incoming events for any of those ECIs are processed in the order in which they were received.