Requirements for Indirect Synchronization#
Indirect synchronization uses intermediate staging tables to synchronize data between the Identity Vault and a database.The following diagrams illustrate how indirect synchronization works on the Subscriber and Publisher channels. In the following scenarios, you can have one or more customer tables and intermediate staging tables.
- Intermediate staging tables in between IDM and the application.
- One "parent" table for each object class.
- Parent table contains all single valued attributes.
- Must have a primary key.
- One "child" table for each MV attribute.
- Two columns, foreign key to parent table, and unconstrained value column.
- Foreign key constraint must be explicitly defined.
- Related attributes
- Map to DN type attributes in eDir.
- Use foreign key references.
- Data synchronization.
- Triggers to move data between app tables and IDM tables.
- Event log triggers for publication
Subscriber Channel: (Coming From IDV)#
- Typically, it is the responsibility of the DBA to update the required tables form the intermediate staging tables
 |
The Subscriber channel updates the intermediate staging tables in the synchronization schema.
The synchronization triggers, typically created and determined by the DBA, then update customer tables elsewhere in the database.
Publisher Channel: (Going to IDV)#
- Event log (JDBC 1.x, 2.x)
 |
When customer tables are updated, synchronization triggers update the intermediate staging tables. Publication triggers then insert one or more rows into the Publisher Event Log table. The Publisher channel then reads the inserted rows and updates the Identity Vault.
Depending on the contents of the rows read from the event log table, the Publisher channel might need to retrieve additional information from the intermediate tables before updating the Identity Vault. After updating the Identity Vault, the Publisher channel then deletes or marks the rows as processed.