Building the Search Indexes

These topics provide an overview of the search indexes and index maintenance, list prerequisites, and discuss how to:

  • Run the Direct Reports Tables Build process.

  • Schedule a search index build.

Page Name

Definition Name

Usage

Direct Reports Tables Build Page

RUNCTL_HR_DR

Run the Direct Reports Tables Build process to build the reporting relationships for a single access type or all access types. This will fully or incrementally load all or a selected access type.

Understanding Direct Reports Functionality, Understanding the Direct Reports Performance Tables, and Direct Reports Tables Build Page.

Build Profile Groups Page

RUNCTL_JPM_GROUP

Run the Build Profile Groups process to create a profile group.

See Understanding Profile Groups and Group Types.

Deploy Search Definition Page

PTSF_DEPLOY_SBO

Deploy the person and non-person profile search definitions.

Deploy Search Category Page

PTSF_DEPLOY_CAT

Deploy the person and non-person profile search categories.

Build Search Index Page

PTSF_SCHEDULE_SI

Run the process that builds the search index for a person or non-person profile search definition.

For more information on deploying search definitions and categories, as well as building the search index, see the product documentation for PeopleTools: PeopleSoft Search Technology, PeopleSoft Search Framework content.

Search and Compare Profiles uses the PeopleTools Search Framework (PTSF) by way of Integration Broker to generate search results and perform comparisons between matching profiles. In order to complete searches, the search engine uses a set of indexes that contain data about the profiles in your system; it does not search the database tables directly.

The PTSF creates the search objects, and two source objects are supported for Profile Management. One source object contains person profile documents and the other contains non-person profile documents.

Creating the source objects involves the following sequence of steps:

  1. Deploy the Search Definition.

    • Person Profile search definition

    • Non-person Profile search definition

  2. Create Search Index Schedule .

    • For the person profile search definitions.

    • For the non-person profile search definition.

  3. Deploy the profile Search Category that combines the non-person and person profile documents into a single searchable object.

    Warning! This is required for the Search and Compare Profiles transaction. The Search and Compare Profile process requires that the Search Categories be used as delivered and should not be renamed.

Image: Processes for maintaining indexes for search and compare profiles

The diagram illustrates how the queries, search definitions, search category, and search index schedule relate to each other:
Processes for maintaining indexes for search and compare profiles

Note: It is recommended that the incremental Schedule Search Indexes process be scheduled to run following the completion of the Direct Reports Table Build Process.

Direct Reports Tables Build

The Build Direct Reports Tables process maintains the direct reports tables by updating the direct reports for managers with current information used in the in Profile Search and Compare process.

Note: The Direct Reports Tables Build process is required to build the manager security for the Search and Compare Profiles transaction. If you are not using the Manager Self Service Search and Compare Profiles transaction, then this process is not needed. The incremental updating of the Profile indexes leverages the manager hierarchy that is built based on the Access Type value specified on the Profile Management Installation page. It is required that the Direct Reports Tables Build process be scheduled to run on an interval to capture the latest organization changes.

See Configuring Direct Reports Functionality

As shown in this table, running the Direct Reports Tables Build process in incremental mode updates only the manage list information for the relevant job record.

Person ID

Employee Record Number

Manager Data Updated

12000

1

Manager data for the reporting structure for record 1.

12000

2

Manager data for the reporting structure for record 2.

Deploying the Search Definitions and Search Category

Before end users can run the Profile Search and Compare process against the search indexes, the Profile Management search definitions (HC_JPM_PERSON_PROFILE and HC_JPM_NONPERSON_PROFILE) need to be deployed to the search engine. Once the search definitions are deployed, you use categories to group search definitions within logical, manageable groups.

You do this by navigating to the PeopleTools > Search Framework > Administration > Deploy\Delete Object component, and then:

  1. Select one or several of the following search definitions from the Deploy Search Definition page and select Deploy:

    • HC_JPM_NONPERSON_PROFILE

    • HC_JPM_PERSON_PROFILE

    • HC_JPM_PROFILES

  2. Access the Deploy Search Category page to select and deploy search categories.

