Event–condition–action (ECA) is a short-cut for referring to the structure of active rules in event-driven architecture and active database systems.

Such a rule traditionally consisted of three parts:

• The event part specifies the signal that triggers the invocation of the rule
• The condition part is a logical test that, if satisfied or evaluates to true, causes the action to be carried out
• The action part consists of updates or invocations on the local data

This structure was used by the early research in active databases which started to use the term ECA. Current state of the art ECA rule engines use many variations on rule structure. Also other features not considered by the early research is introduced, such as strategies for event selection into the event part.

In a memory-based rule engine, the condition could be some tests on local data and actions could be updates to object attributes. In a database system, the condition could simply be a query to the database, with the result set (if not null) being passed to the action part for changes to the database. In either case, actions could also be calls to external programs or remote procedures.

Note that for database usage, updates to the database are regarded as internal events. As a consequence, the execution of the action part of an active rule can match the event part of the same or another active rule, thus triggering it. The equivalent in a memory-based rule engine would be to invoke an external method that caused an external event to trigger another ECA rule.

ECA rules can also be used in rule engines that use variants of the Rete algorithm for rule processing.

• Rulecore
• Concurrent Rules
• Apart Database
• Detect Invocation Rules
• ConceptBase ECArules