OpenSearch in PeopleSoft: Complete Configuration Guide (2026)

Master OpenSearch configuration in PeopleSoft: understand the Search Framework architecture, set up Search Instances, deploy search definitions, build indexes, configure real-time indexing, and stand up PeopleSoft Insights dashboards. Step-by-step walkthrough with real navigation paths for PeopleSoft administrators and search framework developers.

🎯 Essential PeopleSoft Skill: OpenSearch is now the standard search engine behind PeopleSoft’s Search Framework, Global Search, keyword search, and Insights dashboards. Whether you’re migrating off Elasticsearch or setting up search from scratch, getting the Search Instance, deployment, and indexing configuration right is foundational to a working PeopleSoft system. This guide covers every step with real navigation paths. Beginners to advanced PeopleSoft administrators.

📋 OpenSearch in PeopleSoft Complete Guide

1. OpenSearch & the PeopleSoft Search Framework Overview
2. Why PeopleSoft Moved from Elasticsearch to OpenSearch
3. Prerequisites & Version Requirements
4. Installing OpenSearch with the OSK DPK
5. Configuring the Search Instance in PeopleSoft
6. Search Definitions, Categories & Deployment
7. Building Indexes & Real-Time Indexing (RTI)
8. PeopleSoft Insights: OpenSearch Dashboards Setup
9. Security, Failover & Cluster Configuration
10. Troubleshooting Common OpenSearch Issues
11. Pro Tips & Best Practices

What is OpenSearch? OpenSearch is an open-source search and analytics engine built on Apache Lucene, forked from Elasticsearch 7.10.2 in 2021 and now governed as a separate Apache 2.0 licensed project. In PeopleSoft, it serves as the back-end engine that powers Global Search, keyword search on transaction pages, and PeopleSoft Insights dashboards.

The PeopleSoft Search Framework: A centralized PeopleTools interface used to configure the search engine, create search definitions and search categories, build and maintain search indexes, search content through global search and search pages, and build and maintain Insights dashboards. The framework itself doesn’t change based on which engine sits behind it.

How the Pieces Fit Together: PeopleSoft Query (or Connected Query) defines what data gets extracted. A Search Definition wraps that query with indexing metadata. A Search Category groups related Search Definitions. The Search Instance tells PeopleSoft where the OpenSearch cluster lives and how to authenticate to it. Once deployed and indexed, end users search through Global Search, component keyword search, or custom search pages.

OpenSearch Version Integration: Depending on your PeopleTools release, PeopleSoft integrates with a specific OpenSearch and OpenSearch Dashboards version—starting around OpenSearch 2.3.0 in early 8.59.21 patches, moving to OpenSearch 2.11.0 with Logstash 8.11.3 in later 8.62 releases. Always confirm the exact supported version pairing in My Oracle Support before installing.

Best for Administrators: Whether you’re standing up search for the first time or migrating from Elasticsearch, the same Search Framework pages apply—only the underlying engine and a few engine-specific settings change.

The Licensing Trigger: Due to licensing changes introduced by Elastic, Elasticsearch 7.10.0 and Kibana 7.10.0 were the last versions Oracle delivered with PeopleSoft. Oracle responded by adopting OpenSearch and OpenSearch Dashboards—the Apache 2.0 licensed forks—as the supported go-forward engines.

Timeline: OpenSearch support became available starting with PeopleTools 8.59.21 and 8.60.07. From those releases through PeopleTools 8.60, PeopleSoft supports either Elasticsearch or OpenSearch as the search engine. From PeopleTools 8.61 onward, OpenSearch is the only supported search engine—Elasticsearch is no longer an option.

What Actually Changes for Users: The transition is primarily cosmetic. The same search definitions and categories used in Elasticsearch work in OpenSearch without modification. Creating queries, search definitions, search categories, deployment, and viewing search results all work exactly the same way. The most visible change: Kibana has been renamed “Insights” throughout the PeopleSoft UI and documentation, since PeopleSoft Insights now uses OpenSearch Dashboards instead of Kibana for visualizations.

Migration Path: Customers patching to a supported PeopleTools release can choose to use the OSK (OpenSearch Kit) DPK to switch from Elasticsearch and Kibana to OpenSearch and OpenSearch Dashboards without any reindexing or redeployment of existing search indexes and analytics dashboards.

