Skip Headers

Contents

15 Run Post-Load Processes for HCM Person and Employment Data

This chapter contains the following:

Processes Required After Loading Data for HCM Coexistence: Explained

Communicating Person and Assignment Changes to Consumer Applications: Explained

Maintaining Person Keywords: Explained

Person-Record Keyword Searches: Explained

Relationship Strength in the Gallery Search: How It Is Calculated

The Manager Hierarchy: How It Is Maintained

Processes Required After Loading Data for HCM Coexistence: Explained

After the successful completion of an initial or incremental data load, you must run a set of processes to complete data setup in the Oracle Fusion environment. You run these processes from the Scheduled Processes work area.

The following table describes the purpose of each of the post-data-load processes.

Process	Description
Synchronize Person Records	When you run the Synchronize Person Records process, changes to person and assignment details that have occurred since the last data load are communicated to consuming applications, such as Oracle Fusion Trading Community Model and Oracle Identity Management, in the Oracle Fusion environment.
Update Person Search Keywords	Several attributes of person, employment, and profile records are used as person-search keywords. This process copies keyword values from the originating records to the PER_KEYWORDS table, where they are indexed to improve search performance. When you run the Update Person Search Keywords process, the whole PER_KEYWORDS table is refreshed; therefore, you are recommended to run the process at times of low activity to avoid performance problems.
Calculate Relationship Strength	Gallery search results can appear in order of the strength of the relationship between the person performing the search and each person whose assignment is in the search results: the stronger the relationship, the nearer to the top of the results an assignment appears. You run the Calculate Relationship Strength process after each data load to update stored relationship-strength information.
Refresh Manager Hierarchy	For performance reasons, the complete manager hierarchy for each person is extracted from live data tables and stored in a separate manager hierarchy table, known as the denormalized manager hierarchy; it ensures that a person's manager hierarchy is both easily accessible and up to date. The Refresh Manager Hierarchy process populates the denormalized manager hierarchy table with latest information after each data load.

Communicating Person and Assignment Changes to Consumer Applications: Explained

Some Oracle Fusion applications, such as Oracle Fusion Trading Community Model, need to be alerted when changes to person and assignment details occur so that they can synchronize their information with that held by Oracle Fusion Global Human Resources.

