Working with Global Search
This section provides an overview of working with global search.
Global Search provides a way for a user to search across all search indexes or a specific group of search indexes. End users submit a Global Search using the Global Search Bar, which is available in the Portal header throughout the user's session irrespective of the content the user is accessing in the target frame. The Global Search feature allows the user to search and drill down to a specific row of data or transaction from the search results, all without navigating through a menu structure to the classic component search page and entering search criteria there. In an Interaction Hub environment, Global Search can search across indexes from multiple content systems.
Image: Global Search bar
This example illustrates the search icon and the Global Search bar. You can find definitions for the fields and controls later on this page.
The Global Search Bar consists of:
drop-down list for selecting a specific search group, containing the desired indexes.
free text search edit box.
When implementing Global Search, it is highly recommended to employ search contexts and search groups. These constructs work together to refine the user interaction with the Global Search Bar drop-down list.
A search group is a type of search category that is exposed to Global Search to help manage search definitions deployed to the search engine. Search groups provide a way to show relevant categories based on the context the user is in on the target frame. A search definition can belong to multiple search groups. You manage search groups in the Search Framework Administration Activity Guide. In an Interaction Hub installation, for example, search groups can be formed to include search definitions deployed across content systems.
Using search contexts, you can configure search groups such that based on the context in the target frame, only a subset of all possible search groups are available to the user in the Global Search Bar. For example, if the end user is accessing content from a PeopleSoft Financial application, then only search groups relevant to that application will be available. Likewise if a user is accessing content from a PeopleSoft Human Capital Management application, then only search groups related to that application will be available.
At any given time, end users have these types of search groups available:
All: This search group will always be available and is a group of search categories that span across all the indexes that have been deployed and made searchable for a PeopleSoft application.
Component Specific: This type of search group will match the component the user is currently viewing in the target frame. For example, if a user is viewing an expense report, then the Expense Report component would be the search group that is available, if the component is indexed, and it does not apply already to the Home Page context.
Note: Only Home Page search context can be used. Template level and Node level search contexts cannot be used. If a search context is not defined for Home Page, then only the All search group is displayed.
In an Interaction Hub installation, Portal’s Home Page search context is used always.
Global Search shows search groups in the Global Search Bar based on a user's role. To set up permissions to search groups, you use PeopleTools Security permission lists. Setting up role-based search group access is discussed in the Security topics in this document.
This section contains an overview and describes how to set up the portal registry search.
Understanding the Portal Registry Search
PeopleTools provides the search definition, PTPORTALREGISTRY, which enables you to index the content references registered in the portal menu registry. If you deploy this search definition and build the index (just as you would any search definition), end users can search for content references and menu items using the free-text edit boxes and navigate to the underlying pages using the search results, rather than navigating the menu structure manually. This can provide an extremely efficient means of accessing application content.
Note: The portal registry menu search is named Navigator.
Note: The PTPORTALREGISTRY search definition provides a similar option as the portal registry search that has been available with the Verity search engine for previous application releases.
If you run the search from the menu pagelet or drop-down navigation Search Menu edit box, the search request only goes against the current portal. For example, if the user is currently logged into the EMPLOYEE portal, the search will be specific to content references defined within the EMPLOYEE portal only.
If you run the search from the Global Search Bar, the search request goes against all the portals defined in the local portal registry.
The PTPORTALREGISTRY search definition is based on the delivered PTPORTALREGISTRY query, which verifies the "Valid From" and "Valid To" dates for content references.
Note: For more accurate search results, it is recommended that you schedule running your index updates based on how often the content references in your system change effective dates and expire dates.
Setting Up the Portal Registry Search
To enable Portal Navigator Search:
Deploy the PTPORTALREGISTRY search definition and category.
Build the index.
There are some additional options that can be added as well:
To add "Auto suggest," add permission using PeopleTools, Security to this web library: WEBLIB_PORTAL.PORTAL_SEARCH_PB.FieldFormula.IScript_SESPortalQry. This enables the system for anticipating the users desired search based on the partial input.
To add the Portal Navigator index to Global Search, use PeopleTools, Security, Permissions & Roles, Permission Lists, Search Groups, and add the search category, PTPORTALREGISTRY, to the Search Groups grid.
To enable the Navigator category to display in the Global Search drop-down list, select PeopleTools, Search Framework, Search Admin Activity Guide, View Search Contexts. Click the Edit Context link and add PTPORTALREGISTRY to the context type Homepage.
To combine separate search definitions into a single search group, you use the PeopleSoft delivered Administer Remote Search Group ACM plug-in. You can combine search definitions from the same content provider or across content providers. For example, you can combine PTPORTALREGISTRY indexes from multiple content providers into a single Navigator global search group.
When you run the Administer Remote Search Groups plug-in, the plug-in:
Imports the search group from the source.
Adds the search group to the search context.
Merges the groups in the Elasticsearch server.
For information on using ACM plug-ins, see Running the PSRUNACM Script.
The facet folder used for CREFs under Fluid Structure and Content, Fluid Pagesis the folder that appears after the Fluid Pages folder. For example, in this folder structure (Fluid Structure and Content, Fluid Pages, FOLDER A, CREF A), the facet folder for CREF A will be FOLDER A.
Every search result displays an icon, which is associated with the CREF. If you want to change the associated icon, consider the following:
PTNAVSRCH_DEF_ICN is the default icon used by the portal registry search (Navigator). If you want to replace this icon, you need to replace PTNAVSRCH_DEF_ICN with your own icon. The icon is uploaded in Application Designer.
If a CREF has a Tile image associated with it, it will use that Tile image, but only if the image is in the SVG format. If a Tile image is not associated with a CREF or if the CREF uses a non- SVG image type, then the system uses the default icon (PTNAVSRCH_DEF_ICN) for the search result.
To exclude a CREF from the Navigator search index, ensure that you select the Hide from portal navigation option on the Content Ref Administration page.
Note: A specific CREF must be marked as hidden from navigation to be excluded from PTPORTALREGISTRY. A CREF that belongs to a portal folder that is marked hidden does not mean that the CREF is hidden.
Maintaining the Portal Registry Search
In order to ensure that the PTPORTALREGISTRY index provides accurate search results of content references registered in the portal menu registry, you must remove deleted content references from the index.
When you build an index for the PTPORTALREGISTRY search definition using the incremental index, the indexing process removes expired content references from the index. Currently, the PeopleSoft system does not track the deleted content references in the portal menu registry that should also be removed from the index. In this scenario, PeopleSoft recommends:
Ensure that content references that you want to delete are expired by setting the “Valid To” date to a past date on the Structure and Content page.
Run the incremental index for the PTPORTALREGISTRY search definition, which will delete the expired content references from the index.
Delete the expired content references from the portal menu registry.
In a fluid user interface, end users submit a Global Search using the Global Search icon, which is available in the header throughout the user's session irrespective of the content the user is accessing in the target frame. A user clicks the Global Search icon to display the Global Search bar, where you select a search category and enter search criteria in the search edit box.
In a fluid user interface, Global Search is enabled by default based on three conditions:
At least one search index must be deployed and crawled on the system.
A user accessing global search must have the required permissions for the deployed search index.
A user accessing global search must have access to the Fluid Global Search component.
Note: From PeopleTools 8.55, the fluid global search page is used irrespective of the default theme and style the application is using. Global search does not support persistent search.
The portal registry search category is named Navigator.