Prepare the search definitions

NL Search can only find what PeopleSoft Search indexes, so the first step happens entirely in PeopleSoft: a search definition for vouchers, with the attributes the first intent will filter on, and the security that decides who sees which voucher. PeopleSoft Search and OpenSearch explains the pieces.

Plan it

Decision	For the voucher intent
Data	One row per voucher, with its supplier’s name
Attributes	VENDOR_NAME, GROSS_AMT, ENTERED_DT, and VOUCHER_STATUS, for the intent’s fields
Security	Document-level, on BUSINESS_UNIT, so users see vouchers in the business units they may use
Freshness	Incremental builds every 15 minutes, or real-time indexing
Category	ZZ_VOUCHERS, holding this search definition only

If a delivered search definition already covers the data, with the attributes and security you need, you can use it instead, and go straight to Group it in a category.

Build the query

Build a PS Query, ZZ_VOUCHERS_QRY, that returns one row per voucher. It’s easiest to build it on a view, such as ZZ_VCHR_SRCH_VW, that joins the voucher and supplier tables, and names its columns the way the intents will use them; create any fields the view needs. The query needs:

• The voucher’s keys, BUSINESS_UNIT and VOUCHER_ID, so that each row is one document.
• A column for each field users will filter on.
• The security column, BUSINESS_UNIT, which users rarely search on, but which decides who sees each voucher.
• The last update date and time, such as LASTUPDDTTM, which incremental builds use to find what changed.

Create the search definition

1. Create it. At PeopleTools > Search Framework > Search Designer > Search Definition, add ZZ_VOUCHERS, with Query as the source type, and ZZ_VOUCHERS_QRY as the query.

2. Map the attributes. Make each column that the intent filters on an attribute, with the name the Intent Store uses, such as VENDOR_NAME and GROSS_AMT.

3. Set how results look. Choose each result’s title and summary, such as the voucher ID and supplier as the title, and the amount and status as the summary, so users can tell results apart.

4. Set the security. On the Security page, choose document-level security, with BUSINESS_UNIT as the security attribute, and name your document filter application class, which returns the business units the user may see. Build the class on the same security views that PeopleSoft’s own voucher pages use, so that search and pages agree. Oracle’s documentation for your release shows the methods the class must implement.

A user for whom the class returns no business units finds no vouchers at all, whatever they ask.

Group it in a category

At PeopleTools > Search Framework > Search Designer > Search Category, create the category ZZ_VOUCHERS, with the ZZ_VOUCHERS search definition as its only member. Keep each NL Search category to one search definition, so that every filter applies to every document in it.

If users will also search vouchers with Global Search, add facets, such as status, on the category’s Facets page, and select the category’s Search Group box.

Deploy and build the index

1. Deploy the search definition and the category at PeopleTools > Search Framework > Administration > Deploy/Delete Object. The definition’s index now exists in OpenSearch, empty.

2. Build the index. At PeopleTools > Search Framework > Administration > Schedule Search Index, create a run control for a full build of ZZ_VOUCHERS, and run it. PTSF_GENFEED runs the query and sends the documents to OpenSearch.

3. Keep it current. Create a second run control, for incremental builds, and give it a recurrence, such as every 15 minutes during the working day. If users expect a voucher to be searchable as soon as it’s saved, turn on real-time indexing for the definition instead, at PeopleTools > Search Framework > Real Time Indexing > Configure Real Time Indexing.

Test it as your users

Before NL Search is involved, check the index the way users will meet it. Sign in as test users who can see different business units, and search the ZZ_VOUCHERS category for a supplier’s name, on the Search Test Page at PeopleTools > Search Framework > Utilities > Search Test Page, or with Global Search:

• Each user finds vouchers from their own business units, and none from anyone else’s.
• A user with no voucher access finds nothing.
• A voucher changed a moment ago appears after the next incremental build, or straight away with real-time indexing.

Fix it here first

NL Search shows exactly what this search shows. If a user finds a voucher they shouldn’t here, they’ll find it with NL Search too, so fix the search definition’s security before you go on.