Every module can publish their own event types. Basic (core) event types
CREATE - synchronous, new entity is createdUPDATE - synchronous, entity is updatedDELETE - synchronous, entity is removedNOTIFY - asynchronous, notify about entity is changed (CU).EAV_SAVE - synchronous, some entity extended attribute is modified (CUD) - it is synonym for NOTIFY type ⇒ notify about entity extended attribute is changed (only extended attribute is changed). When entity is saved together with extended attributes, then only source event (e.g. CREATE) on owner entity is published (⇒ eav attributes are saved after owner entity is saved in once process line - e.g. CREATE).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.
Supported events for individual entities:
core:IdmAuthorizationPolicyDto - authoriyation policiesCREATE, UPDATE, DELETEIdmAutomaticRoleAttributeDto - automatic role by attributeCREATE, UPDATE, DELETEIdmAutomaticRoleAttributeRuleDto - rule of automatic role by attributeCREATE, UPDATE, DELETEIdmIdentityDto - operation with the identityCREATE, UPDATE, DELETE, EAV_SAVE, NOTIFYPASSWORD - changes passwordPASSWORD_EXPIRED - password expiresIdmProfileDto - operation with the identity profileCREATE, UPDATE, DELETEIdmPasswordDto - operation with the CzechIdM passwordCREATE, UPDATE, DELETEIdmTokenDto - operation with the CzechIdM tokenCREATE, UPDATE, DELETEcidmst)IdmRoleDto - operation with the roleCREATE, UPDATE, DELETE, EAV_SAVE, NOTIFYIdmRoleGuaranteeDto - operation with the role guarantee by identityCREATE, UPDATE, DELETEIdmRoleGuaranteeRoleDto - operation with the role guarantee by roleCREATE, UPDATE, DELETEIdmRoleRequestDto - role requestsCREATE, UPDATE, DELETEEXCECUTE - execute role request (i know EXECUTE!, but it's too late …)NOTIFY - is published, when request is completely approved or executed - provisioning listen this event mainly.IdmRoleCatalogueDto - operation with the role catalogueCREATE, UPDATE, DELETE, NOTIFYIdmRoleCompositionDto - operation with the business rolesCREATE, UPDATE, DELETEIdmIdentityRoleValidRequestDto - role starts to be validIDENTITY_ROLE_VALID.IdmIdentityRoleDto- assigning a role to the userCREATE, UPDATE, DELETENOTIFY - when parent role request event is propagated, then provisioning listener skips this elementary event processing and waits to role request is completed - listen NOTIFY on IdmRoleRequestDto.IdmIdentityContractDto - labor-law relationCREATE, UPDATE, DELETE, EAV_SAVE, NOTIFYIdmContractPositionDto - other contract positionCREATE, UPDATE, DELETE, NOTIFYIdmRoleTreeNodeDto - automatic role by tree structureCREATE, UPDATE, DELETEPasswordChangeDto - used in password prevalidation onlyPASSWORD_PREVALIDATION - evaluates registered password policies - show policies setting before password is changed.IdmContractGuaranteeDto - manually added guarantee to contractCREATE, UPDATE, DELETE, NOTIFYIdmTreeTypeDto - tree structure typeCREATE, UPDATE, DELETEIdmTreeNodeDto - tree structure nodeCREATE, UPDATE, DELETE, EAV_SAVE, NOTIFYIdmPasswordPolicyDto - password policyCREATE, UPDATE, DELETE IdmLongRunningTaskDto - long running taskEND - long running task ended.IdmEntityEventDto - persisted eventCREATE, UPDATE, DELETEEXECUTE - executes persisted event.IdmEntityStateDto - persisted entity / event stateCREATE, UPDATE, DELETEIdmFormInstanceDto - eav attribute values from single definition.UPDATE - update event type is used for saving eav attributes (⇒ CUD form values)IdmCodeListDto - code listsCREATE, UPDATE, DELETEIdmCodeListItemDto - code list itemsCREATE, UPDATE, DELETEacc:AccAccountDto - Accounts on target systemCREATE, UPDATE, DELETESTART - starts provisioning for given account.AccIdentityAccountDto - Identity accounts on target systemCREATE, UPDATE, DELETESysSystemDto - System in ACC moduleCREATE, UPDATE, DELETESysSystemMappingDto - Mapping between system and his mapping of provisioning or syncCREATE, UPDATE, DELETESysSchemaAttributeDto - Connector schema on systemDELETESysProvisioningOperationDto - execute provisioning operation. Look out, persisting provisioning operation into queue itself doesn't support events. Events are added for executing operations from queue:CREATE - execute provisioning for CREATE operationUPDATE - execute provisioning for UPDATE operationDELETE - execute provisioning for DELETE operationCANCEL - cancels provisioning operationAbstractSysSyncConfigDto (SysSyncConfigDto, SysSyncContractConfigDto, SysSyncIdentityConfigDto) - synchronizationSTART - starts synchronizationSTART_ITEM - starts synchronization of one item (~entity)CANCEL - cancels synchronizationSysSyncItemLogDto - synchronization item vs:VsRequestDto - Request for account change in virtual system EXCECUTE - executes requestrpt:RptReportDto - generate reportGENERATE - generates requestA 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:
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.
DELETE event is still synchronous.
Before event is persisted into queue, then event priority is evaluated, priority types:
IMMEDIATE - immediate ~ synchronously. Event will be executed synchronously.HIGH - asynchronously (7 / 10 in one cycle)NORMAL - asynchronously (3 / 10 in one cycle)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 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".
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 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).
save, delete etc.save - e.g. sends notifications.NOTIFY event about entity is changed.delete provisioning (before identity role is deleted).after provisioning actions (e.g. sends notifications)Other orders can be found directly in application, see supported event types.
Processors can be configured through Configurable interface by standard application configuration.