Parameters to Control Flow and Processing of Events

Managing Reconciliation Events 1-3 available as a system property and can be managed from Oracle Identity Manager Design Console. The property name is OIM.ReconBatchSize. The default value of the system BatchSize parameter is 500. For information about system properties, see Chapter 4, Administering System Properties . Parameter to Control AutoRetry The MaxRetryCount profile parameter controls auto retry by indicating how many times an item needs to be retried before the reconciliation engine marks it as an error or sends it to manual queue. MaxRetryCount = 0 means auto retry option is not configured.

1.1.1.3 Grouping of Events by Reconciliation Runs

All the events created in the reconciliation database are grouped by reconciliation runs. All events in a reconciliation run are grouped with a common reconciliation run ID. Because each reconciliation run is associated with a profile, all events in a reconciliation run are processed by using the same profile. This helps in optimizing the performance because the configurations have to be retrieved only once per reconciliation run. Each profile can use a different batch size. This enhances system performance for each target reconciliation by tuning the appropriate batch for it.

1.1.1.4 Grouping of Events by Batches

Batches are introduced to increase system performance during reconciliation. A batch consists of a number of events. It is a unit of processing in the reconciliation engine. The size of the batch is configurable. Reconciliation runs are broken into fixed size batches. For example, if a reconciliation run consists of 9900 events and batch size is 1000, then that reconciliation run is divided into 10 batches each with size 1000, and last batch with size 900. Processing a batch as a unit optimizes system performance by eliminating the overhead of processing one event at a time. This also allows performing bulk operations wherever possible. Batches can also run in parallel to balance the use of hardware resources.

1.1.1.5 Implementing Reconciliation Engine Logic in the Database

In earlier releases, all engine logic was implemented in Java and the processing happened one event at a time. In 11g Release 1 11.1.1, most of the logic to process the events is implemented as stored procedures. A combination for processing at batch level and the logic being implemented in PLSQL makes it possible to perform bulk operations at the SQL layer. The following steps are performed in bulk one batch at a time: ■ Required data check ■ Applying matching rules ■ Applying action rules See Also: Handling of Race Conditions on page 1-5 for more information about auto retry 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