Offer NL Search to the Assistant

The PeopleSoft Assistant answers questions with tools, and NL Search finds documents. With NL Search as one of its tools, the Assistant can answer “Do we still owe Globex anything?” by searching vouchers, then summarizing what it found, while PeopleSoft still runs every search as the user.

You’ll build: the application service ZZ_ASSISTANT_SEARCH, with the GET /search operation, and the Assistant’s search_peoplesoft tool.

Plan it

Decision	For this tool
Input	`q`: a question, in the user’s words
Output	How the question was understood, how many documents matched, and the first ten
Each hit	Its title, summary, and link, and nothing else
Security	`ZZ_NLS_USER`, so only NL Search users can search through the Assistant

Build the application service

Create the service ZZ_ASSISTANT_SEARCH, with the root resource search and a GET method that takes the query parameter q, as in Build the first application service.
Call the search class from the handler. The method’s application class creates a ZZ_NLSEARCH:Search object, calls Plan with q, and then Run with the plan, no removed filters, and a size of 10. It logs the request ID with the user, as the search page does.
Return a small result: the summary, joined with ·; the total, from GetEstimatedHitCount(); and each result’s GetTitle(), GetSummary(), and GetUrlLink().
Secure it. Give the permission list ZZ_NLS_USER access to the service, require OAuth 2.0 on the method, and activate the service. Then download its OpenAPI description.

Add the tool

The description tells the Assistant’s LLM when to search, and what to pass:

Search PeopleSoft documents, such as vouchers and requisitions,
with a question in plain language, as the signed-in user. Pass
the user's question in their own words. Returns how the question
was understood, the number of matches, and the first ten, with
links.

Save the OpenAPI description as specs/zz_assistant_search.json, add it and the tool to the catalog, and restart the Assistant service:

services:
  - openapi: specs/zz_assistant_search.json

tools:
  search_peoplesoft:
    operation: GET /search
    progress: Searching PeopleSoft

What happens

A manager asks the Assistant “Do we still owe Globex anything?”:

The Assistant’s LLM calls search_peoplesoft with {"q": "Unpaid vouchers for Globex"}.

PeopleSoft runs the operation as the manager. The search class asks the NL Search Service for a plan, runs it with the Search Framework under the manager’s security, and returns:

{
  "summary": "Vouchers · Supplier: Globex · Status: not paid",
  "total": 2,
  "results": [
    {
      "title": "Voucher 00012388, Global Export Industries",
      "summary": "8,200.00 USD, Approved",
      "url": "https://fin.example.com/psc/ps/EMPLOYEE/ERP/..."
    },
    {
      "title": "Voucher 00012391, Global Export Industries",
      "summary": "1,950.00 USD, Open",
      "url": "https://fin.example.com/psc/ps/EMPLOYEE/ERP/..."
    }
  ]
}

The Assistant answers:

Yes. Two vouchers for Globex aren’t paid yet: 00012388, for 8,200.00 USD, which is approved, and 00012391, for 1,950.00 USD, which is still open.

In the chat, each voucher number links to its page.

What each part sees

The Assistant’s LLM sees the question it passed, and the results’ titles and summaries, as it does any tool result.
NL Search’s LLM sees only the question, as it always does.
PeopleSoft runs the search as the manager, so the Assistant can only ever find what the manager could find on the search page.

Check it

A user with ZZ_NLS_USER gets results, and a user without it is refused, and the Assistant says it can’t search for them.
Each log has its part. The Assistant’s audit log shows the search_peoplesoft call and its question, the NL Search Service’s log shows the same question with a request ID, and PeopleSoft’s log joins that request ID to the user.
The answer’s links open the vouchers’ pages, which check the user’s access again.