Horizontal Tables Other Enhancements

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. 1-6 Oracle Fusion Middleware Administrators Guide for Oracle Identity Manager When auto retry is configured, the reconciliation engine checks for the race conditions. If a race condition is found, then the reconciliation engine puts the reconciliation event in a re-evaluate queue until the retry count is exhausted. A Reconciliation Retry Scheduled Task periodically checks if there is any event waiting for retry and is ready to be re-evaluated and if yes, it queues them up for reconciliation engine processing. This scheduled task is configured by default. Auto retry can handle the following race conditions: ■ An account event for creating an account in Oracle Identity Manager is processed before the user is created for this event because the event for creating user is not processed yet. ■ A user event for creating a Xellerate user in Oracle Identity Manager is processed before the organization is created to which this user belongs. Except for the CurrentRetryCount parameter, all other auto retry parameters are stored as part of the reconciliation profiles. This means that while the events belonging to one reconciliation run may have auto retry configured, the events belonging to another reconciliation run may not have auto retry configured. In Oracle Identity Manager 11g Release 1 11.1.1, there is no UI to manage these parameters within a profile and you must use an XML editor to manage them by directly editing the XML profile. For information about editing an XML profile, see Updating Reconciliation Profiles on page 1-15.

1.1.3.3 OES Integration

The event management APIs, the reconciliation APIs, and the UI to manage reconciliation events are protected by using authorization policies. Oracle Entitlements Server OES is the Oracle product that is used to control authorization policies. The default authorization policy for reconciliation specifies that only users with the RECONCILIATION ADMINISTRATORS or SYSTEM ADMINISTRATORS role are able to access and use reconciliation. Note: ■ If the auto retry count is exhausted, the reconciliation engine does not further process the event and sets the status per the matching rules. However, you can manually retry by requesting for re-evaluate from Event Management. For information about re-evaluating events, see Re-evaluating Events on page 1-11. ■ During the retry, if the event is successfully processed, then the value of the CurrentRetryCount parameter is reset to 0. See Also: Parameter to Control AutoRetry on page 1-3 for information about auto retry parameters Note: More information about OES is available in the following URL: http:www.oracle.comtechnetworkmiddlewareoesove rviewindex.html