An Event for a given context is fired if something happens in that context. For example, the login event defined in the users context indicates that a new user has been logged in to the LinkServer. An event in a Device context may occur if it is initiated by the hardware device. Every event in LinkServer has a special structure called Data Table associated with it. This Data Table contains event-specific data. For example, the login event may contain one record with a username field containing the user name of the newly logged user.
|
Event-specific data is formatted as a Data Table. |
Every event is defined in its context using an Event Definition. An Event Definition contains several options:
| • | Event Name. The name is unique within the context where the event is defined. This is a string that may contain only letters, numbers and underscore character ("_"). |
| • | Event Format. The Record Format of a Data Table representing event-specific data. |
| • | Description. Description of the event. |
| • | Help. Detailed description of the event. |
| • | Persistent. Flag indicating that event will be stored in event history. |
| • | Expiration period. Defines how long persistent event is stored in the event history. |
| • | Level. Severity of the event. This is the default level for this event, but the actual event fired in the context may have another severity level. The levels are listed below. |
| • | Permissions. Permission level required to receive events of this type. |
| • | Group. Shows that event belongs to a event group. Groups help join similar event instances together during different operations. |
EXAMPLES
The Alert context has an alert ("Alert") event which fires when an alert is triggered.
The LinkServer Root context has a login ("User Login") event which fires when a user logs in to the server.
Every event has an Data Table attached to it. This Data Table is different for every event type, and contains relevant information for this event type. You might say it's "notes" or "particulars" for this specific event type.
For example, the login event has a username field, indicating what user logged in. This field is used only for the login event -- there's no use for it in an alert event (for example). So it's contained within the Data Table for the login event (and there's no such field in the data table for the alert event).
Event Listeners
If an LinkServer component "wants" to know what's going on in a particular context, it starts to listen for events in that context. For this, it has to register a special context event listener. This listener receives a notification whenever the selected event is fired in the context.
For example, the Event Log component in AggreGate Client registers event listeners in the contexts defined by the active Event Filter. When these events are fired, the Event Log receives notifications. It uses these to display new events.
Event listeners may be dynamically added and removed during server operation.
The lifecycle of an event
| 1. | Some system component fires an event during its operation. For example, the component responsible for communications with a particular Device Server (it is called a Device Server Controller) fires a logout event in the this Device Server's context when the connection with the Device Server is broken. |
| 2. | If the event is defined as persistent, it is saved to the event history. You cannot make an event permanent if it's not already defined as such (most events are permanent). You can, however, change the "time to live" of an event (its expiration time). This is done by changing the Event Expiration Times table in LinkServer Global Configuration (See Event History below). |
| 3. | The the event is processed by the context, and every registered listener receives a notification. |
Levels describe the severity of an event. When an event is fired, its level may be either assigned by the component firing it or set to some default value specified in the Event Definition. There are several predefined event levels:
| • | None (undefined severity) |
| • | Notice (the least severe) |
| • | Info |
| • | Warning |
| • | Error |
| • | Fatal (the most severe) |
Numeric values of event levels (may be used in different expressions, e.g. during event filtering):
Level |
Value |
None |
0 |
Notice |
1 |
Info |
2 |
Warning |
3 |
Error |
4 |
Fatal |
5 |
Persistent events are stored in the event history. The event history is a special database table that contains all persistent events that were generated by the various LinkServer components. Other components may access the event history through the events context. For example, the Event Log component in AggreGate Client uses this context to display event history.
Each event stored in the history has an expiration period. When an event expires, it is automatically removed from the history. The default expiration period is 10 days, but it can be changed by editing Event Expiration Times table in LinkServer Global Configuration options.
Event Parameters
Every event has the following parameters:
| • | Unique event ID |
| • | Context where the event was fired |
| • | Creation time |
| • | Expiration time |
| • | Event level |
| • | Event data in the form of Data Table |
| • | Acknowledgement text (for persistent events only) |
Every persistent event may be acknowledged one or more times. An acknowledgement is a text string which may be entered and viewed using the Event Log component of AggreGate Client. A user can also enter the acknowledgement text when an alert pops up in the AggreGate Client. If the alert requires an acknowledgement, the popup will prompt the user to enter the acknowledgement text. The acknowledgement comprises of a timestamp, username (who acknowledged the event) and the acknowledgement text.
Acknowledgements are usually generated by humans. They're useful for accountability - you can be certain that a human operator saw the event, and can also tell which operator it was, when they saw it and what they had to say about it.