Working With Advanced Settings

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

Define Query to Delete SBO

Field or Control	Definition
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.

Field or Control

Definition

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	Definition
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	Definition
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.

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	Definition
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.

Field or Control

Definition

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	Definition
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.

Field or Control

Definition

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.