To share changes to person and assignment details with consumer applications, you run the process Synchronize Person Records. This process raises an HCM event (ChangedPersonDetails), for which consumer applications listen. On input to the process, you can specify start and end dates; the process raises events for changes that become current between those two dates. If you specify no date, the process runs for the system date (today's date), and events are raised for changes that become current on that date.

You are recommended to schedule Synchronize Person Records to run daily.

Changes Notified to Consumer Applications

When you run Synchronize Person Records, the ChangedPersonDetails event is generated by changes to:

Person
Person name
Person work e-mail address
Person phones
Person image
Service dates
Assignments (including changes to job, position, department, work location, work location address, manager, and worker type)
Changes to the names of a person's existing job, position, department, work location, or work location address do not cause the ChangedPersonDetails event to be generated.

Maintaining Person Keywords: Explained

Several attributes of person, employment, and profile records are used as person-search keywords. Keyword values are copied automatically from the originating records to the PER_KEYWORDS table, where they are indexed to improve search performance.

This topic explains:

How person keywords are maintained
Why you run the Update Person Search Keywords process
How to schedule the Update Person Search Keywords process

How Person Keywords Are Maintained

Whenever the value of a keyword attribute changes (for example, if a person acquires a language skill or a different phone number), an event is raised. In response, services run a process to update the relevant attributes for the person in the PER_KEYWORDS table; therefore, most changes are made in PER_KEYWORDS immediately and automatically.

When you create a new person record, keyword values for that person are copied automatically to the PER_KEYWORDS table.

Why You Run the Update Person Search Keywords Process

Although most changes to the PER_KEYWORDS table are made automatically, you need to run the Update Person Search Keywords process regularly because the automatic process does not apply future-dated changes to the PER_KEYWORDS table. Running the Update Person Search Keywords process also ensures that all changes are copied to the PER_KEYWORDS table, despite any temporary failures of the automatic process.

How to Schedule the Update Person Search Keywords Process

You can run the Update Person Search Keywords process manually or schedule it to run at regular intervals (for example, weekly at a specified time).

The likely volume and frequency of changes to person records in your enterprise will determine how often you run the Update Person Search Keywords process:

If the volume and frequency are high, you need to schedule the process to run frequently.
If the volume and frequency are low, running the process once a month is recommended.

When you run the Update Person Search Keywords process, the whole PER_KEYWORDS table is refreshed; therefore, you are recommended to run the process at times of low activity to avoid performance problems.

Person-Record Keyword Searches: Explained

The application searches for keyword values in these attributes of a person's records: department, job name and code, position name and code, person name, primary e-mail, primary phone, work location, competencies, language skills, licenses and certifications, school education, awards and honors, affiliations, areas of interest, and areas of expertise.

This topic describes:

Access to restricted information
Keyword indexing
Searches using date-effective keywords

Access to Restricted Information

Access to information about a person's competencies, language skills, licenses and certifications, school education, awards and honors, and affiliations is restricted to a person's line managers. For example, if a line manager searches for a language skill and a match is found in the language-skills information of the manager's direct or indirect reports, that information appears in the search results. Restricted information is not searched and is never included in search results when the searcher is not a line manager. However, if the match is found in public information, such as areas of expertise, it appears in the search results for any user.

Keyword Indexing

Keywords are indexed values, which means that they are copied from person records and organized in a keywords table for fast retrieval. Most changes to person records are copied as they occur to ensure that there is no difference between the source and indexed values. Your enterprise can also run a keyword-refresh process to update all keywords and fix any discrepancies. Depending on when this process was last run, some recent changes to person records may not appear in search results.

Searches Using Date-Effective Keywords

In the professional user person search, you can enter an effective as-of date. When date-effective values, such as work location, are copied to the keywords table, their history is not copied: only the latest change is stored in the keywords table. Therefore, if you enter both a keyword value and an effective as-of date, the search results may not be as expected.

For example:

You change the work location of assignment 12345 from Headquarters to Regional Office on 27 January, 2011.
The changed work location is copied automatically to the keywords table on 27 January, 2011.
You search for a person on 1 February, 2011 using the keyword Headquarters and the effective as-of date 10 January, 2011.

Although the work location on 10 January, 2011 was Headquarters, assignment 12345 does not appear in the search results because the work location stored in the keywords table at the time of the search is Regional Office.

Relationship Strength in the Gallery Search: How It Is Calculated

Gallery search results can be listed in order of the strength of the relationship between the person performing the search and each person whose assignment is in the search results: the stronger the relationship, the nearer to the top of the results an assignment appears. This topic describes how relationship-strength values are calculated for individual factors, such as proximity in the manager hierarchy and work location, and how those results are combined to give an overall relationship-strength value.

How Relationship Strength Is Calculated

The calculation of relationship strength is based on several factors.

When the searcher's primary assignment is in the same organization or position hierarchy as a person's assignment, the strength of the relationship depends on their proximity to each other in the hierarchy. To calculate the relationship strength, 100 is divided by the number of boundaries plus 1 between the searcher and the person, as shown in the following table.

Hierarchy Boundaries

Calculation

Relationship Strength (%)

0

100/1

100

1

100/2

50

2

100/3

33.3

3

100/4

25

The maximum number of hierarchy boundaries to include in the calculation is 4 by default. You can set this value for the enterprise on the HR: Maximum Hierarchy Proximity profile option.
When the searcher's primary assignment is in the same manager hierarchy as a person's assignment, the strength of the relationship depends on their proximity to each other in any direction in the hierarchy. To calculate the relationship strength, 100 is divided by the number of people removed from the searcher the person is, as shown in the following table.

People

Calculation

Relationship Strength (%)

1

100/1

100

2

100/2

50

3

100/3

33.3

4

100/4

25

Only the manager hierarchy associated with the line manager of the searcher's primary assignment is included in the calculation.

The maximum number of hierarchy boundaries to include in the calculation is 4 by default. You can set this value for the enterprise on the HR: Maximum Hierarchy Proximity profile option.
The location on the searcher's primary assignment is compared with the location on the person's assignment. Relationship strength values are allocated according to the relative locations of the searcher and the person, as shown in the following table.

Location

Relationship Strength (%)

Same floor of building

100

Same building

80

Same postal code

60

Same town or city

40

Same country

20

People in a different country from the searcher have no relationship with the searcher.
The number of times the searcher selects a person's assignment from the search results is recorded automatically. This value is compared with the maximum number of times the searcher has selected any person and assignment in a specified period. For example, if the searcher selects Andrew Jones 10 times in a week and Gloria Schmidt twice in a week, then the relationship strength values are 100% for Andrew Jones and 20% for Gloria Schmidt. The period of time during which the searcher's selection history is recorded is 7 days by default. You can set this value for the enterprise on the HR: Selection History Timeout profile option.
If the searcher is in the same social network as the person, then the relationship-strength value is 100%; otherwise, the relationship-strength value is 0%.

Hierarchy Boundaries	Calculation	Relationship Strength (%)
0	100/1	100
1	100/2	50
2	100/3	33.3
3	100/4	25

People	Calculation	Relationship Strength (%)
1	100/1	100
2	100/2	50
3	100/3	33.3
4	100/4	25

Location	Relationship Strength (%)
Same floor of building	100
Same building	80
Same postal code	60
Same town or city	40
Same country	20

The relationship strength for each individual factor is multiplied by a weighting value, which is 0.5 by default, as shown in the following example.

Factor	Relationship Strength (%)	Weighting	Result (%)
Organization hierarchy proximity	100	0.5	50
Position hierarchy proximity	0	0.5	0
Manager hierarchy proximity	100	0.5	50
Location proximity	80	0.5	40
Selection history	40	0.5	20
Social network	100	0.5	50
Totals		3	210

You can change the weighting values for individual factors on the relevant profile options, such as HR: Manager Hierarchy Weight and HR: Location Proximity Weight, to change the relative importance of those factors.

Each search result has a default searcher rating of 3, which has no effect on the relationship strength. However, the searcher can set this rating for individual results to a value between 1 and 5; values above 3 increase the relationship strength and values below 3 decrease it.

Each rating value is associated with a multiplying factor. The highest multiplying factor (the one used when the searcher sets the rating for a search result to 5) is specified on the profile option HR: Relationship Priority Factor, which is set to 2 by default. This table shows the default multiplying factors

Searcher Rating	Multiplying Factor
1	1/2
2	1/1.5
3	1
4	1.5
5	2

The total of the individual relationship-strength percentages is multiplied by the multiplying factor associated with the searcher's rating. For example, if the default rating (3) applies, then 210*1 =210. The searcher can double the multiplying factor by setting a search result's rating to 5 or halve it by setting the rating to 1.

If you change the setting of HR: Relationship Priority Factor, then you automatically change the associated multiplying factors. This table shows the multiplying factors for HR: Relationship Priority Factors from 3 through 6.

Searcher Rating:	1	2	3	4	5
HR: Relationship Priority Factor 3	1/3	1/2	1	2	3
HR: Relationship Priority Factor 4	1/4	1/2.5	1	2.5	4
HR: Relationship Priority Factor 5	1/5	1/3	1	3	5
HR: Relationship Priority Factor 6	1/6	1/3.5	1	3.5	6

If you increase the HR: Relationship Priority Factor value, you increase the effect of the searcher's ratings relative to the other factors.

The result of multiplying the total of the individual percentages by the factor associated with the searcher's rating is divided by the sum of the individual weighting values. The result of this calculation is the relationship strength between the searcher and the person in the search result. For example: 210/3=70%

Results that are greater than 100 are set to 100%.

Because the factors that contribute to this calculation are likely to change often, the calculation runs daily by default and the results are stored. However, you can schedule the Calculate Relationship Strength process to suit local requirements.

The Manager Hierarchy: How It Is Maintained

In many situations, a person's manager hierarchy must be readily available. For example, a person's line managers may need to be identified during an approval process, and business intelligence reports often retrieve data based on a manager hierarchy.

How the Manager Hierarchy Is Maintained

A person's manager hierarchy could be derived from live data tables, but the impact of that approach on performance is unpredictable. Therefore, the complete manager hierarchy for each person is extracted from live data tables and stored in a separate manager hierarchy table, known as the denormalized manager hierarchy; it ensures that a person's manager hierarchy is both easily accessible and up to date.

The Refresh Manager Hierarchy process populates the denormalized manager hierarchy table when person records are migrated from other applications. Otherwise, whenever a change is made to a person's manager hierarchy, the change is reflected automatically in the denormalized manager hierarchy table. However, by running the Refresh Manager Hierarchy process in addition to these automatic individual updates, you can ensure that the denormalized manager hierarchy is as accurate as possible. Refresh Manager Hierarchy processes all types of manager hierarchies.

The Refresh Manager Hierarchy process has no default schedule; however, you can run the process occasionally to perform a complete refresh of the denormalized manager hierarchy. Alternatively, you can specify a schedule to run the process at regular intervals.