A search record is a very import part of the component processing. In this post, I will tell you what its relevance is and how making changes to a search record can affect the search page.
Every Component in PeopleSoft should have a search record associated with it. Without specifying one, App Designer wouldn’t let you save the Component definition. We specify the search record in the properties of a Component as shown below.
On the search page for the component, a user may enter values against one or more or even none (leave all fields blank) of search key to retrieve the data. The Component Processor then performs a search against the search record to retrieve data from the database that matches the user’s input and populates the Component buffer during the Component build.
In short, this record provides the only values the user may choose to see. As such, it’s very much used in row level security as well.
Search Page
You can use the search keys and alternate search keys to retrieve values on the advanced search page. The basic search page allows you to use only one search criteria at a time – this can either be a search key or an alternate search key. On the Component Properties, you can specify what search page – basic or advanced – that a user would see by default.
If the list box item check box for a filed is selected, the values of that field are listed in the list box as shown below.
Bypass the Search Page
Sometimes it may be necessary to bypass the Search page. To do this, you can use a search record that doesn’t have any search keys. On finding that that there are no search keys selected, PeopleSoft will not show you the search page while accessing the component.
Since the delivered INSTALLATION record doesn’t have a search key, it’s common to see it being used in cases where the search page is not required.
Overriding a search record
You may have a case in which the same Component should have one search Record when accessed through a navigation and a different search record at another navigation. For this, PeopleSoft allows you to override the search record at Menu Item level by accessing the Menu Item Properties as shown below.
Row Level Security
By adding fields like OPRID, OPRCLASS or ROWSECCLASS as a key to a search record, you can implemented row level security. When the Component Processor finds such a key in a search record, it would include a condition (over and above the user’s search criteria) which equates it to the user’s value (see below) there by limiting what data the user is able to see.
OPRID is equated to the user’s Operator ID.
OPRCLASS is equated to the Primary Permission List.
ROWSECCLASS is equated to the users Row Security Permission List.
Conclusion
A search record plays an important role in how users access a component. It specifies what fields a user can search against through search keys and alternate search keys. Row level security can also play a role in what rows are returned when the user searches.
Can you tell what is the purpose of Phone Preferred – i don’t remember seeing that option.
Is there something else that needs to be done when adding a data item with history to the search page so only the max row is evaluated in the results?
Hi Mike,
Search records would usually have a key structure similar to level 0.
History (EFFDT) is not part of this level.
So you will need to write a view that returns the latest row for the purpose.
Is it possible to have work record as search record ?
As in my requirement we have the search values provided by third party which will change dynamically.
Please elaborate on how we could do this.
Hi Amy,
A Derived/Work Record can’t be used as a Search Record.
You can, however, skip the Search page by using a search record with no search keys and take users to a regular page.
On that page, you can have your logic to let them search and display results in a grid and link the results up to the desired pages.
This would let you have full control on how the search is performed.
Hope that helps.
Many thanks for your response.We are developing CI based web service, get operation for integrating with third party.
We need to get the search keys in get keys of the component interface which will not happen if we create a custom search page.
The search keys should be ID and the pagenumber (which particular rows in sequence of 100 e.g. 101 to 200)they need.
The search keys input will be given by third party.
Please shed some light on this.
Hello,
Just one question about search results. I need to discard data in search results,
It’s possible to discard one line after save and before results will be show.
Thanks
Hi!
Explore DiscardRow() and StopFetching() – these are written in RowSelect event.
It’s best to filter out rows of data using a search view rather than using these functions.
Hello,
thank you I’ll try this.
Can you change the default search field using event mapper?