1 Managing Reconciliation Events

The reconciliation process involves generation of events to be applied to Oracle Identity Manager. These events reflect atomic changes in the target system, and contain the data that has changed, the type of change, along with other information. The reconciliation events that are generated as a result of changes occurring in the target system must be managed in such a way that they meet various business requirements. The Event Management section in the Oracle Identity Manager Advanced Administration addresses these event management requirements.

See Also:

"Reconciliation Configuration" in the Oracle Fusion Middleware User's Guide for Oracle Identity Manager for detailed information about reconciliation

You can manage reconciliation events by using the Event Management section, which lets you query the events stored in various ways and display all event data. The events are always displayed in the same form, which is on the Event Details page. You can run custom queries for the events through the Advanced Search feature. It also allows you to perform any necessary action to resolve event issues.

Events are generated by reconciliation runs, which are scheduled to run by using the Oracle Identity Manager Scheduler.

See Also:

""Managing Scheduled Tasks"" for detailed information about the scheduler

This chapter describes the following topics:

1.1 Reconciliation Features in Oracle Identity Manager

Reconciliation features can be divided into the following categories:

1.1.1 Performance Enhancements

In 11g Release 1 (11.1.1), the following enhancements help increase performance during reconciliation:

1.1.1.1 New Metadata Model - Profiles

Oracle Identity Manager has a new model to store the metadata associated with various targets.

In earlier releases, the metadata is associated with a reconciliation target. This limits the ability to run multiple jobs performing different types of reconciliation against the same target.

In Oracle Identity Manager 11g Release 1 (11.1.1), all configurations in various components of Oracle Identity Manager are stored centrally in an XML store called MDS.

For backward compatibility, current deployments continue managing their configurations through Oracle Identity Manager Design Console and the configuration continues to be stored in the Oracle Identity Manager database. The configuration APIs automatically read the configurations from the tables in Oracle Identity Manager 11g Release 1 (11.1.1) and convert them into XML profiles, called default profiles, and associate those profiles with the existing reconciliation runs. The default profiles are marked with a DEFAULT tag.

You manage all the metadata by using Oracle Identity Manager Design Console. Using Oracle Identity Manager Design Console, you can generate the default reconciliation profile. This can be used to regenerate the profile when reconciliation configurations are changed from Oracle Identity Manager Design Console. When configurations are imported from the Deployment Manager, the profile is generated by default.

All nondefault profiles are completely managed directly by using an XML editor.

See Also:

"Reconciliation Profile" in the Oracle Fusion Middleware User's Guide for Oracle Identity Manager for information about reconciliation profiles

1.1.1.2 Parameters to Control Flow and Processing of Events

This section consists of the following topics:

Parameters to Control Event Processing

BatchSize is the parameter to control event processing. This dictates the size of the batch. A batch size of 1 is equivalent to processing of events one at a time. Batch size is 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.

See Also:

"Handling of Race Conditions" for more information about auto retry

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

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.

See Also:

"Horizontal Tables" for more information about horizontal tables

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.

See Also:

"Event Management Tasks" for information about the tasks performed in Event Management

1.1.3 Other Enhancements

Other reconciliation enhancements are described in the following sections:

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 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".

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.

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".

  • During the retry, if the event is successfully processed, then the value of the CurrentRetryCount parameter is reset to 0.

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.

See Also:

"Parameter to Control AutoRetry" for information about auto retry parameters

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".

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.

Note:

More information about OES is available in the following URL:

http://www.oracle.com/technology/products/id_mgmt/oes/index.html

The default authorization policy for reconciliation specifies that only users with the Reconciliation Administrator or System Administrator role are able to access and use reconciliation.

See Also:

  • "Managing Authorization Policies" in the Oracle Fusion Middleware User's Guide for Oracle Identity Manager for detailed information about authorization policies

  • "Managing Roles" in the Oracle Fusion Middleware User's Guide for Oracle Identity Manager for information about how to assign roles to a user

1.1.3.4 Ad Hoc Linking

If the reconciliation engine is not able to determine the owner based on the matching rules, then you can manually link an account to a user by using Oracle Identity Manager Advanced Administration. Subsequent modifications to the account is automatically linked to that account.

Ad hoc linking is supported for user and account events. If the reconciliation engine is not able to determine the owner based on the matching rules, then you can manually link a user or account event to a user.

See Also:

"Ad Hoc Linking" for information about how to perform ad hoc linking

1.2 Event Management Tasks

You can perform the following event management tasks by using the Event Management section of Oracle Identity Manager Advanced Administration:

1.2.1 Searching Events

