Email Notification handling

Workflow running Consistency Rules to handle Email accounts.

Email Notification handling is a mail-specific real-time workflow that runs consistency processing for email accounts inside DirX Identity. You use it when mail consistency rules, tag evaluation, and privilege resolution should handle entries from the configured user subtree instead of provisioning directly to an external target system.

The sample is generic because tscluster and tsresource are *. Its join activity applies consistency logic below rulesroot and provisionrulesroot and works on users below usersubtree.

The workflows in this reference are delivered as factory data and are loaded into the Connectivity configuration database during the initial configuration. They are samples: use the Identity Manager to copy a workflow into your own scenario and adapt the copy. Do not change the delivered objects, because a product update can replace them.

At a Glance

Name

Email Notification handling

Prerequisites

You need mail consistency rules below cn=Mail,cn=Consistency,cn=Default,cn=Rules,cn=Policies,cn=My-Company.
You need provisioning rules below cn=domain_name,cn=Rules,cn=Policies,cn=domain_name and the affected users below cn=subtree,cn=Users,cn=domain_name.
The Java-based Server (IdS-J) must be able to access the Identity Store content that the workflow evaluates.

Workflow and Activities

Activity Type Component description Description Ports

Activity	Type	Component description	Description	Ports
`error`	`error`	`provisioningActivity`	Error Activity	`Message`
`join`	`PrivilegeResolutionController`	`PrivilegeResolutionActivity`	Activity for user resolution and account update.	-

error

provisioningActivity

Error Activity

Message

join

PrivilegeResolutionController

PrivilegeResolutionActivity

Activity for user resolution and account update.

Ports

Activity Port Component description Connector Connected directory Bind profile SSL

Activity	Port	Component description	Connector	Connected directory	Bind profile	SSL
`error`	`Message`	`errorPort`	`ErrorNotifyMailConnector`	-	-	not set

error

Message

errorPort

ErrorNotifyMailConnector

not set

Configuration Parameters

Table 1. Workflow parameters of `Email Notification handling`
Parameter	Default value
`ispwdmanager`	FALSE
`timeout`	P0Y0M0DT0H0M0S
`tscluster`	*
`tsresource`	*

Table 2. Parameters of activity `error`
Parameter	Default value
`resourcefamily`	LDAP
`retrylimit`	3
`timeout`	P0Y0M1DT0H0M0S
`waitbeforeretry`	P0Y0M0DT2H0M0S

Table 3. Parameters of port `Message` (activity `error`)
Parameter	Default value
`decrypt.attribute`	dxmPassword

Table 4. Parameters of activity `join`
Parameter	Default value
`applyconsistencyrules`	TRUE
`checkrolespermissions`	FALSE
`checktsaccountsgroups`	FALSE
`checkusers`	FALSE
`evaluatetags`	TRUE
`privilegetobedeleted`	FALSE
`provisionrulesroot`	cn=domain_name,cn=Rules,cn=Policies,cn=domain_name
`resourcefamily`	ConsistencyCheck
`retrylimit`	3
`rules.cache.mru.size`	500
`rules.ldap.pagesize`	300
`rulesroot`	cn=Mail,cn=Consistency,cn=Default,cn=Rules,cn=Policies,cn=My-Company
`sortattribute`	cn
`timeout`	P0Y0M0DT0H15M0S
`userstorage.batch.accumulator.size`	500
`userstorage.cache.mru.size`	10000
`userstorage.cache.prefetch.size`	50
`userstorage.ldap.pagesize`	50
`usersubtree`	cn=subtree,cn=Users,cn=domain_name
`waitbeforeretry`	P0Y0M0DT0H30M0S

A Java-based real-time workflow runs as a permanently loaded configuration in the Java-based Server (IdS-J). It is triggered by a request or an event rather than by a schedule. Each workflow consists of activities; an activity opens one port per system it talks to, and each port uses a connector to reach that system.

Most provisioning workflows contain a join activity that performs the actual work and an error activity that receives requests which still fail after all retries and sends a notification about them. The retrylimit, waitbeforeretry and timeout parameters of an activity control how often and how long a failed request is retried before it is handed to the error activity.

The event port publishes change events over JMS, and the notify port sends e-mail notifications. Neither port is bound to a connected directory.

The join activity is a PrivilegeResolutionController. It runs entirely inside IdS-J and therefore has no external workflow ports. With applyconsistencyrules and evaluatetags set to TRUE, the activity focuses on rule-driven mail handling instead of connector-based provisioning.

Because checkusers, checkrolespermissions, and checktsaccountsgroups are FALSE, the sample concentrates on consistency processing for the affected mail objects. If processing still fails after three retries with a 30-minute wait, the workflow routes the request to error, which sends the error notification through Message.

Operation

A request for mail consistency processing enters Email Notification handling.
The Java-based Server (IdS-J) starts the join activity.
join evaluates tags and consistency rules from rulesroot for entries in usersubtree, sorted by sortattribute.
When rule processing needs provisioning rule context, join uses provisionrulesroot.
After rule evaluation completes, the workflow returns control to normal DirX Identity processing of the affected mail objects.
Requests that fail permanently are handed to error, which reports them by e-mail.

The workflow is delivered inactive (dxmActive is FALSE). Copy it into your own scenario, adapt the rule roots and activate the copy.