Minimum PeopleTools Version: PeopleTools 8.59.21 or 8.60.07, depending on which release line you’re on. If you’re already on PeopleTools 8.61 or later, OpenSearch is your only option—plan accordingly if you’re still running Elasticsearch on an older release.

Server and OS Requirements: OpenSearch and OpenSearch Dashboards are supported on both Windows and Linux. Oracle recommends installing OpenSearch Dashboards on one of the existing OpenSearch cluster nodes rather than a separate server, for better connectivity between OpenSearch and OpenSearch Dashboards.

Integration Broker Setup: Before configuring search, confirm Integration Broker and the integration gateway are configured on your PeopleSoft system. The Search Framework communicates with the search engine over REST, and Integration Broker’s Service Configuration (Setup Target Locations) needs the gateway URL and default local node correctly set.

Network/Hostname Resolution: Confirm hostname resolution works in both directions between the PeopleSoft application server and the OpenSearch nodes. A classic deployment failure is a missing hosts file entry—if either system can’t resolve the other’s hostname, search definition deployment and round-trip tests will fail even though the network path itself is fine.

Plan Your Cluster Size Now: Decide on a single-node or multi-node OpenSearch cluster before installation, since cluster topology affects Search Instance configuration later. Oracle recommends a three-node OpenSearch cluster on separate physical servers for production environments.

Why DPK and Not the OpenSearch.org Installer: PeopleSoft requires installation through the delivered OpenSearch Kit (OSK) Deployment Package—not a manual download from opensearch.org. This matters even more for OpenSearch Dashboards, which is delivered as part of the OSK DPK specifically because it includes a security module built in. Installing Dashboards directly from the open-source distribution skips that security layer.

Step 1: Download the OSK DPK. Obtain the OpenSearch Kit Deployment Package matching your PeopleTools release from the PeopleSoft Deployment Packages documentation on My Oracle Support.

Step 2: Run the Installation Script. Run the DPK installer interactively, or in silent mode using a prepared configuration file. You can install OpenSearch and OpenSearch Dashboards together in one pass, or separately if you’re staging the dashboard server independently.

Step 3: Install OpenSearch Dashboards. During the OSK DPK installation, you’ll be prompted to specify which OpenSearch server Dashboards should connect to. Choose the node you’ve designated as primary, especially in a multi-node cluster, since the cluster statistics monitoring job is tied to whichever node is listed first in the Search Instance configuration.

Step 4: Start the Services. On Windows, open a command prompt, change directory to OSD_Home\bin, and start the OpenSearch Dashboards service from there. On Linux, the DPK typically registers OpenSearch and Dashboards as system services you can start with standard service commands.

Verify Before Moving On: Confirm both the OpenSearch cluster and OpenSearch Dashboards are reachable and healthy before touching the PeopleSoft side—troubleshooting connectivity is far easier at the server level than after you’ve started wiring up the Search Instance.

What Is a Search Instance? A Search Instance represents a single instance of the search engine in the PeopleSoft Search Framework. It defines connectivity and administration settings used both for running end-user queries and for administrative tasks like deployment and indexing. You can define more than one Search Instance—useful for running a side-by-side comparison during a migration, or pointing different environments at different clusters.

Navigation: PeopleTools, Search Framework, Search Admin Activity Guide, Configuration, Search Instance. (Some releases also expose this directly under PeopleTools, Search Framework, Administration, Define Search Instances.)

Step 1: Set the Search Provider. On the Search Instance Properties page, choose OpenSearch as the search provider. Enter a descriptive Search Instance name—Oracle’s default instance is typically named PSFT_DEFAULT, but you can create additional named instances.

Step 2: Enter Connectivity Details. Provide the host name and port number for your OpenSearch cluster, along with admin service and query service credentials. These credentials authenticate every request from PeopleSoft to the search engine and must match what’s configured on the OpenSearch side.

Step 3: Add Multiple Nodes for Failover. For a multi-node OpenSearch cluster, use the scroll-bar plus button in the Search Instance Properties section to add each additional node. Configuring multiple nodes enables PeopleSoft’s failover mechanism, so a single node going down doesn’t take search down with it. When using multiple nodes, always ensure the replica setting is at least 1 so data exists on more than one node.

Step 4: Configure Service Target Locations. In the Service Configuration tab, set “Setup Target Locations” before saving. In Web Services Target Locations, confirm the Integration Broker Gateway is listed as the target location, and that the default local node appears at the end of that list.