You can display a summary of reconciliation events by performing the following types of search:

1.2.1.1 Performing a Simple Search for Events

To perform a simple search for events:

  1. Login to Oracle Identity Manager Advanced Administration.

  2. In the Welcome page, under Event Management, click Search Reconciliation Events. Alternatively, you can click the Event Management tab, and then click Reconciliation.

  3. In the left pane, enter a search criterion in the Search field. You can include wildcard characters (*) in your search criterion.

    The simple search takes one argument. The text arguments are searched in the following event fields:

    • Event ID

    • Profile Name

    • Key Fields

    Note:

    In simple search, you cannot perform the search by event dates.
  4. Click the icon next to the Search field. The events that match your search criterion is displayed in the search results table.

    The search fetches all rows for which the aforementioned attributes contains the string specified in the Search field. The search result displays the Event ID, Profile Name, and Key Fields columns. The Event ID column displays the event ID. The IDs are sorted as integers, not strings. The Profile Name column displays the name of the reconciliation profile. Key field is an attribute that uniquely identifies a row of data. In reconciliation, some attributes are flagged as Key in the profile. These fields are displayed in the Key Fields column.

    Note:

    Simple Search is paginated, meaning it only displays search results 64 rows at a time. This is to improve performance. Scrolling down past the 64th row in the UI triggers another page fetched from the database and so on for every 64 rows beyond that.

1.2.1.2 Performing an Advanced Search for Events

The advanced search takes multiple arguments and lets you fine-tune the list of events. To perform an advanced search for events:

  1. In the left pane of the Reconciliation section, click Advanced Search. The Search: Events page is displayed.

  2. Select any one of the following options:

    • All: On selecting this option, the search is performed with the AND condition. This means that the search operation is successful only when all the search criteria specified are matched.

    • Any: On selecting this option, the search is performed with the OR condition. This means that the search operation is successful when any search criterion specified is matched.

  3. In the Event ID field, enter the event ID that you want to search. You can use wildcard characters (*) in your search criteria. Select a search condition in the list adjacent to the Event ID field.

  4. Specify search arguments in the other fields displayed in the Search: Events page. Table 1-1 lists the fields in the Search: events page.

    Table 1-1 Advanced Search Fields

    Field Description

    Event Id

    The event ID. The IDs are sorted as integers, not strings.

    Resource Name

    The name of the resource object representing the target system the event originates from.

    Current Status

    A string representing the current state of the event.

    Type

    The type of operation performed by the event: regular (add or modify) or delete.

    Profile Name

    The name of the reconciliation profile this event pertains to.

    See Also: "Reconciliation Profile" in the Oracle Fusion Middleware User's Guide for Oracle Identity Manager for information about reconciliation profile

    Entity

    The type of Oracle Identity Manager entity this event pertains to. Can be either user, account, role, role grant, or role hierarchy.

    Start Date

    Oldest event creation date to search for.

    End Date

    Most recent event creation date to search for.

    Linked User Login

    A string representing the login ID of the user linked to the event.

    Key Fields

    The fields flagged as key fields in the reconciliation profile that uniquely identifies rows of data.


  5. Click Search. The search results are displayed, which consists of the Event ID, Resource Name, Entity, Event Status, Type, Profile Name, Job ID, Key Fields, and Date columns.

From the search results, you can perform event bulk actions, such as close and re-evaluate, and also display the details of any specific event.

If you want to search for events with LDAP profile, use the following LDAP profiles in your search:

Object Profile
User LDAPUser
Role LDAPRole
Role Membership LDAPRoleMembership
Role Hierarchy LDAPRoleHierarchy

1.2.2 Displaying Event Details

To display the details pertaining to an event:

  • In the left pane of the Oracle Identity Manager Advanced Administration, from the list of events, select an event whose details you want to display.

  • From the advanced search result table, click an event in the Event ID column.

  • From the Actions list, select Lookup. The Event Details page is displayed. The fields in the Event Details page change dynamically based on the event type and event status. Alternatively, you can select an event from the Event Summary on the right pane, and click the magnifying glass icon for lookup to open the Event Details page.

