The EventGroupDefinition provide the metadata for Event Group.
The event subscribers write the filtering conditions on event group.
If the condition is true the event handlers get executed.
Event group let you group events. Group can have parent event group to make it
hierarchical. Event groups can directly used in building rules.
When user writes policies, they have two choices. User can either directly
use the group itself to define policy rule, in this case user is indirectly
creating rule on all events which belong to that group or user can use event
group is a way to quickly narrow down the list of events and define policy rules
based on sub set of events under that group.
Event groups will also be classified by the type. This will let services
to own and manage groups required to create their service specific policies.
Currently as a part of Event service we are already providing some implicit groups,
which are not manageable in post deployment by either services or end users.
Those groups are internal groups managed by the event service.
Examples of such groups are:
DOCUMENT_ASYNC_EVENTS: This group includes DOCUMENT_CREATED, DOCUMENT_UPDATED and DOCUMENT_DELETED events.
ALL_ASYNCHRONOUS_EVENTS: This group includes all the asynchronous events in the system.
The attribute types of a particular EventType is returned by getAttributes().
Used the GUI teams to show list of attributes that can be used in building the
RuleCondition
returns boolean whether the event is synchronous or not.
If the event type is synchronous, the event handlers get executed before the
call is returned to the event publisher. The event handlers in synchronous events
are only PL/SQL calls.
If the event type is Asynchronous event types, the event is put into event queue and
the events are processed by event handlers Asynchronusly.
Below are examples in JSON and XML formats. All examples are shown with all inherited members. Quoting when required is part of the examples, but you must obviously populate with your own data.
