12 Managing Reconciliation

Reconciliation is the process by which operations, such as user creation, modification, or deletion, started on the target system are communicated to Oracle Identity Manager. The reconciliation process compares the entries in Oracle Identity Manager repository and the target system repository, determines the difference between the two repositories, and applies the latest changes to Oracle Identity Manager repository.

Reconciliation of roles, role memberships, and role hierarchy changes are handled as separate reconciliation events. Ideally role events must be submitted first and then only the membership events in order to avoid race conditions. For race conditions, the automatic retry logic allows the reconciliation engine to handle it.

See Also:

"Handling of Race Conditions" in the Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Manager for information about race conditions

Figure 12-1 shows that provisioning and reconciliation involve synchronization from Oracle Identity Manager to the target system or from the target system to Oracle Identity Manager. Provisioning and reconciliation enable the provisioning system to build the managed identities in the target system as well as replicate the managed identities as they already exist in the target system.

Figure 12-1 Provisioning and Reconciliation

Description of Figure 12-1 follows
Description of ''Figure 12-1 Provisioning and Reconciliation''

In Figure 12-1, a user is created by the HR representative when a new employee joins. The user is reconciled to Oracle Identity Manager by trusted source reconciliation. When the user is created in Oracle Identity Manager, the account for the user is provisioned in the target system. In the target system, the target system administrator can make changes in the account, which must be reconciled to Oracle Identity Manager.

In terms of data flow, provisioning provides the outward flow from the provisioning system by using a push model, in which the provisioning system indicates the changes to be made to the target system. Reconciliation provides the inward flow into the provisioning system by using either a push or a pull model, by which the provisioning system finds out about any activity on the target system.

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 consequently because of changes occurring in the target system are managed by using the Event Management section in Oracle Identity System Administration, which addresses these event management needs. See "Managing Reconciliation Events" for information about managing reconciliation events by using Oracle Identity System Administration.

This section consists of the following topics:

See Also:

"Customizing Reconciliation" in the Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Manager for information about reconciliation features and architecture

12.1 Types of Reconciliation

Reconciliation can be of different types, as shown in Table 12-1:

Table 12-1 Types of Reconciliation

Classification Criteria Reconciliation Type

Object being reconciled

Based on identity being reconciled, such as user, account, role, organization, or relationship that includes role hierarchy and role membership

Mode of reconciliation

Changelog
 

Regular

Approach used for reconciliation

Incremental reconciliation
 

Full reconciliation

This section describes the following topics:

12.1.1 Reconciliation Based on the Object Being Reconciled

Reconciliation depends on the entity object that is being reconciled. The following entities in Oracle Identity Manager are reconciled:

  • User: A user is an identity that exists within and is managed through Oracle Identity Manager.

  • Account: An account entity is granted to a user in Oracle Identity Manager. It represents a collection of the attributes and privileges for the user that uniquely identifies the user in a provisioning target. The existence of an account in Oracle Identity Manager makes it possible for the user to access the provisioning target.

  • Organization: An organization entity represents a logical container of entities, such as users and other organizations, that exists in Oracle Identity Manager.

  • Role: A role is a logical grouping of users to whom you can assign access rights within Oracle Identity Manager, provision resources automatically, or use in common tasks such as approval and certification.

  • Role hierarchy: Role hierarchy is the inheritance of the parent role to child roles. The parent role has the same permissions and privileges on the members as the inherited roles.

  • Role membership: Role membership means that the members of the inheritor role inherit from the inherited role. See "Managing Roles" in Oracle Fusion Middleware Administering Oracle Identity Manager for detailed information about membership and permission inheritance.

This section discusses the following topics:

12.1.1.1 Trusted Source Reconciliation

If data is reconciled from a system that drives the creation of users, roles, role memberships, or role hierarchies in Oracle Identity Manager repository, then that reconciliation mode is called identity reconciliation, or authoritative source reconciliation, or trusted source reconciliation. The system that is being reconciled from is referred to as the authoritative source for the enterprise identities, and may be an HR system or a corporate directory.

