Working With Advanced Settings

Access the Advanced page by selecting PeopleTools > Search Framework > Search Designer Activity Guide > Search Definition and selecting the Advanced tab.

This example illustrates the fields and controls on the Advanced Properties page. You can find definitions for the fields and controls later on this page.

Advanced Properties page

Field or Control

Description

Disable Security Join

Select the check box to disable row-level query security join while performing the indexing process.

Real Time Indexing Available

Indicates whether the search definition is enabled for real-time indexing or not. If this check box is disabled, the search definition is not available for real-time indexing.

For the list of search definitions excluded from real-time indexing, see Excluding Search Definitions from Real-Time Indexing.

Define Query to Delete SBO

Field or Control

Description

Query Name

Select the query that you’ve defined to remove orphaned search documents. This is your deletion query.

For example, for rows of data that have been deleted from the database, you would want to ensure that those rows of data (or search result documents) no longer appear in the search index.

Note: Even though this query is defined the same way as the source type query is defined, the difference is that the result of the query is used for deleting the already indexed documents from the search engine. The Drilling URL field acts as the primary identifier to locate the documents to be deleted. This means the drilling URL must be identical to the drilling URL built for the original query.

Delete SBO Query will not be executed during the first index build of a search definition. It only becomes active after the initial index is populated.

See Defining a Deletion Query.

URL Link Field

Select the drilling URL field for the query selected.

Pre Processing AE Library

Before an index build is run, data can be manipulated to perform additional tasks. For example, it may be required to search through subqueries to determine if one or more subquery might have changed and to update the last updated datetime value on the parent so that the change is recognized. Another use might be to calculate or summarize a value to be indexed. Another common case for pre processing occurs when a query is created based on staging tables. In this case the pre processing Application Engine program can be used to populate the staging tables. This is useful when the data cannot be retrieved using a simple query (such as hierarchal or computed data).

You can define an Application Engine routine to perform these tasks.

Note: Pre and post processing adds to the overall indexing time, and it is recommended not to use this in scenarios where it can be avoided.

Note: Application Engine programs used for pre or post processing should be defined as type Library.

Field or Control

Description

AE Library

To call additional processing logic from Application Engine, specify the correct AE Library (Application Engine program) to run.

AE Section

Specify the Application Engine program section to run.

Post Processing AE Library

After an index is built, certain clean-up functions might need to be performed, such as removing the records in your delete query, or cleaning up staging tables. Use the post processing Application Engine routine to perform these functions.

Field or Control

Description

AE Library

To call additional processing logic from Application Engine, specify the correct AE Library (Application Engine program) to run.

AE Section

Specify the Application Engine program section to run.

Index By Data Partition

Index By Data Partition indexes large volumes of data with equal-sized partitions in parallel. You can change the number of parallel instances based on the number of AE server processes and temporary table instances. In order to use the Index By Data Partition option, you must specify the values for the available field.

This feature is applicable only to search definitions with a data source as a connected query.

Note: Index By Data Partition is applicable only when the connected query property SupportsOrderBy is True.

Note: PeopleSoft Applications that have adopted data partitions for their search definitions have already delivered appropriate settings. See PeopleSoft 9.2 Application PeopleBook for more information.

Field or Control

Description

AE Library

Specify the AE Library to populate the staging table with the keys of all the documents that need to be indexed. To establish parallel processing, the rows should be assigned with a partition number using the meta sql %RandomNatural.

AE library sample code:

/*
  * Code Snippet for Index by Data Partition Library

  * Populate staging table and assign partition number
 
  * Staging Table PS_DP_STG_JOB
	* Columns of staging Table are:
       - QE_JOB_OPENING_ID
       - PROCESS_INSTANCE
       - PTSF_DP_NBR

  * Clean Staging Table
  * Populate staging Table
  * Assign Partiton Number; use %RandomNatural to assign partition number
 
*/

/*  Clean Staging table*/
SQLExec("DELETE FROM PS_DP_STG_JOB");
SQLExec("COMMIT");

/*Get number of partitions as configured in the run control page*/
Local number &nPartCnt = PTSF_DP_SDL_AET.PTSF_DP_PARTCNT.Value;

/*Populate Staging Table and assign partition number*/
SQLExec("INSERT INTO PS_DP_STG_JOB (qe_job_opening_id,PROCESS_INSTANCE,ptsf_dp_nbr) select qe_job_opening_id , 0,%RandomNatural(:1)  from PS_QE_ALL_JOBS_VW ", &nPartCnt);
SQLExec("COMMIT");

Note: You must associate the temporary table name with the AE Library.

AE Section

Specify the Application Engine program section to run.

Staging Table Name

Specify the Staging Table Name to store the keys of the document to index. The staging table should have a structure with the application keys and the subrecord PTSF_DP_STG_SBR.

Temporary Table Name

Specify the Temporary Table Name to store the keys of the document to index. The temporary table should have a structure with the application keys and the subrecord PTSF_DP_STG_SBR.

Encode Search Attributes

Use the encode option in place of setting up custom lexers for applications that have indexed code-based fields for search attributes. Encoding these values enables the system to process the codes when generating the feed for the search index without requiring staging tables or a pre-processor Application Engine program. Encoding keeps words intact for indexing and searching that otherwise might be split during the parsing process of search index generation.

For example, a code-based search field, expects the end user to enter a code, known to the application users, that may not be interpreted as a single value by the search engine. In which case, the search engine may index the code as multiple values, losing the meaning of the code. For example, perhaps there is a product version represented by the code "M-2000". If the search engine indexes this code as two separate values, "M" and "2000" rather than "M-2000," the code loses its meaning and it no longer serves as a useful search attribute. In this case, if added to the Encode Search Attributes grid, PeopleSoft Search Framework encodes the "M-2000" value (to Mx2000 for example) so that it is indexed as a single value. While the value may be encoded for the search engine, the end user enters the code when searching as normal, requiring no knowledge of how the code is represented for the search engine indexing purposes.

If encoding search attributes, keep these items in mind:

  • Encoded attributes are not exposed to the end user. The system uses encoded values only for programmatic operation.

  • The search engine has a token limit of 64 bytes, so fields with more than 30 characters cannot be encoded. In a hierarchical value, use a word separator character to ensure the end value does not exceed 64 bytes.

  • For these values, the system encodes the search string using EncodeSearchCode PeopleCode before passing the filters to the search API.

  • For indexes containing encoded values, there can be slight overhead related to index size and query performance.

Note: Do NOT use encoded search attributes unless you are prepared to customize the underlying code. Encoded search attributes should never be displayed on a page, therefore, be careful what attributes you encode.

Full Indexing Criteria

Field or Control

Description

Index Only Last <> Days

Enter the number of days for which you want to build the index. The number of days entered are treated as days prior to the current date.

The default value is 0.

Index Start Date

The Index Start Date is calculated based on the number of days you enter in the Index Only Last <> Days field. The Index Start Date displays the date after deducting the number of days entered in the Index Only Last <> Days fields from the current date. The index will be built from the date that is displayed in the Index Start Date field.

When the value of the Index Only Last <> Days field is 0, which is the default value, the Index Start Date is set to 01/01/1900.

Alternate Search Keywords

Field or Control

Description

Alternate search keywords

Enter any alternate search keywords that users are likely to submit when running search requests. For example, rather than submitting the more official "purchase order" phrase, a user may be more likely to search on "PO" instead.

This field is translatable. If supporting multiple languages, the keywords need to be translated.