Search Framework

• 1: Real-Time Indexing Backlog
• 2: Real-Time Indexing Stuck Off
• 3: Search Indexing Errors

1 - Real-Time Indexing Backlog

Real-Time Indexing Backlog Alert

Alert ID: rti_staging_backlog Category: Search Framework Default thresholds: 1,000 queued updates, or 30 minutes Runs: every 15 minutes

What This Alert Detects

With Real-Time Indexing on, a database trigger on each indexed record writes a row to the queue table PTSF_RTISTG for every insert, update, and delete. PeopleSoft then sends those rows to the search engine and removes them. This alert triggers when the queue for a record is not draining.

Two situations cause it:

• The process that drains the queue has stopped. Rows keep arriving and none leave, so the oldest row gets older.
• A bulk update or batch load changed thousands of rows on a record that carries a Real-Time Indexing trigger. The queue fills faster than it drains.

Severity Logic

Either condition triggers the alert. There is one alert item per record.

What Gets Checked

The alert runs one aggregate query on PTSF_RTISTG, grouped by RECNAME, returning the row count and the oldest PTRTIINSERTDTTM per record. The age is measured against the database server’s clock.

Alert Details

Each alert item includes:

• The record whose trigger queued the updates (RECNAME)
• The number of queued updates
• When the oldest update was queued, and how many minutes ago
• A link to the Search Framework Monitor

Configuration

alerts:
  checks:
    rti_staging_backlog:
      enabled: true
      thresholdCount: 1000    # Queued updates per record before alerting
      thresholdMinutes: 30    # Age of the oldest queued update before alerting

How to Respond

1. Open the Search Framework Monitor and switch on the Real-Time Indexing Queue panel to see the oldest queued rows and their keys.
2. If the count is high and the oldest row is recent, a bulk change is in progress. Check Process Monitor for the batch job, and confirm the queue shrinks once it finishes.
3. If the oldest row keeps getting older, the queue is not draining. Check that the Real-Time Indexing server process is running in the application server domain and that the search engine is reachable.
4. Open the record’s detail page and switch on Search Framework Usage to see which search definitions index it.

Required Table

PTSF_RTISTG. Without it the alert is inactive.

2 - Real-Time Indexing Stuck Off

Real-Time Indexing Stuck Off Alert

Alert ID: rti_stuck_disabled Category: Search Framework Default threshold: 60 minutes Runs: every 15 minutes

What This Alert Detects

A search definition with Real-Time Indexing configured has a switch in PTSF_RTI_STATUS that turns it off temporarily. An index build turns the switch off while it runs and back on when it finishes. A batch job can do the same around a bulk change.

This alert triggers when the switch has been off for longer than the threshold and no index build is queued or running. That usually means a job turned Real-Time Indexing off and ended before turning it back on. Until someone turns it on again, changes to the indexed records do not reach the search engine.

Severity Logic

There is one alert item per search definition.

What Gets Checked

1. PTSF_RTI_STATUS rows with PTRTISTATUS = 0.
2. Of those, the definitions that have Real-Time Indexing configured on (PTSF_INDEX.PTSF_RTI = 'Y'). A definition that does not use Real-Time Indexing is ignored.
3. The time since PTRTISWDTTM, measured against the database server’s clock.
4. Whether a PTSF_GENFEED process request is queued, running, or pending in PSPRCSRQST. If one is, the alert stays quiet.

Alert Details

Each alert item includes:

• The search definition
• When Real-Time Indexing was switched off, and how many minutes ago
• A link to the search definition’s detail page

Configuration

alerts:
  checks:
    rti_stuck_disabled:
      enabled: true
      thresholdMinutes: 60    # Minutes switched off before alerting

Raise the threshold if your batch window turns Real-Time Indexing off for longer than an hour without running an index build.

How to Respond

1. Open the search definition and switch on Real-Time & Incremental Indexing to confirm the status.
2. Check Process Monitor for an index build or batch job that failed around the time shown in the alert.
3. Turn Real-Time Indexing back on for the definition in PeopleSoft.
4. Run an incremental index build for the definition. Changes made while Real-Time Indexing was off were not queued.

Required Tables

PTSF_RTI_STATUS and PTSF_INDEX. Without either the alert is inactive.

3 - Search Indexing Errors

Search Indexing Errors Alert

Alert ID: ptsf_indexing_errors Category: Search Framework Default lookback: 24 hours Runs: every 15 minutes

What This Alert Detects

This alert triggers when PeopleSoft has recorded indexing errors for a search definition. It reads three sources:

“Latest build” is the build recorded for the definition in PTSF_SCHED_STAT. A clean rebuild clears the first two sources, so the alert resolves on its own.

Severity Logic

There is one alert item per search definition, listing each source that has errors.

Alert Details

Each alert item includes:

• The search definition
• The error count the latest build reported
• The number of requests the search engine rejected
• The number of rows that failed Real-Time Indexing in the lookback window
• A link to the Search Framework Monitor

Configuration

alerts:
  checks:
    ptsf_indexing_errors:
      enabled: true
      lookbackHours: 24    # Window for failed Real-Time Indexing rows

How to Respond

1. Open the Search Framework Monitor and switch on the Indexing Errors panel. It shows the first part of the search engine’s response for each rejected request, and the record and keys of each failed row.
2. Follow the process instance link to Process Monitor for the build’s message log.
3. Fix the cause the search engine reports, then rebuild the index for the definition.

What This Alert Cannot See

A build that ends in Success with no recorded errors is not flagged, even if it indexed nothing. PeopleSoft can leave its document counts at zero after a successful build, so a zero count is not treated as an error. Check the document count in the search engine.

Required Tables

Each source is read only when its table is whitelisted. PTSF_INDEX_STAT and PTSF_ES_DT_ERR also need PTSF_SCHED_STAT. With no source available the alert is inactive.