Step 5: Save and Test. After saving, run a round-trip deployment test. If it fails immediately on connectivity, double-check hostname resolution between the two systems before investigating anything else—it’s the single most common first-time setup failure.

The Query Comes First. Before creating a Search Definition, build the PS Query (or Connected Query) that will supply the data. The query needs the specific fields the Search Framework expects: the list of fields to index from authorized records, a drilling URL back to the source transaction, a prompt against the “Last Updated” field, and selection criteria built around that field for incremental indexing. Navigate to Reporting Tools, Query, Query Manager to build it.

Step 1: Create the Search Definition. Navigate to PeopleTools, Search Framework, Designer, Define Search Definitions. Give it a name—best practice is matching the Search Definition name to the underlying query name to simplify maintenance. Attach the query as the data source, and configure field mappings, source security (by User ID or User Role), and document-level security as needed.

Step 2: Create a Matching Search Category. A one-to-one relationship must exist between a Search Definition and a Search Category of the same name for standalone definitions. Categories let you group related definitions into logical, manageable units that can be deployed and searched together.

Step 3: Deploy the Search Definition. Navigate to PeopleTools, Search Framework, Administration, Deploy/Delete Object. Filter for your Search Definition by name—it should show “Undeployed” status the first time. Select its checkbox and click Deploy. This transfers an empty shell of the definition and category structure to OpenSearch, telling the engine what the data will look like, without yet sending any actual data.

Deploying Composite Categories: When you deploy a Search Definition, its matching one-to-one Search Category deploys automatically. But if a category is a composite of multiple definitions, you must deploy each contained definition first, then deploy the category manually afterward.

Making Changes Later: If you need to modify a deployed Search Definition—adding fields, changing security—you must first Undeploy it on this same page, make your changes, then Deploy it again. You can’t edit a live, deployed definition in place.

Step 1: Run the Initial Full Index. Navigate to PeopleTools, Search Framework, Administration, Schedule Search Index. Select your deployed Search Definition and run with the Full Index option for the first build—this transfers all data currently matching the underlying query into OpenSearch. This kicks off the PTSF_GENFEED Application Engine program, which runs any Pre-Processing AE defined for the definition, then runs the query itself and generates the feed.

Incremental vs Full Indexing: After the first full index, subsequent scheduled runs typically use incremental indexing, which relies on the “Last Updated” criteria built into your query to pick up only changed rows—much faster than reprocessing the entire dataset every time.

Verifying the Index Ran Successfully. Check the message log for confirmation lines like “Successfully generated feed for Search definition” and check the segment count. If the Application Engine appears to hang, check Integration Broker’s Service Operation Monitor (PeopleTools, Integration Broker, Service Operation Monitor, Monitoring, Asynchronous Services) for stuck operation instances or subscription contracts.

Real-Time Indexing (RTI): For transactions that need to be searchable immediately after creation—rather than waiting for the next scheduled batch index—enable RTI so users can find records right after saving them. Configure this through PeopleTools, Search Framework, Administration, Define Search Instances, under the Search Instance Search Options.

Tuning RTI Performance: Two key parameters control RTI behavior: the Heartbeat Interval, which determines how often the RTI process checks the staging table (PS_PTSF_RTISTG) for new rows, and the Real Time Indexing Set Size, which controls how many rows get processed per interval. A shorter heartbeat gets you closer to true real-time search at a higher performance cost; a longer interval reduces load but delays searchability. Tune both together based on your transaction volume.

Build Order Matters. The index build process must be run separately for each Search Definition after it’s deployed—there’s no single “build everything” button, so plan your initial rollout as definition-by-definition deploy-then-index cycles.

What Is PeopleSoft Insights? Insights is PeopleSoft’s branding for visualizations and analytics built on top of the Search Framework, currently powered by OpenSearch Dashboards (the successor to Kibana). Insights dashboards can be embedded directly into PeopleSoft Fluid pages as tiles, giving end users charts and visualizations without leaving the application.

Step 1: Build the Search Definition First. Insights dashboards are powered by the same Search Definitions covered earlier. Navigate to PeopleTools, Search Framework, Designer, Define Search Definitions to set up the dataset the dashboard will visualize, then deploy and run a full index exactly as described above.

