Table of Contents

Events - processing of events

Event types

Every module can publish their own event types. Basic (core) event types

Different (and custom) event types can be used for different entities.

Event is published with content and specific event type (e.g. CREATE, PASSWORD). Processors can be registered by content type and event type - e.g. process event with IdmIdentityDto content and event type CREATE ⇒ other event contents and other event types will not be processed by this processor.

Entities with event support

Supported events for individual entities:

A page has been created directly in the application on the module page for an overview of all entity types and event types migrating through event processing. All the registered processors including the configuration are listed there:

Asynchronous event processing

CzechIdM 8.0.0 ushered in a new feature - asynchronous event processing. New event type NOTIFY was added, all previous events (CREATE, UPDATE, DELETE, EAV_SAVE etc.) are still synchronous.

Entity DELETE event is still synchronous.

Features

Event priority

Before event is persisted into queue, then event priority is evaluated, priority types:

Priority can be set to event manually or registered processors can vote about event's priority - see AsyncEntityEventProcessor - the highest priority is used.

Execute date

Execute date can be set to event manually. Event with priority HIGH or NORMAL will be processed after given date. Can be used for events, which could be executed sometimes "in night".

Remove duplicate events

When internal scheduled task for executing event from queue is processed, then duplicate events are removed.

Duplicate event is event with the same:

Older duplicate events are removed - the newest event is used. Events are processed by priority in bulk, default bulk size is 100 events ⇒ duplicates are removed only in this bulk (not configurable for now, see future development). Bulk size is designed this way, because events are processed by priority - event with HIGH priority should not wait too long for another bulk is begin to process. Remove duplicates should be redesigned from scratch - remove duplicates through whole queue.

Notification

Notification about registered asynchronous processors is prepared, when an asynchronous event is published. Notification is send into topic core:event - uses console log by default and is send to currently logged identity - e.g. identity is saved, but provisioning will be executed asynchronously. Localization for asynchronous processors was added on frontend (see key acc:processor.identity-save-processor).

Configuration

Predefined processors order

Other orders can be found directly in application, see supported event types.

Processor configuration

Processors can be configured through Configurable interface by standard application configuration.