Note:

If the user login is not passed for trusted reconciliation, then the login handler generates the user login. The password is generated in postprocessing event handler, and notification is sent for the same.

As shown in Figure 12-2, the authoritative sources of identity may be more than one. The different authoritative sources may be the source of reconciliation for different categories of user identities or may be the source of reconciliation for different sets of attributes. The various events generated by the reconciliation engine are add, modify, and delete.

Figure 12-2 Trusted Source Reconciliation from Single and Multiple Authoritative Sources

Description of Figure 12-2 follows
Description of ''Figure 12-2 Trusted Source Reconciliation from Single and Multiple Authoritative Sources''

In Figure 12-2, trusted source reconciliation from a single authoritative source and multiple authoritative sources are shown. Creation of user entities can be reconciled from multiple authoritative sources. In addition, different attributes can be reconciled from different multiple authoritative sources. For example, the user ID and e-mail ID can be provided by an authoritative source and role attributes can be provided by another authoritative source.

Trusted source reconciliation must be followed by account reconciliation when the target system is the source for identities as well as accounts. For instance, if Active Directory is the corporate LDAP repository in which user information is stored, then the user information is reconciled from the Active Directory target system. Subsequently, the Active Directory accounts are reconciled into Oracle Identity Manager by using a different connector. Identity reconciliation occurs only from trusted sources, by using connectors specific to those trusted sources.

Note:

A reconciliation connector is a component developed to reconcile identities or accounts from a specific target system. Typically, a reconciliation connector is configured to be run as a scheduled task. However, there are push-based connectors, such as the PeopleSoft HR connector, for which there is no scheduled task to trigger the reconciliation.

12.1.1.2 Account Reconciliation

If the target system identities are accounts that get reconciled to Oracle Identity Manager, then that is target resource reconciliation or account reconciliation. This type of reconciliation is to reconcile a specific resource object that represents the target system being managed. There is always a corresponding provisioning flow for it. The identity retrieved from the target system maps to a resource object instance that has been provisioned to a user or organization.

Account reconciliation takes place in the following scenarios:

Scenario I

Identity gets created in Oracle Identity Manager from an authoritative source. The identities are provisioned with resources on the target system. Any change on the target system is reconciled with Oracle Identity Manager. Figure 12-3 shows account reconciliation from a target system:

Figure 12-3 Account Reconciliation From a Target System

Description of Figure 12-3 follows
Description of ''Figure 12-3 Account Reconciliation From a Target System''

Scenario II

In this scenario, the target system initially plays the role of an authoritative source. Later it plays the role of a regular provisioning target. Following are the sequence of steps:

  1. Identities are created in Oracle Identity Manager based on the target system entity details. Corresponding accounts are also created for these entities.

  2. The entities are updated as provisioned entities in the target system.

  3. The resource administrator at the target system makes changes to the accounts.

  4. The changes made on the target system are reconciled with Oracle Identity Manager.

Figure 12-4 shows identity reconciliation followed by account reconciliation:

Figure 12-4 Identity and Account Reconciliation

Description of Figure 12-4 follows
Description of ''Figure 12-4 Identity and Account Reconciliation''

Note:

When the value of the XL.UserProfileAuditDataCollection property is set to an audit data collection level, then the account reconciliation performs the matching in the database layer at a batch-level and performs the event action by using the provisioning APIs. This in turn triggers the audit event handlers for account reconciliation. By default, the value of this property is set to Resource Form. See "Administering System Properties" for information about system properties in Oracle Identity Manager in the Oracle Fusion Middleware Administering Oracle Identity Manager.

12.1.1.3 Reconciliation Process Flow

The reconciliation process flow is shown in Figure 12-5:

Figure 12-5 Reconciliation Process Flow

