Introduction

As customers work towards implementing Fusion Applications (FA) in their enterprise and prepare for go-live, the enterprise user and role identity data from various HR applications needs to be migrated to FA, so that the users can become part of FA system and be able to use the application. There are a number of steps involved in this process and performing partial steps in lower environments does not prepare sufficiently for a go-live preparation to a production environment. In this article, we will cover the important steps involved and some helpful tips for a successful user and role load.

High-level Steps of Initial Bulk Load

To migrate the Users and Role identities to FA, user and role information can be collected from various enterprise applications and brought in to FA using tools offered with the FA release the customer is using. For Release 7 and Release 8 of FA, Human Capital Management (HCM) File-Based Loader (FBL) is the recommended option for bulk-load. While Release 9 includes an evolution of FBL, this is not covered in detail in this article, FBL can still be used with Release 9.

FBL enables you to bulk-load data from any data source to HCM for the initial load as well as for on-going maintenance of the data by means of periodic batch loading. Please refer to the documents listed in reference section below for full list of FBL capabilities and limitations and detailed steps of execution. The following diagram depicts the high-level steps of using FBL:

As noted in the diagram above, data gathered from various sources is transformed for import using FBL. The tool helps with data validation and up to loading the data into FA. After a FBL run, you will see the users and roles reflected in the FA product families. However, the users and roles loaded using FBL cannot be used, as yet. There is further down-stream provisioning needed before we can login using the user-id of any of the users just loaded. Before we look at the steps of how to provision down-stream, it helps to understand user and role identity containers in FA. Let’s look at that next.

User and Role Identities in FA

User and Role identity information is stored primarily in 3 containers in a typical FA deployment:

1. FA-HCM (Even if you meant to use other product families, HCM module is always used in FA to manage User and Role identity)

2. Oracle Identity Manager (OIM)

3. Oracle Internet Directory (OID).

During run-time, the identity information in all of these 3 containers is applied to the users and used in enforcing security and entitlement policies of FA. For more details, please refer to the ‘Implementing Workforce Deployment’ document: https://docs.oracle.com/cd/E48434_01/fusionapps.1118/e49577/toc.htm

The following diagram gives an overview of the flow of user and role identity information between them:

We discussed FBL and the process of loading users and roles into FA HCM. Now, as per the flow in the diagram above, we need the users and roles provisioned in OIM and in-turn provisioned to the OID server. So that, when a user tries to login to the FA system, Oracle Access Manager (OAM) can authenticate the user by looking up the user in OID. Likewise, much of the FA security policy enforcement is performed based on what user and role information is available in OID. Hence, after step 1.FBL, step 2. ‘Send Pending LDAP Requests’ must be manually invoked to provision the users downstream. There are scheduled jobs that take care of step 3 to provision the users into OID. Once we have established that the steps 1, 2 and 3 have been run, step 4. ‘Retrieve Latest LDAP Changes’ can be invoked manually to complete the full cycle. Step 4, ‘Retrieve Latest LDAP Changes’ brings in updates made in the IDM systems (OIM, OID and APM) to FA HCM. The step marked ‘1.1.Person Synchronization’ helps to ensure user information is complete and also help cover dated actions. This 1.1 step must always be run at the beginning of the cycle followed by Step 1.2 Retrieve Latest LDAP Changes’ for initial load.

If a customer were to perform step 1, FBL and not continue through the rest of the steps under the assumption that the rest of the steps are not significant, they would not come away with a full understanding of the importance of remaining steps of the process, nor would the users and roles be fully provisioned in the system. So, it is important to complete all 4 steps in at least one lower environment before attempting to do this in production environment for the first time. This so you have a full appreciation of the complete process and an ability to plan for go-live activity.

Completing All the Important Steps

Assuming step 1.FBL is completed, let’s look at completing the ‘Send Pending LDAP Requests’ job to provision the users downstream from FA HCM. This is an important and resource intensive step that needs to be carefully executed with proper planning.

Firstly, the FA system must be properly tuned. There is good guidance available in FA tuning document. Please review FA tuning guide from the link below and make sure you apply recommended parameters for your FA environment needs:

