Grouping of Events by Reconciliation Runs

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