Before end users can submit search requests against the Search Framework deployed objects, the search indexes must first be built. Prior to the index being built, a deployed search definition contains no searchable data. Therefore, a search index needs to be built for each individual search definition.

Invoke a search index build for one or several search definitions from the Build Search Index page.

Schedule Search Process

The Schedule Search Index Application Engine process (PTSF_GENFEED) builds an index for person or non-person profile types. Select the search definition HC_JPM_PERSON_PROFILE if building the index for person profile types. Select the search definition HC_JPM_NONPERSON_PROFILE for non-person profile types. You cannot create an index for a profile type if it:

  • Is inactive.

  • Is a not an end profile type.

    When you set up a profile type, you can specify if the profile type is an end profile on the Profile Types - Attributes page. The delivered CLUSTER profile type is an example of a profile type that is not an end profile.

  • Does not have searchable properties.

    When you set up content sections for a profile type, you select the Searchable check box for the properties that you want to include in the index. If none of the content sections contain searchable properties, you can't create an index.

The process uses the profile type definition to determine what profile information is included in the index. Only those properties defined as searchable in the profile type are selected for indexing. The process retrieves active profiles, the active profile items in those profiles, and the searchable properties to include in the index. For profile types with a profile type of Person, the Schedule Search Index process retrieves manager hierarchy data and row level security for the person ID associated with the profile. If a profile type belongs to a profile group type that is defined as searchable, the profile group is also included in the index.

The index created by this process is separate from the database. It is a snapshot of the database at one point in time and does not remain synchronized with the profile data in the database unless you routinely update the index.

When the Schedule Search Index is run, the application engine process PTSF_GENFEED generates an XML feed and creates a schedule in the search engine, which in turn crawls the XML feed and builds the search index.

Searching is language-independent since only the codes and not the associated descriptions are indexed. For example, if a user searches for the competency Forecasting whose content item ID is 1000, then the search query will look for item ID 1000 and not for the word Forecasting.

The indexes represent a snapshot of the profile data and security as of the date that you last ran the Direct Reports Tables Build, Build Profile Groups, and Schedule Search Index processes. To ensure that your Search and Compare Profiles results are accurate, run these processes periodically to update the indexes and its security.

You can run the Schedule Search Index process in two modes:

  • Full Index: creates or recreates the index for the selected search definition.

  • Incremental Index: updates profile documents for an existing index based on the profile update datetime stamp (LASTUPDDTM). If the profile has been updated since the last incremental run, then this profile will be selected for re-indexing.

    Run the process according to a frequency that balances frequency of profile updates with the need to search on the most up-to-date information. You can select this process to run immediately or schedule it to run at intervals using Process Scheduler when the system usage is low.

Run the Schedule Search Index process using the Full Index mode when any of the following changes are made:

  • A new profile type is defined that has searchable properties.

  • The Searchable check box for a property is selected.

    When you select the Searchable check box for a property that previously was not searchable, the index must be recreated to include the property in the index for profiles of that type.

  • The Priority field for an Instance Qualifier is changed.

    The Maintain Profile Indexes process uses the priority field to determine which profile item row is included in the index when instance qualifiers are associated with a content section of a profile type. The row with the highest priority and highest effective date for that priority is selected for indexing only.

  • A large reorganization has occurred that impacts the manager reports or administrator row level security.

To illustrate how the Schedule Search Index process selects rows in the profile for indexing, suppose that you have defined an Instance Qualifier Set to identify the evaluation type. This table lists the instance qualifier values and their assigned priorities:

Instance Qualifier

Description

Priority

Searchable

A

Approved

10

Y

R

Supervisor/Manager

20

Y

S

Self

30

Y

