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
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:
- 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 individuals who
configures
the system the opportunity to add events without coding a single line.
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.
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 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.
- The involved entity's business logic supplies different
pre-defined parameters with data and sends them packed in a string to the Event
handler.
- The Condition handler checks if the conditions for the
actions are true by unpacking the text string supplied by the Event handler.
- The Action handler controls the type of action required and
will activate this action when the stated conditions have been met.
- 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.