Implementing Reconciliation Engine Logic in the Database

1-4 Oracle Fusion Middleware Administrators Guide for Oracle Identity Manager

1.1.1.6 Improved Java Engine

Processing that cannot be performed in stored procedures and must be performed in Java layer also provides better performance than earlier releases of the engine for the following reasons: ■ Java engine performs bulk operations by default: Submits events in batches to the database Submits bulk postprocess orchestration depending on the action ■ Performs bulk operations wherever possible.

1.1.1.7 Improved Database Schema

A notable performance enhancement from the new database schema in 11g Release 1 11.1.1 is by using horizontal tables for storing event details for various targets instead of using a single vertical table for storing the event details from various targets. A horizontal table is used for each profile.

1.1.2 Web-Based Event Management Interface

Oracle Identity Manager provides a Web-based event management interface that allows you to manage the events from the Web. Authorized users are able to search for events, users, and handle exceptions by linking events with users and accounts. You can also close events, force failed events to be re-evaluated, and perform ad-hoc linking. Ad-hoc linking refers to the ability provided to authorized users of the Event Management section to link an event to any user in Oracle Identity Manager. Although the reconciliation engine finds user matches for events, the user through this ad-hoc link feature can ignore those matches and select a different user. This allows you to handle exceptions resulting from error matches.

1.1.3 Other Enhancements

Other reconciliation enhancements are described in the following sections: ■ Horizontal Tables ■ Handling of Race Conditions ■ OES Integration ■ Ad Hoc Linking

1.1.3.1 Horizontal Tables

In earlier releases of Oracle Identity Manager, the reconciliation schema has one table to store all the event details from various targets. The list of attributes and their names and types that the various reconciliation events contain can vary from target to target. This means that events from one target can contain a different set of data compared to events from another target. The only way to store data from such events in a single table is by storing one attribute per row. Therefore, in earlier releases, each row in the event detail table represents a single attribute of reconciliation event data. For each See Also: Horizontal Tables on page 1-4 for more information about horizontal tables See Also: Event Management Tasks on page 1-7 for information about the tasks performed in Event Management Managing Reconciliation Events 1-5 attribute, it stores the event to which it belongs, the attribute name, type, and value. This is also referred to as vertical table in this document. Although vertical tables are beneficial from the point of view of flexibility and extensibility, it is not an efficient way to store event records from the performance prospective. In 11g Release 1 11.1.1, storage in vertical tables is replaced by separate tables for each target, called horizontal tables. They are called horizontal tables because instead of storing attributes of an event vertically in the table as rows as many rows as there are number of attributes, the attributes of an event are stored horizontally as columns. This means that there are as many columns as there are number of attributes for a target. Each event is stored as a row. Because different targets can have different sets of attributes, each target has a separate table in the reconciliation schema to store event details. There can be multiple tables per target because of requirements to handle multi-valued attributes that are stored as rows in child tables. Each row of the event detail table for a specific profile stores the list of reconciliation fields for a single event. For example, for trusted user reconciliation in which firstname, lastname, email attributes are being reconciled, there is the RA_XELLERATE_USER horizontal table with the following columns: RE_KEY, RECON_FIRSTNAME, RECON_LASTNAME, RECON_EMAI Creating and Maintaining Horizontal Tables Horizontal tables can be created only when a target is being deployed against Oracle Identity Manager. This is because, at the time of target deployment, the reconciliation system knows the list of attributes and their types for the target, which needs to be reconciled. Horizontal tables are updated when configurations are imported from the Deployment Manager or changes are made by using Oracle Identity Manager Design Console. To generate a horizontal table from Oracle Identity Manager Design Console, in the Object Reconciliation form, click Generate Reconciliation Profile.

1.1.3.2 Handling of Race Conditions

In earlier releases of Oracle Identity Manager, when an event is being reconciled, the reconciliation engine may not be able to process it successfully because before this event can be reconciled, another event needs to be reconciled. For example, before the reconciliation engine can reconcile an event that is supposed to create an account, the engine needs to reconcile an event that is supposed to create a user. This is called a race condition. In Oracle Identity Manager 11g Release 1 11.1.1, the race conditions are handled by using an auto retry option that you can select for each reconciliation run. To configure auto retry, specify a value greater than 0 for the MaxRetryCount parameter. If you do not want to configure auto retry, then specify 0 as the value of the MaxRetryCount parameter. Note: MaxRetryCount is a parameter in the reconciliation profile. The default value of this parameter is 5. You can change this by exporting the profile from MDS, updating the retry count, and importing it back to MDS. For information about manually updating reconciliation profiles, see Updating Reconciliation Profiles on page 1-15.