The data in the Event Details page is displayed in the following sections:

  • Event: This section displays the information about the event, such as event ID, whether the event type is User or Account, the time when the event was created, the reconciliation run ID, resource name, the profile name, and the key field values. Reconciliation can use several key fields, and the key field values are shown separated by commas.

  • Linked To: This section shows that the event is linked to a user or account. It displays the user or account ID to which the event is linked, the account description (if any), and the type of linking, such as rule-based linking or manual linking. Rule-based linking means that the reconciliation engine has performed the linking. Manual linking means that the administrator performs the linking manually.

  • Notes: The reconciliation engine adds notes where appropriate. For example, when there is a 'Data Validation Fail', the engine adds a note explaining the reason. This is a read-only field and is blank if no notes are attached to the event.

  • Reconciliation Data: This table displays the reconciliation event data. This shows the attribute name, attribute value, and Oracle Identity Manager mapped field. It also shows the child data of the event, if any. The reconciliation data displays the last name, first name, hiring date, user ID, and the IT resource name.

    If there are attributes with multi-language support, then these attribute values are also displayed in a separate table similar to child data.

  • Matched Accounts: This table displays the accounts that are matched. The columns in the Matched Accounts table are listed in Table 1-2:

    Table 1-2 Columns in the Matched Accounts Table

    Column Description

    Account ID

    The account ID of the matched account

    Orc Key

    An internal key that is stored in the ORC table. This key indicated if the event is matched to a user or an account.

    Descriptor Field

    A description that is associated to the account

    Login ID

    The user login ID corresponding to the user ID displayed for user events.

    Account Owner Name

    A string comprising of the first name and last name and the login ID of the user who owns the account. The event pertains to this account.

    Account Owner Type

    The type of account owner, such as user.


  • Matched Users: This table shows the user matches found by the reconciliation engine. For a multiple match, the linked user is not shown in this table.

  • History: This table shows the operations that took place for this event from event creation and data validation to account matching and whether the update was successful. The columns in the History table are listed in Table 1-3:

    Table 1-3 Columns in the History Table

    Column Description

    Status

    Event status at the given date and time.

    Action

    Action performed on the event at the given date and time.

    Action Performed by User

    The ID and login ID of the user who performed the cited action. The engine uses the Default IAM Admin id: xelsysadm, ID = 1.

    Date and Time

    Date and time of the cited action.

    Notes

    Any notes attached to the event at the specified date and time.


Note:

Oracle Identity Manager does not support translation of the reconciliation field names.

1.2.3 Determining Event Actions

The list of actions allowed for an event depends on the status, type, and operation of the event. Table 1-4 lists the possible actions for each type and status of events.

Table 1-4 Actions for Event Status and Types

Event Status Event Type Possible Actions

No matches found

User

Close event

Re-apply reconciliation rules

Create entity

Ad-hoc linking

 

Account

Close event

Re-evaluate event

Ad-hoc linking

Users matched

User

Close event

Re-apply reconciliation rules

Linking

 

Account

Close event

Re-apply reconciliation rules

Linking

Accounts matched

Account

Close event

Re-apply reconciliation rules

Linking

Event Received

Any

Close event


The possible actions are described in the subsequent sections.

1.2.4 Re-evaluating Events

Re-evaluating an event means reapplying the reconciliation rules on the event. Reconciliation rule refers to the matching rule used to identify the owner of an event. For instance, if you change the reconciliation rules by using Oracle Identity Manager Design Console, then you can re-evaluate the rules in the Event Management section of the Oracle Identity Manager Advanced Administration.

To re-evaluate an event:

  1. From the list of events, select an event. You can select multiple event rows by pressing the Ctrl key if you want to re-evaluate multiple events at a time.

  2. From the Actions list, select Re-Evaluate Event. The Re-Evaluate Event dialog box is displayed with the event IDs that you have selected.

  3. Click Perform. A confirmation message is displayed stating that the reconciliation rules are successfully reapplied for the event. If the selected action fails for any event, a generic message is displayed that shows the event IDs for which bulk processing has failed. The events can then be processed one at a time.

    Note:

    • The preprocess validation lists the events that are valid and those that are invalid for re-evaluation. If you click Perform, then only the valid events are re-evaluated.

    • All event actions are tracked in the Event History table.

1.2.5 Closing Events

This action closes or discards the selected events, and the events are removed from any further processing queues. To close an event:

  1. From the list of events, select an event.

  2. From the Actions list, select Close Event. You can select multiple event rows by pressing the Ctrl key if you want to close multiple events at a time. The Close Event dialog box is displayed.

    Note:

    If closing an event is not a valid option, then en error message is displayed in the Close Event dialog box.
  3. In the Justification box, enter a reason to close the event.

  4. Click Perform. A confirmation message is displayed stating that the event is closed. If the selected action fails for any event, a generic message is displayed that shows the event IDs for which bulk processing has failed. The events can then be processed one at a time.

Note:

  • All event actions are tracked in the Event History table.

  • The close event operation needs a justification to be entered. Therefore, when multiple events are closed at a time by performing bulk action, all the closed events will have the same justification.