Note: The priority decreases as the value in the Priority field increases. In this example, the instance qualifier with the highest priority is A and the instance qualifier with the lowest priority is S.

In this example, the employee's profile has three profile items for competencies 0010, 0200, and 0120. This table lists the profile item rows:

Competency

Date

Proficiency

Evaluation Type

0010

May 1, 2009

3 - Good

A

0010

June 21, 2009

4 - Very Good

S

0200

June 21, 2009

4 - Very Good

S

0200

June 21, 2009

5 - Expert

R

0120

January 30, 2009

2 - Fair

A

0120

May 1, 2009

2 - Fair

A

This table lists the rows that are included in the index for this profile:

Competency

Date

Proficiency

Evaluation Type

0010

May 1, 2009

3 - Good

A

0200

June 21, 2009

5 - Expert

R

0120

May 1, 2009

2 - Fair

A

Notice that:

  • For competency 0010, the row with the highest priority (lowest sequence number) instance qualifier (A) is selected even though the effective date for this row is earlier than the row dated June 21, 2009.

  • For competency 0200, the two rows have the same effective date. In this case the system selects the row that is assigned the instance qualifier with the highest priority (R-Supervisor/Manager).

  • For competency 0120, the system selects the row with the highest effective date.

Note: Instance qualifiers that are defined by a prompt record are not searchable and not included in indexes.

See Defining Instance Qualifiers.

Document level security exists for Person Profiles. The administrator can only view profiles for employees in their range of HCM row-level security. Managers can only view profiles for direct and indirect reports. Employees can only view their own profile.

The list of “manager access” Emplids and “administrator access” Class Ids is merged into a single Document Security Attribute called JPM_SRCH_SECID. When a search is executed against the Person Profile Index, this security attribute is automatically filtered based on the Profile Management role that issues the query.

Image: Security for Person Profiles

This diagram illustrates how document level security will add security attributes to the profile document and search framework will automatically apply a list of values to be matched against the security attributes of those documents returned by the search query.

Process for maintaining document level security for person profiles

Before you run the Schedule Search Index process, you must define the Supervisor Navigation Method field on the Profile Management Installation page and run the Direct Reports Tables Build process for at least that access type specified. The Supervisor Navigation Method field value specifies the reporting structure (access type) for your organization.

Before you run the Schedule Search Index process, you must set up the content catalog, define your profile types, and set up the Integration Broker.

For more information on the Search Framework, see the product documentation for PeopleTools: Search Technology.

Use the Direct Reports Tables Build page (RUNCTL_HR_DR) to run the Direct Reports Tables Build process to build the reporting relationships for a single access type or all access types. This will fully or incrementally load all or a selected access type.

Image: Direct Reports Tables Build page

This example illustrates the fields and controls on the Direct Reports Tables Build page. You can find definitions for the fields and controls later on this page.

Direct Reports Tables Build page

Field or Control

Definition

Build Mode

Select one of these modes:

Full - Complete Rebuild: Created the full organizational hierarchy. Any existing data is overwritten by this process.

Incremental - Current Date Upd: Detects where the organization hierarchy has changed and updates those changes in the tables.:

Access Method

Select the access method that was defined on your Profile Management Installation Page.

Use the Build Search Index page (PTSF_SCHEDULE_SI) to run the process that builds the search index for a person or non-person profile.

Image: Build Search Index page

This example illustrates the fields and controls on the Build Search Index page. You can find definitions for the fields and controls later on this page.

Build Search Index page

Field or Control

Definition

Search Definition

Select HC_JPM_NONPERSON_PROFILE for non-person profiles, or HC_JPM_PERSON_PROFILE for person profiles.

Note: These search definitions must be deployed prior to running this process.

Indexing type

Select on of these values:

Full index: Builds a new index for the selected search definition.

Incremental Index: Updates the existing index for the selected search definition.

Language Option

Always select the Base Language option since related language data is not indexed.