Events

The event registry is used in IFS Applications for keeping track of the activities related to handling of events that occur inside the application. Events are programmatically defined, but the actions and conditions that apply can easily by configured.

Contents

• Definition
• Uses in Foundation1
• The Event Registry process

Definition

The Event Registry is a way to create an active behavior on top of an Oracle Server and is based on the ECA-rule:

Picture edges too dark and thick and it looks quite old.

The event occurs, conditions are evaluated, if true then an action is executed.

The ECA-rule is a rule that almost all active databases follow. The rule can be described as the following:

An EVENT occurs in the database that generates a call to the condition handler. The condition handler evaluates certain CONDITIONS that are registered together with the action. If the evaluation is successful, the registered ACTION is performed.

Event

An event can be described as something that happens in a transaction that generates a method call to the condition handler.

There are two types of events:

• Application Defined Events
  These events are built into the applications logic at places where important things happen.
• Custom Defined Events
  These events are defined at installation time and maintained by triggers generated during configuration. This type of event gives the Configurator of the system the opportunity to add events without coding a single line.

Condition

Conditions decide whether or not the registered action shall be performed.

Actions

Actions are the different types of responses that can be generated by the system when an event occurs. The actions can be conditioned so that they are fulfilled only when the conditions evaluate to true.

Uses in Foundation1

The idea of an active database is very useful in Foundation1. Implementation of this in applications should provide a flexible way to control events and the actions connected to them. The use of LUs makes it easy to find a location for the calls that have to be made in the database when a specified event happens. The use of an executor of actions makes it easy to support the actions that an event should result in.

The process to access Events can logically be divided into four different sections: Event Production, Event Handling, Condition Handling and Action Handling.

Principal design of event handling in the architecture context

The Event Registry process

1. The business logic calls the Event handler for the event to control if any actions are registered on the event. This call should be in the involved LU's package body (in the method controlling the event) or as a trigger on the base table of the LU. It is possible to have different conditions and different actions on the same event, but the event doesn’t need to have any actions at all connected to it. An event can be created without knowledge about the actions that will be connected to it in the future. The actions can be added afterwards. If at least one of the actions is active, the event is triggered and its condition must be evaluated.
2. The involved LU:s business logic supplies different pre-defined parameters with data and sends them packed in a string to the Event handler.
3. The Condition handler checks if the conditions for the actions are true by unpacking the text string supplied by the Event handler.
4. The Action handler controls the type of action and activates this action.
5. The Action handler is responsible for that the action is executed in the proper way. The action could be sent to clients, the business logic or some external source such as mail. This is done through IFS Connect. If end users subscribe to the action, the action handler will send the action to the subscribers as well as to the original receiver.