Description of Figure 12-5 follows
Description of ''Figure 12-5 Reconciliation Process Flow''

Reconciliation process involves the following steps:

  1. Changes in the target system: The various activities that can happen in the target system are creation, modification, or deletion of user, account, role, role membership, or role hierarchy.

    Note:

    If you create an entity on an external system and then modify it a short time later, reconciliation processes the create entity step, but the modify entity step fails with the Creation Failed event status. This is because reconciliation cannot process a create and a modify action for the same entity in the same batch process.

    However, the entity modification action can be resubmitted for reconciliation at a later time by one of the following built-in mechanisms:

    • The "Automated Retry of Failed Async Task" scheduled task will run to re-process the failed events without any manual intervention.

    • The failed event is re-processed if the "Manual Retry Error Handling Mechanism" is triggered.

    Reconciliation failure messages that are caused by processing conflicts within the same batch process should be regarded as transitory failures only.

  2. Providing reconciliation data: When the creation, modification, or deletion event occurs, data about that event is sent to the reconciliation service by using reconciliation APIs.

    Note:

    Reconciliation service refers to the collection of reconciliation engine, reconciliation APIs, and the associated metadata and schema.

  3. Creation of reconciliation event record: When the data for a reconciliation event is provided to reconciliation service, a record of that event is stored in Oracle Identity Manager repository.

  4. Processing of the reconciliation event data: The data received is then evaluated to determine the actual operation to be performed in Oracle Identity Manager based on the changes in the target system. The evaluation involves application of a specific set of rules that help in:

    1. Identifying whether the data is for an account or for an identity that Oracle Identity Manager already has a record of

    2. Identifying the owner of the account or identity that the data represents

    3. Defining the context-sensitive action to be taken

    4. Setting the status of the event at the end of evaluation and the action that the reconciliation engine must take

  5. Taking action on the event: Based on the evaluation result of processing the reconciliation event data, the intended action is taken. The various actions can be:

    Note:

    The actions on the event can be manually performed through the UI, or they can be automatic actions.

    • Creating a new account and associating with proper owner identity

    • Updating the matched account

    • Deleting the matched account

    • Creating a new user in Oracle Identity Manager

    • Modifying an existing user in Oracle Identity Manager

    • Deleting an existing user

    • Enabling and disabling account status by updating the status attribute

    • Enabling or disabling user

    • Creating, updating, or deleting role

    • Creating or deleting role membership

    • Creating or deleting role hierarchy

    See Also:

    "Reconciliation Engine" in the Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Manager for information about role membership and role hierarchy

  6. Follow up actions triggered by the reconciliation event: After the action is taken, follow up tasks can be started based on the reconciliation event. An example of follow up tasks or post-processing task is creating a request to provision a resource, such as a laptop computer, after a user creation event.

12.1.2 Mode of Reconciliation

The mode of reconciliation is either pull or push that depends on the connector used. Most connectors, such as Active Directory, use the pull model. For the pull model, a pull reconciliation task is scheduled in the IAM Scheduler. The task runs at recurring intervals.

See Also:

"Managing the Scheduler" for information about the IAM Scheduler

Typically, the pull-based reconciliation connectors submit the reconciliation events within a scheduled task. Every time the scheduled task runs, a new reconciliation run is triggered and the reconciliation events are created in batches. When the batch size is met, the batch is submitted for processing. At the end of the scheduled task, an end of job listener is triggered, which submits all the batches whose size is not met.

Other reconciliation connectors, such as the PeopleSoft connector, use a push model. The connector comprises of an HTTP listener that detects any asynchronous messages issued by PeopleSoft. On receiving a message, the listener submits reconciliation events by calling the reconciliation API. The events are processed by the reconciliation engine in batches when the batch size is met. For batches where batch size is not met, a scheduled task runs periodically and submits the batches for reconciliation processing.