Step 2: Build the Dashboard in OpenSearch Dashboards. Open the OpenSearch Dashboards homepage from within PeopleSoft. Navigate to the top-right navigator menu, then Manage, Index Patterns, and click Create Index Pattern. Search for and select your newly indexed pattern. Return to the homepage and use the OpenSearch Dashboards visualization tools to build your charts, tables, or maps against that index pattern.

Step 3: Import the Dashboard into PeopleSoft. Navigate to PeopleTools, Search Framework, Administration, Import Insights Dashboards. Add a new row, select the dashboard by name, and import it so PeopleSoft is aware of it as a manageable object.

Step 4: Deploy the Dashboard. Navigate to PeopleTools, Search Framework, Administration, Deploy Insights Dashboards. Select your imported dashboard and click Deploy—this pushes the associated configuration, including security settings, into the live environment.

Step 5: Configure the Content Reference. Navigate to PeopleTools, Search Framework, Administration, Configure Insights Dashboards. Provide a content reference name and label, select the Full View (Dashboard Name) and Tile View options, set the height and width, and save.

Step 6: Add It to a Fluid Dashboard. Navigate to PeopleTools, Portal, Dashboards, Manage Dashboard Pages. Create a new dashboard page, then use the Tile button to select your Insights tile and place it on the page for end users to see.

Authentication Between PeopleSoft and OpenSearch. The Search Instance Properties page stores the username and password PeopleSoft uses to connect to the search engine. These credentials must match what’s defined in the OpenSearch configuration, since the engine validates every incoming search and administrative request against them.

Document-Level and Source Security. Within a Search Definition, you can restrict who sees which indexed records using Source Security (by User ID or User Role) and Document Level Security. This lets you index sensitive data while still respecting the same row-level access rules users have inside the actual PeopleSoft transactions.

Cluster Failover Behavior. In a multi-node cluster, the system monitoring job that tracks cluster statistics runs against whichever node is listed first in the Search Instance node configuration. If that primary node changes—say, during a failover event or maintenance—you must stop the monitoring job and restart it using the system monitoring flag on the Configure Server page so it correctly targets the new primary.

Replica Configuration. When running a multi-node OpenSearch cluster, set the replica count to at least 1. Without replicas, losing a single node can mean losing indexed data outright rather than just losing capacity.

OpenSearch Dashboards Security Module. Reiterating a point from installation: the security layer bundled into the OSK DPK version of OpenSearch Dashboards is specifically why Oracle requires that installation path rather than a direct download from opensearch.org—skipping it means losing that built-in security integration with PeopleSoft.

Issue 1: Round-Trip Deploy Test Fails Immediately. The most common cause is hostname resolution—if either the PeopleSoft application server or the OpenSearch node can’t resolve the other’s hostname (not just its IP), deployment and round-trip tests fail even with a healthy network path. Add the missing entries to the hosts file on both systems and retest.

Issue 2: Search Definition Stuck “Undeployed” After Clicking Deploy. Confirm the Search Instance credentials are valid and that Integration Broker’s Setup Target Locations correctly list the gateway and default local node. Check the Service Operation Monitor for failed asynchronous service operations tied to the deployment request.

Issue 3: Index Build (PTSF_GENFEED) Runs but Returns No Data. Verify the underlying PS Query actually returns rows when run standalone in Query Manager. Then confirm the Search Definition’s field mappings and “Last Updated” criteria are correctly configured—a misconfigured incremental criteria can silently filter out every row on subsequent runs.

Issue 4: Insights Dashboard Shows “Monitor Console is Disabled” or Won’t Load. Confirm OpenSearch Dashboards was installed via the OSK DPK (not a manual opensearch.org install), and that the Configure Insights Dashboards content reference settings—particularly height, width, and the selected Full View/Tile View names—match what was actually imported and deployed.

Issue 5: Stale Cluster Statistics After a Node Failover. If cluster monitoring data looks frozen after a primary node change, stop and restart the system monitoring job using the monitoring flag on the Configure Server page—the job doesn’t automatically re-target a new primary node on its own.

PeopleSoft Search Framework & OpenSearch Migration Services

PepperTech offers PeopleSoft administration training and consulting covering Search Framework setup, Elasticsearch-to-OpenSearch migration, Insights dashboard development, and production search performance tuning. Expert trainers with 15+ years of PeopleSoft infrastructure experience. Get your team productive with OpenSearch in days, not weeks.