An event is an object containing information related to an event. As an example, there are Workflow State Events that are emitted when the state of a workflow is changed and there are User Events that are emitted when a user logs in or modifies data in the system.

All events are forwarded to a Platform feature, named Event Server. Units interested in events, subscribe to specific events with the Event Server. An example of such units is the Workflow Template, which shows workflow and agent states, the Event Notification configuration, which subscribes and routes events to notifiers, etc.

The DTK allows new event types to be introduced and emitted to the Event Server. These events may be collected and parsed in the Event Notification configuration and forwarded to one of the existing notifiers, such as the Log File or a user-defined notifier created with DTK. For further information about notifier plugins, see Notifier Plugins.

Event

For an event plugin example, see

com.digitalroute.devkit.examples.event.TAPErrorEvent

Event-related examples are located in the package com.digitalroute.devkit.event.

Historic Events

After an event has been processed by the Event Server, it is disposed of, by default. Thus, a new subscriber will not receive a matching event until the next one arrives. For subscribers such as the Workflow Template, which needs to know the state of each agent when a workflow is loaded, this is not sufficient. To solve this problem, an event can be defined as historic. If such an event arrives at the Event Server, it will cache this event after processing it, instead of throwing it away. Only the last event for each key will be saved. An event defined as clearing history will remove historic events sharing the same group key.

Event Suppression

The Event Notification configuration (not the Event Server) offers a feature of suppressing duplicate events. For instance, if duplicate suppression is configured to 10 seconds, the first arriving event will be forwarded, while duplicates, arriving within 10 seconds, will be discarded. To handle this, the duplicate key may be defined in the event. This is referred to as the suppress key.

DRBaseEvent

User-defined events are introduced by extending the DRBaseEvent class. DRBaseEvent itself extends DRAbstractUDR so that it can benefit from the introspection mechanism introduced in the UDR subsystem. The Event Notification configuration utilizes this when allowing automatic filtering on or selecting data from individual event fields. The base event contains some common fields that will be available in all events. These include severity, IP address, and timestamp.

The following methods must be overloaded for new events. The method getEventName will return a string representation of the event. This name will be displayed in the list of available events when selecting which events to subscribe to in the Event Notification configuration. The getValue method, called by the toString method, will return an array of name/value pairs that describe the current value of the event. The toString implementation arranges these name/value pairs in a common layout.

As previously mentioned, the UDR introspection mechanism automatically displays fields for all methods whose names begin with get_, i.e. methods such as String get_FirstName(). In the Event Notification configuration, these will allow filtering and value collection from a field named FirstName.

To serialize the data, writeTo and readFrom methods must be implemented, and if an event will be cached by the Event Server, in order for a new subscriber to immediately obtain a value (without waiting for the next event), then the methods:

• isHistoryEvent
• getKey
• isClearingGroup
• getGroupKey

and must be overloaded. For further information, see Historic Events above.