.png)
Reconciliation
Reconciliation allows to compare the content of a remote application's repository with the IDM repository. The reconciliation task starts by scanning all the application's objects (accounts, organizations...), detecting changes regarding the IDM state; new applicative accounts added, accounts that no longer exist (i.e. removed by the application's administrator), accounts modified. Reconciliation is usually executed as a scheduled task.
Reconciliation Steps
This section describes the various steps occurring in the reconciliation and live synchronization tasks. It also mostly applies to the import task, with slight variations that will be mentioned when appropriate.
For simplicity's sake, the term "account" will the used to designate any object belonging to a remote application (not to be confused with Memority IDM objects), be it a user or an organization, or any other resource type.
Reconciliation Overview
The main reconciliation steps are:
account search step: search on the remote application (using a Connector) accounts to reconcile or import. For the live sync task this list is well known because it is directly obtained from the application's changelog
account reorder step: if dependencies exist between accounts to reconcile (e.g a user referencing a manager), they are re-ordered according to their natural dependency order
IDM delta computation step: iterate on each account to reconcile. For each account, compute an "IDM delta" that may correspond to an IDM object added, modified or deleted. A delta represents the difference between the account state and the counterpart IDM object state (if such a counterpart already exists)
This delta computation step is roughly composed of the following sub-steps:situation step: determine the account "synchronization situation", regarding its potential existing IDM owner(s). The situation may be "linked", "unmatched", etc. The "situation" notion is detailed in a later section
reaction step: react to the above synchronization situation, most likely by adding or updating IDM objects (inbound attribute mappings are then evaluated). Reactions are configurable, but for the import task, the reaction is forced to be "add an IDM object", whatever the configuration may dictate. The "reaction" notion is detailed in a later section
delta generation step: if the configured reaction dictates to reflect account changes to the IDM service, the IDM delta is computed (but not submitted yet, see next step)
IDM request step: deltas are accumulated and sent to the IDM in batch mode using the IDM bulk API
IDM response step: the IDM bulk response is post-processed to update Synchronization service’s internal repository state regarding the IDM state
The delta computation step is illustrated below:
Configuration
A Reconciliation Task is configured through a classic Synchronization Task Definition When executing a Reconciliation Task, a regular Synchronization Task is indeed launched behind the scene. The "reconciliation" flavor only stems from the fact that a CSV file is uploaded on-the-fly by an end user when launching or scheduling (just once) the Synchronization Task.