Pull or push model is used based on the nature of the target system and how the changes can be detected in the target system. But irrespective of the push or pull model being used, reconciliation is performed by using a scheduled task that runs in the IAM Scheduler.

Note:

You can also create the reconciliation events directly by using the reconciliation APIs.

Changelog reconciliation is the default reconciliation mode. In this mode, only changed attributes are reconciled. Unspecified fields are ignored. You typically use the Changelog reconciliation mode when a connector is aware of the list of changed attributes. Along with the changed attributes, Oracle Identity Manager needs a list of required fields for matching. The Changelog reconciliation mode was supported in previous Oracle Identity Manager releases, so all connectors work in this mode.

Regular reconciliation is a new reconciliation mode, introduced in this release, where the reconciliation engine completely replaces the existing snapshot of the entity. You typically use this reconciliation mode when the connector cannot determine which attributes have changed, and therefore, sends an entire snapshot of the entity. For new connectors, you can specify this mode when performing a full reconciliation. Using regular reconciliation mode results in better performance because the events are processed faster.

Note:

The mode of reconciliation depends on the connector implementation. For information about connector implementation, see "Connector for Reconciliation" in the Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Manager.

Table 12-2 lists the differences between regular and changelog reconciliation modes:

Table 12-2 Regular and Changelog Reconciliation Modes

Regular Changelog

Must pass a full set of mapped attributes

Must pass a subset of mapped attributes that are required by the specific profile and used by matching a rule

Performs better in batch processing mode (no difference in performance while in single event processing mode)

  

Creates and updates all fields

Creates and updates only specified fields, and all other fields remain unchanged

See Also:

"Changing the Profile Mode" in the Oracle Fusion Middleware Developing and Customizing Applications for Oracle Identity Manager for information about changing the reconciliation mode

12.1.3 Approach Used for Reconciliation

When you run reconciliation for the first time on a target system, all users and accounts on the target system are reconciled into Oracle Identity Manager by default. This is called full reconciliation. To perform full reconciliation, the connector sends the reconciliation events for each entity in the target system. The reconciliation engine processes the events as create or update events depending on whether or not the entity already exists in Oracle Identity Manager. The connector also identifies all the deleted entries and sends the deletion events to Oracle Identity Manager.

At the end of full reconciliation, the connector typically sets the last execution time parameter to the time when the reconciliation run ends. For the next reconciliation run, only the entity records that have been added, modified, or deleted after the first reconciliation run ended are fetched for reconciliation. This is called incremental reconciliation.

You can manually switch from incremental reconciliation to full reconciliation by setting the value of the timestamp IT resource parameter to 0.

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

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. These reconciliation runs are scheduled to run by using the Oracle Identity Manager Scheduler.

See Also:

""Managing the Scheduler"" for detailed information about the scheduler

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

12.2.1 Searching Events

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

12.2.1.1 Performing a Simple Search for Events

To perform a simple search for events:

  1. Login to Oracle Identity System Administration.

  2. In the left pane, under Provisioning Configuration, click Reconciliation. The Advanced Administration is displayed with the Reconciliation section in the Event Management tab active.

  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.

12.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 12-3 lists the fields in the Search: events page.

    Table 12-3 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), delete, or changelog.

    Profile Name

    The name of the reconciliation profile this event pertains to.

    See Also: "Reconciliation Profile" in the Oracle Fusion Middleware Developing and Customizing Applications 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, Current 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

12.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 12-4:

    Table 12-4 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 12-5:

    Table 12-5 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.

12.2.3 Determining Event Actions

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

Table 12-6 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.

12.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 Reevaluate Event. The Reevaluate Event dialog box is displayed with the event IDs that you have selected.

  3. Click Reevaluate. 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 Reevaluate, then only the valid events are re-evaluated.

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

12.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 Close. 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.

12.2.6 Linking Reconciliation Events

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

12.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. Click the lookup icon, and perform a user search.

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

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

12.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:

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

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