http://docs.oracle.com/cd/E36909_01/fusionapps.1111/e16686/toc.htm#BEGIN

If we were to point one primary component that must be tuned, we would look at the OID processes. This component is kind of security-central for the overall FA application and must be tuned properly for a good performance of the FA system anytime. It is very easy to tune this component as detailed in the above document. Next, the OIM and SOA components tuning certainly helps in the next step. The tuning document above details the necessary JVM heap size and data source tuning parameters among others.

Once tuning is completed, and you are now ready to invoke the step 2. ‘Send Pending LDAP Requests’ job, be prepared with a few SQL queries to track the progress of the load – as shown below. At the end of step 1. FBL load, you would see multiple LDAP requests generated in status of CREATE and REQUEST.  You may query the status, as they get processed by the ‘Send Pending LDAP Requests’. A sample SQL query such as below, gives a snapshot of the requests:

Once step 2 is finished, you may export the output to a spread sheet to process success and failures and resolve any issues for a re-run. There can be reasonable errors such as user id already exists or invalid data that may prevent the process from completing. So, you may correct those errors and a re-run could complete them. For example, error ‘IAM-3076036 – User with the attribute mail, value <email_id> already exists’ can be corrected by updating the user record with a correct email id. Error code IAM-3071004 means the user is not correctly setup with a manager record. For more details on the error codes, please refer to Doc ID 1509644.1 in support.oracle.com.

Also, since this provisioning to OIM and OID, steps 2 and 3, are resource intensive steps, it is a good idea to split the load and load users in small batches. When the users are brought in with FBL, make that a smaller manageable size that performs better for your environment requirement. Say, you are bringing in a total of 100,000 users, then it may be good to load them in batches of 25,000. Load 25,000 users in first batch using step 1. FBL and complete steps 2, 3 and 4. Then bring in next 25,000 in FBL and so on.

There are pros and cons of running in smaller batches as with any batch processing, but achieving the right size is important. Smaller batches help in reducing the stress on the system and also help in error handling. Depending on the performance you get, you may adjust the size of the load.

It is a good idea to plan for dedicated time for the system to complete step 2. ‘Send Pending LDAP Requests’ process, since a general slowness may be observed in user login performance during this load. Hence, you may plan for one batch over-night or few batches over a weekend. This helps in avoiding conflicts, were the system to be shared by other work streams. Allowing sufficient dedicated load-time gets this process complete relatively faster.

There are several good documents, listed in the reference section, in My Oracle Support to prepare and monitor the progress of this phase and trouble-shooting articles that you would find valuable.

Besides the initial load, it is important to plan and schedule for the ongoing incremental processing once the system is in use. By looking at the number of users created or updated, roles created or updated in previous systems, a set of these jobs we looked at above need to be scheduled. Step 1.1 must always be executed at the beginning of scheduled cycle. Step 3. OIM LDAP Synchronization can also be manually invoked using OIM scheduled jobs. ‘LDAP Role Create and Update Full Reconciliation’ and ‘LDAP Role Create and Update Reconciliation’ are some important ones. For further details on how these programs work, and when to schedule them, see ‘Synchronization of User and Role Information with Oracle Identity Management: How It Is Processed in the Oracle® Fusion Applications Coexistence for HCM Implementation Guide.

Summary

A few take away points from this article for initial bulk-load:

1. Load initial bulk load of users and roles in batches of size relative to your environment.

2. Proper tuning of OID, OIM and SOA components are key to the success of this process

3. Run the full process discussed here in at least one environment before production load and plan to allow dedicated system resources for the job.

4. Prepare / gather necessary monitoring and validation scripts beforehand for easy monitoring and progress during the load.

5. Plan for and run scheduled jobs discussed above on an ongoing basis to keep the information flow current.

Reference

My Oracle Support Docs:

File-Based Loader for Release 7 & 8 – 1595283.1

File Based Loader Diagnostics Release 7 & 8 – Doc ID 1594500.1

User and Role Provisioning – Troubleshooting Guide (Doc ID 1459830.1)

Fusion HCM: Common BPEL and OIM error messages in User and Roles Provisioning (Doc ID 1509644.1)

All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission