Skip to content

PeopleSoft Search and OpenSearch

NL Search doesn’t search PeopleSoft by itself. It hands each plan to PeopleSoft Search, the Search Framework that PeopleSoft runs on top of OpenSearch. PeopleSoft decides which data is indexed, which fields users can search and filter on, and who can see each document. OpenSearch stores the indexes and runs the searches. Knowing how the two fit together makes it much easier to design intents that work.

When someone searches, PeopleSoft doesn’t look for matches in the application’s tables. It searches indexes that it built earlier from the data you chose to make searchable, which OpenSearch stores in a form designed for fast searching. The database stays the system of record, and the index is a read-optimized copy.

Building and searching PeopleSoft's search indexesBuilding the index: the PTSF_GENFEED Application Engine program runs each search definition's query against the PeopleSoft database, turns the results into JSON documents, and sends them through Integration Broker to OpenSearch. Searching: the user searches from the browser, with Global Search, Keyword Search, or NL Search. PeopleSoft's Search Framework builds the query, and the search definition's security application class returns the values the user may see. OpenSearch returns the matching documents, and the browser shows the results. The search runs on the index, not the application's tables.Building the indexSearchingPeopleSoft databaseThe system of recordQuery resultsPTSF_GENFEEDBuilds a document per rowJSON documentsIntegration BrokerDelivers them for indexingThe user's browserGlobal, Keyword, or NL SearchSearchResultsPeopleSoftSearch FrameworkBuilds the querySecurity application classReturns the user's allowed valuesQueryDocumentsOpenSearchThe search indexes, on servers of their own
PeopleSoft builds each index ahead of time, then searches it as the user. The search runs on the index, not the application's tables, so results are as current as the last index update.

For NL Search, that has two consequences:

  • A search can only use what’s indexed. If a field isn’t part of the search definition, no question can filter on it.
  • Results are as current as the index. A voucher entered a minute ago appears once the index is updated, as described in Keeping the index current.
  1. A query selects the data. Most search definitions are built on a PS Query or Connected Query, which returns one row for each thing users can find, such as a voucher. Search definitions can also index files and websites, but NL Search works with query-based ones, whose columns become attributes.

  2. A search definition maps the query’s columns to attributes, and sets how each result is displayed, such as its title and summary. Attributes are what searches, and NL Search plans, filter on.

  3. Deploying the search definition creates its index in OpenSearch. The index stays empty until it’s built.

  4. The PTSF_GENFEED Application Engine program builds the index. It runs the definition’s query, turns each row into a JSON document, and sends the documents through Integration Broker to OpenSearch. You schedule it on the Schedule Search Index page, under PeopleTools > Search Framework > Administration.

  5. A search category groups one or more search definitions, and it’s what users choose when they search. Each category also sets its facets and its advanced search fields. An NL Search intent runs against one category.

Oracle suggests separate run controls for full builds, which create or recreate an index, and incremental builds, which add what changed since the last build. Between builds, new and changed data isn’t searchable.

Where that gap matters, use real-time indexing, available from PeopleTools 8.59. It updates the index as the data changes, instead of waiting for the next build. It’s off by default: turn it on for each query-based search definition on the Configure Real Time Indexing page, under PeopleTools > Search Framework > Real Time Indexing, with the Process Scheduler set up to run it.

OpenSearch doesn’t know about tables such as PS_VOUCHER. It stores documents, each a set of fields, and each row that a definition’s query returns becomes one document. Simplified, one document in the voucher index used on these pages might look like this:

One voucher document (simplified)
{
"VOUCHER_ID": "00012345",
"BUSINESS_UNIT": "US001",
"VENDOR_NAME": "Acme Corporation",
"GROSS_AMT": 12500,
"ENTERED_DT": "2026-08-14",
"VOUCHER_STATUS": "O"
}

A document is flat and read-optimized, so OpenSearch can search millions of them quickly without running the original SQL. Some attributes are there for security rather than searching: here, BUSINESS_UNIT could decide who may see the voucher.

  • Global Search, in the PeopleSoft banner, searches across categories, so users can find data without knowing its navigation path.
  • Keyword Search is a tab on a component’s search page, next to Find an Existing Value. Find an Existing Value queries the database by the component’s level 0 search keys, while Keyword Search searches the index, which can hold data from levels 0 through 3. A component gets Keyword Search when it’s mapped to a search definition.
  • NL Search adds another way in, through the same categories, attributes, and security.
  • Relevance ranking, so the best matches come first.
  • Facets: counts of results by an attribute’s values, such as status or business unit, which users select to narrow the results. Each category’s facets are set on its Facets page.
  • Stemming, where it’s turned on, matches other forms of a word. The engine indexes each word’s root form, so manage can match managing and management.
  • Typo tolerance in suggestion search: when a search finds nothing, PeopleSoft can use OpenSearch’s phrase suggester to correct the word and search again. It’s set with the Enable Typo Tolerance field on the Search Options page.
  • Semantic search, from PeopleTools 8.63, matches meaning as well as words. See Semantic search.

These features apply to the words being searched for. In NL Search, those are the plan’s text; the plan’s filters match attribute values directly.

Each search definition has one of three security settings: no security, which lets anyone who can use PeopleSoft search it; source-level security, for chosen users and roles; or document-level security, which filters documents by each user’s allowed values. PeopleSoft applies them to every search, including NL Search’s. See Search security.

  • OpenSearch comes in Oracle’s OSK DPK, with OpenSearch Dashboards and Logstash. PeopleTools 8.63 uses OpenSearch 3.2.0, OpenSearch Dashboards 3.2.0, and Logstash 9.1.3.
  • Oracle recommends separate servers. Install the DPK on servers other than your PeopleSoft ones.
  • Indexes are split into shards across the nodes of the OpenSearch cluster. The Number of Shards setting on the Search Options page applies to every definition you deploy, unless overridden, and defaults to 5.
  • Users search through PeopleSoft, never OpenSearch directly, and the NL Search Service doesn’t connect to OpenSearch at all.

PeopleSoft Insights charts the same indexes with OpenSearch Dashboards, such as vouchers by status or by month, without adding load to the transactional database. The two answer different questions: NL Search finds documents, while Insights counts and charts them. A question such as “voucher totals by supplier this quarter” belongs in an Insights dashboard.

  • An intent’s category is a search category, and its fields must be attributes of the category’s search definitions.
  • Adding a field means changing the index. Add the column to the query, map it as an attribute, redeploy the search definition, and run a full build.
  • Freshness comes from the index, so plan incremental builds, or real-time indexing, around how current users expect results to be.
  • Security comes from the search definitions, so check each one before you build an intent on it.