Guidelines for Batch Loading Workers
This topic lists the guidelines to follow when loading over 100,000 workers during cut-over activities as part of go-live, and complete the related processing with minimal overhead.
Prerequisites
Prepare Worker HCM Data Loader (HDL) Data File
- Set
INVOKE_POST_PROCESS
to N to avoid automatic submission of each HDL Worker data load post-processing jobs. This will avoid submitting too many post-processing jobs that can get blocked with each other. Once the planned workers dat files are loaded, post-processing can be done manually. Refer the Disable Postload Processing topic for more information. - Set GeneratedUserAccountFlag to N for workers for whom a user account isn’t required.
- Don't configure any role mappings yet. This is to ensure that no role memberships are provisioned at the time of account creation. Role provisioning can be done in a later step.
- Ensure these processes aren’t running or scheduled to run.
- Synchronize Person Records
- Maintain Party and Location Current Record Information
- Refresh Manager Hierarchy
- Update Person Search Keyworkds
- Optimize Person Search Keywords Index
- Send Pending LDAP Requests
- Autoprovision Roles for All Users
- Send Personal Data for Multiple Users to LDAP
- Ensure the Apply Name Formats to Person Names, Keywords and LDAP process set isn’t running.
You need to do these steps in the listed order after you complete the steps in Preparing the Worker HDL Data File.
1 - Load Workers and Synchronize Person Records
Typically, you run the Synchronize Person Records process to synchronize workers' person records in HCM with party records in Trading Community Architecture (TCA) to manage HR Help Desk, Payroll, Expenses, and so on.
Since a large number of worker records are created, updated, or both this process can result in events processing overhead for the Enterprise Scheduler Service (ESS) or the Service Oriented Architecture (SOA) servers. Hence, it’s recommended to use this approach.
- Split the workers data file into batches if there are more than 100,000 workers to load. It's recommended not to exceed 100,000 workers per batch.
- Ensure the Synchronize Person Records ESS process isn’t running.
- Set these profile options.
- ORA_HZ_ENABLE_MPLCRI_ACTIVE_WORKER to Yes
- HRC_DISABLE_HCM_EVENTS_PROCESSING to Yes
- Load worker data in batches of 100,000 or less and synchronize them to create
party records. Repeat these steps until all workers are loaded and
synchronized.
- Load a batch of worker data
- Run Update Person Search Keywords ESS process with Batch ID as 1 to create Person Type Usage records that are required by the next step. This step doesn’t create person search keywords, it only creates Person Type Usage records required for the next step.
- Run Maintain Party and Location Current Record Information ESS process
with these parameters.
Parameter Value Synchronization Type Worker Person Type Null or Default From Date Date on or after which worker records are loaded To Date Date on or before which worker records are loaded Person Number Null or Default
- After all worker data is loaded and synchronized successfully, set these profile
options to No. This step is extremely important to make sure the application
functions normally after go-live.
- ORA_HZ_ENABLE_MPLCRI_ACTIVE_WORKER to No
- HRC_DISABLE_HCM_EVENTS_PROCESSING to No
These profile options are set to Yes only when you’re synchronizing a large number of person records to create parties. When you set the HRC_DISABLE_HCM_EVENTS_PROCESSING profile option to Yes, it disables all HCM events across all modules including HCM approval transactions. Hence, this profile option should be set to No at all other times. Since the above steps will synchronize person records in bulk, don't run the Synchronize Person Records ESS process at this time.
2 - Refresh Manager Hierarchy
Run the Refresh Manager Hierarchy ESS process to de-normalize manager hierarchy information for all workers.
3 - Create Person Search Keywords and Optimize Keywords Index
After all workers are loaded for the first time, create person search keywords for people.
- Run Update Person Search Keywords ESS process with all parameters left blank to create keywords for all workers.
- Run Optimize Person Search Keywords ESS process with default parameters.
4 - Create User Accounts
After all the workers are loaded, these LDAP requests are created.
- CREATE - Request to create a new user account
- UPDATE - Request to update an existing user account
- TERMINATE - Request to terminate the user account. Created only if workers with termination dates are loaded.
The following points are expected because when workers are loaded there shouldn't be any role mappings:
- For CREATE request types, there are no records in PER_LDAP_ROLE_MEMBERSHIPS
- No requests of type USERROLE should exist.
Create User Accounts
Create user accounts for all eligible workers without assigning any roles to users.
- Don't load the Users HDL dat file to assign any role memberships.
- Go to User Account
Maintenance to None..
- This option controls whether to suspend user accounts if the user has no roles provisioned.
- When set to None, SUSPEND requests are created as SUPPRESSED.
(do not use Update) and set - Run Send Pending LDAP Requests ESS process with Batch Size = 20. This creates User Accounts for eligible workers in Identity Store, and creates SUSPEND requests in SUPPRESSED status and user accounts without roles aren't suspended.
- Go to User Account Maintenance to Both Person and Party. (do not use Update) and set
If all workers have the same email address, it's recommended not to set the username generation rule to email address because it can cause performance issues with the Send Pending LDAP Requests ESS process. The application has to make multiple trips to the LDAP server to generate unique usernames based on the same email address for all workers. Therefore, it's recommended to use a username generation rule other than Email or pre-generate unique usernames and load the Workers dat file instead of the application generating it.
5 - Provision Roles to Users
Assign roles to user accounts created in step 4.
- Configure all required role mappings.
- Enable bulk operation for the Autoprovision Roles for All Users ESS job using
these steps.
- Go to .
- Create a new profile option with these details. The profile option must
be updatable only for SITE level.
Field Value Profile Option Code PER_AUTO_PROVISION_ROLES_ENABLE_BULK Profile Display Name Enable Bulk Mode for Autoprovision Roles Application Global Human Resources Module Users Start Date <Today's date> - Set the profile value to Y at the SITE level.
- Run the Autoprovision Roles for All Users ESS process with default input parameters. Roles are provisioned to users based on role mapping rules. If roles are provisioned to suspended user accounts, those accounts will be activated.
6 - Synchronize Personal Data for Users from HCM to Identity Store
- After workers are loaded for the first time and user accounts are created, run the Send Personal Data for Multiple Users to LDAP ESS process with All users as the parameter. This step updates all personal information including manager details for the workers in their user account details.
- Depending on the user population size, this process can take time to complete.
Enable concurrent processing to improve throughput.
- Go to .
- Create a new profile option with these details. The profile option must
be updatable only for the SITE level.
Field Value Profile Option Code PER_IIP_SEND_PERSONAL_DATA Profile Display Name PER_IIP_SEND_PERSONAL_DATA Application Global Human Resources Module Users Start Date <Today's date> - Go to .
- Set the execution_mode_concurrent=Y for the profile option at SITE level
7 - Schedule Required ESS Processes
After cut-over is completed and the Fusion HCM application is in regular use, schedule these processes as per the recommendations in this documentation on My Oracle Support.
- Fusion Global HR: ESS Jobs - Person Area (Doc ID 1593212.1)
- Best Practices for User and Role Provisioning in HCM