Restore_LDAP_Realtime
Sample workflow to restore an LDAP target system.
A restore workflow writes the state that DirX Identity holds for a target system back into the connected system. Use it after the connected system has lost data, for example after a restore from a backup that is older than the last provisioning run: the workflow re-creates the accounts, groups and memberships that DirX Identity knows about, so that the connected system matches the Identity Store again.
The workflow reads from the target system subtree of the Identity Store and writes to the connected system; it does not change the Identity Store.
Restore_LDAP_Realtime is the restore workflow for connected systems of type LDAP. You use it when DirX Identity must replay the managed state of an LDAP target system after you need to recover the target side.
The sample stays separate from an initial load because dxminitialload is FALSE. It restores the accounts, groups, and members object areas and can also send password data through setPassword.
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 |
|
Category |
Target Realtime / LDAP |
Technology |
Java-based real-time workflow |
LDAP object class |
|
Workflow type |
|
Connected system / controller type |
|
Configuration wizard |
|
Active in the factory data |
FALSE |
Factory data version |
8.0 |
Factory data path |
|
Prerequisites
-
You need a connected directory of type
LDAPwith bind profileAdmin. -
You need the target system entries in the Identity Store to represent the state that you want to restore over
accounts,groups, andmembers. -
The Java-based Server (IdS-J) must reach the Identity Store through
Domain_Adminand theLDAPconnected directory through theTSport.
Workflow and Activities
| Activity | Type | Component description | Description | Ports |
|---|---|---|---|---|
|
|
|
Error Activity |
|
|
|
|
Join activity for the provision-to-TS workflow |
|
Ports
| Activity | Port | Component description | Connector | Connected directory | Bind profile | SSL |
|---|---|---|---|---|---|---|
|
|
|
|
- |
- |
not set |
|
|
|
|
- |
- |
not set |
|
|
|
|
|
|
not set |
|
|
|
|
- |
- |
not set |
|
|
|
|
|
|
not set |
Channels
| Channel | Description | Reference type | Delta type |
|---|---|---|---|
|
Channel for accounts |
OneToOne |
SearchAttributes |
|
Channel for groups |
OneToOne |
SearchAttributes |
|
Channel for members |
OneToOne |
SearchAttributes |
| Channel | Description | Reference type | Delta type |
|---|---|---|---|
|
Channel for accounts |
OneToOne |
SearchAttributes |
|
Channel for groups |
OneToOne |
SearchAttributes |
|
Channel for members |
OneToOne |
SearchAttributes |
|
Channel for setting a password |
OneToOne |
SearchAttributes |
Configuration Parameters
| Parameter | Default value |
|---|---|
|
FALSE |
|
P0Y0M4DT0H0M0S |
| Parameter | Default value |
|---|---|
|
|
|
3 |
|
P0Y0M1DT0H0M0S |
|
P0Y0M0DT2H0M0S |
| Parameter | Default value |
|---|---|
|
dxmPassword |
| Parameter | Default value |
|---|---|
|
LDAP |
|
3 |
|
P0Y0M1DT0H0M0S |
|
P0Y0M0DT0H30M0S |
| Parameter | Default value |
|---|---|
|
event |
|
userPassword |
|
false |
| Parameter | Default value |
|---|---|
|
userPassword |
| Parameter | Default value |
|---|---|
|
userPassword |
| Parameter | Default value |
|---|---|
|
userPassword |
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 reads the stored target-system state from IdentityDomain over accounts, groups, and members and reapplies it to the LDAP connected directory through channels of the same name. The TS port also exposes setPassword, and CryptFilter decrypts protected values before the connector sends them to the directory.
The event port can publish JMS messages and the notify port can send workflow notifications. 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
-
DirX Identity creates a restore request for the affected entries of the
LDAPtarget system. -
The Java-based Server (IdS-J) passes the request to
join. -
The
IdentityDomainport reads the stored target-system state from the Identity Store over the matching channel. -
The
TSport reapplies that state in theLDAPconnected directory and usessetPasswordwhen the restore includes password data. -
DirX Identity records the restore result in the target system entry state.
-
The
eventport publishes the processed change as a JMS event and thenotifyport sends the configured e-mail notifications. -
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, connect the copy to your connected directory and activate the copy.