1.2.6 Linking Reconciliation Events

Oracle Identity Manager allows you to perform the following operations for linking reconciliation events:

1.2.6.1 Ad Hoc Linking

Ad hoc linking allows you to link an event to any user or role in Oracle Identity Manager. Even if the reconciliation engine finds user matches for the events, you can use ad hoc linking to ignore those matches and select a different user. This allows you to handle exceptions resulting from error matches because the reconciliation matching rules may not work correctly all the time.

This action lets you link an event to any entity other than the already matched entities. In other words, instead of selecting a row from the Matched Users table, you can select another user to link with the event.

To create an ad hoc link for an event:

  1. In the Event Details page, from the Actions list, select Ad Hoc Link. The Ad Hoc Link dialog box is displayed.

  2. Perform a user search by specifying a search criterion.

  3. Select a user from the search result, and click Perform. A confirmation message is displayed that states that the ad hoc linking with the event is successful.

1.2.6.2 Manual Linking

When a reconciliation event has multiple matches, each match is displayed on the Matched Accounts (for account entity) or Matched Users (for user entity) tab of the Event Details page. You can manually select any match out of all the matches found by the reconciliation engine. To perform manual linking:

Note:

In manual linking, you select a match from a list of matches found by the reconciliation engine instead of selecting from a list of all Oracle Identity Manager users.
  1. In the Event Details page, select a row from the table that lists all the matches found by the reconciliation engine.

  2. Click Link. A message is displayed asking for confirmation.

  3. Click OK to confirm.

1.2.6.3 Linking Orphan Accounts

Orphan accounts refer to accounts in the target system for which there is no corresponding user that exists in Oracle Identity Manager.

You can resolve events for orphan accounts for which the events either have no user match in Oracle Identity Manager, or several users are found for the match. You can therefore perform any one of the following:

  • Re-create the user in Oracle Identity Manager

  • Trigger a provisioning process to delete the user or account from the target system

  • Perform ad hoc or manual linking

The Event Management section allows you to resolve orphan accounts by selecting the correct user for the match in the following scenarios:

1.2.6.3.1 For an Event With Multiple Matches

When several users are matched to the event data by the reconciliation engine, you must select the right user by using ad hoc or manual linking.

For information about ad hoc linking, see "Ad Hoc Linking".

For information about manual linking, see "Manual Linking".

1.2.6.3.2 For an Event With No Matches

When no matches are found for an event, you can either trigger an entity creation, or select an Oracle Identity Manager entity to link to the event. For information about how to select and Oracle Identity Manager entity to link to an event, see "Ad Hoc Linking".

1.3 Updating Reconciliation Profiles Manually

This section describes creating and updating reconciliation profiles manually in the following sections:

1.3.1 Creating New Reconciliation Profiles

You might want to create reconciliation profiles in the following scenarios:

1.3.1.1 Creating Additional Nondefault Profiles for Reconciliation Based on Resource Objects

For reconciliation based on resource objects, the default profile name is the same as that of the resource object. For example, if resource object name is testresource, then the default profile name is also testresource. The corresponding reconciliation horizontal table name is RA_TESTRESOURCE<obj_key>. If the resource has Multi-Language Support (MLS) data, then the MLS table name is RA_MLS_TESTRESOURCE<obj_key>.

If the resource object has child tables, then for each child form name, which is UD_xxx, there is a corresponding RA_UD_xx. Each of the tables has a corresponding entity definition XML file, which is stored as per platform documentation on MDS storage. Therefore, RA_MLS_TESTRESOURCE<obj_key> has an entity definition MDS document called /db/RA_TESTRESOURCE<obj_key>.xml, which is stored as per platform documentation on MDS storage.

Note:

If you change the name of a resource object, the reconciliation profile needs to be regenerated by clicking the "Create Reconciliation Profile" button in the Object Reconciliation tab in Oracle Identity Manager Design Console.

If the resource has child tables, then you must first delete all horizontal tables and entity definitions for the RA_UD_xx tables associated with the reconciliation profile, before regenerating it.

To create nondefault profiles for reconciliation based on resource objects:

Note:

You can export or import files to MDS by using the MDS export/import utility, which is run by running the weblogicExportMetadata.sh and weblogicImportMetadata.sh scripts. For information about running these scripts, see "MDS Utilities" in the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager.
  1. Create a copy of the exported profile XML file with a different name.

  2. Make changes to the file to reflect the new profile name, horizontal table names, and new reconciliation field names and mappings.

  3. Import the new profile to MDS by using the MDS import tool.

  4. Copy the entity definition XML files with new names based on the new profile name. If the reconciliation field names also change, then change the XML files to refer to the new reconciliation field names.

  5. Import the entity definition XML files to MDS by using the MDS import tool.

  6. Create new horizontal tables in the database based on the new profile name.

