Events

The Event Registry is used in IFS Applications for keeping track of the activities related to the 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

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

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 follows:

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, then 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:

Condition

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

Action

Action is the response that can be generated by the system when an event occurs. The action can be set up so they are only executed when all of the specified conditions are met.

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 Logical Units (LU's) 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 determine if any actions are registered on the event. This call should be included within the involved entity'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 any knowledge about the actions that will be connected to it in the future.  Actions, if required, can be added afterwards. If at least one of the actions is active, then the event is triggered and its condition must be evaluated.
  2. The involved entity'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 required and will activate this action when the stated conditions have been met.
  5. The Action handler is responsible for ensuring that all actions are executed in the correct manner. Actions can be sent to clients, to the business logic or some external source such as mail. This is handled through IFS Connect. If end users subscribe to any actions, then the action handler will send the appropriate actions to the subscribers as well as to the original receiver.