1.3.1.2 Creating New Profiles for Trusted Source Reconciliation

The procedure for creating new profiles for trusted source reconciliation is similar to the procedure in "Creating Additional Nondefault Profiles for Reconciliation Based on Resource Objects". The only difference is that trusted source reconciliation may or may not be associated with a resource object, and therefore, you can use the XML files corresponding to the LDAPUser profile as samples.

1.3.2 Updating Reconciliation Profiles

To change a property in a reconciliation profile, for instance batch size:

  1. Export the /db/PROFILE_NAME profile document from MDS.

  2. Make changes in the XML file, for example, change the batch size value.

  3. Import the updated profile into MDS by using the MDS import tool.

1.3.3 Changing the Profile Mode

You can use one of the following methods to change the profile mode property from CHANGELOG to REGULAR:

See Also:

"Mode of Reconciliation" in the Oracle Fusion Middleware User's Guide for Oracle Identity Manager for information about changelog and regular reconciliation modes
  • Change the value of the mode attribute in the profile, for example:

    <generalconfig mode="REGULAR"         createEntityUsingSPFlag="true"           dateFormat="yyyy/MM/dd hh:mm:ss z"               ownerMatchingRuleWhereClause="           (UGP.ugp_ldap_guid=RA_SAMPLE_HIERARCHY.RECON_ROLE_GUID)"               entitytype="RoleRole"            version="1.0"            trustedSrcFlag="false"           accountPostProcessingRequiredFlag="NOT_SET"               sequentialProcessingFlag="false"         batchSize="-1"           retryInterval="30"               maxRetryCount="5"        defaultProfileFlag="true"        name="sample-hierarchy"/>
    
  • Change the attribute during event creation:

    The event creation API, introduced in Oracle Identity Manager 11g Release 1 (11.1.1), contains three parameters. The first two parameters are same as those used in previous create event APIs. The third parameter can have attributes such as dateFormat, changeType, eventFinished, and actionDate.

    You can use this API to set the changeType as follows:

    public long createReconciliationEvent(String objName, Map<String, Object>inputData, EventAttributes eventAttribs);
    

    Note:

    Using the API to set the changeType attribute overrides the value of the changeType attribute set in the profile.

1.4 Populating Data in the RECON_EXCEPTIONS Table

The RECON_EXCEPTIONS table in Oracle Identity Manager database is used to capture error messages generated during account reconciliation. This data is collected for the purpose of generating reports.

See Also:

"Account Reconciliation" in the Oracle Fusion Middleware User's Guide for Oracle Identity Manager for information about account reconciliation

If a reconciliation match is found to a deleted user, then you must insert USER_DELETED in the REX_EXCEPTION column and the key of the deleted user in the USR_KEY column of the RECON_EXCEPTIONS table.

If no match is found, then insert USER_NOT_FOUND in the REX_EXCEPTION column.

If account match is found, then check if the account is already deprovisioned. Then insert into RECON_EXCEPTIONS table with the value RESOURCE_DEPROVISIONED in the REX_EXCEPTION column for the user who is to be provisioned.

To populate the RECON_EXEPTIONS table with exception data:

  1. Fetch all the events with the change type != ('Modify' , 'Delete') and event status as ('Single User Match Found', 'Single Org Match Found').

  2. Provision the resource object for the entities by performing the following:

    1. Collect the exception data from RECON_EXCEPTION DB table. To do so, perform any one of the following:

      • Check if the value of the XL.EnableExceptionReports property is TRUE. If it is set to TRUE, then continue to the next step. Otherwise, do not collect the exception data.

      • Select the obj_initial_recon_date in the obj table for the resource object being provisioned, and check if it is earlier than today's date. If an earlier date is displayed, then continue to the next step. Otherwise, do not collect the exception data.

    2. While provisioning the resource object to the user, check if the resource object has already been deprovisioned in Oracle Identity Manager:

      • If the resource object is already deprovisioned, then insert into RECON_EXCEPTIONS table the value RESOURCE_DEPROVISIONED in the REX_EXCEPTION column for the user who is to be provisioned.

      • If the resource object is not deprovisioned, then insert into RECON_EXCEPTIONS table the value RESOURCE_NEVER_PROVISIONED in the REX_EXCEPTION column for the user who is to be provisioned.