This is another blog posting that Chris and I had discussed putting out there (but got distracted doing other things, one of which is keeping up with the PeopleSoft community… Chris calls this Yak Shaving.)
So I finally found this posting on ITTOOLBOX, and realized that it was time to discuss some of the intricacies of bypassing the search page here.
For those who have been following the blog, you may be familiar with some of the posts we’ve done on drilling and PeopleSoft.
So, as you can see, drilling is a recurring theme here in the blog. Let’s look at what the component processor does, and how this affects drilling.
How the component processor handles drilling
Let’s start by revisiting the how you can create a URL that opens up a specific page with a specific item. The first thing is to look at the structure of the PeopleSoft URL to do this.
|psp||Portal or Content |
psp=Show portal frame
psc=Show content only
|.JOURNAL_ENTRY_IE.GBL||Component and Market|
So, from the above table, you can see that many of the PeopleSoft artifacts have a place in the URL. The menu and component tell you what component to invoke (and notice that the page within the component is a parameter just as is the mode in which the component is brought up). Any field on the search record of the component can be passed as a parameter, but you need to have all of the (primary) Search Keys passed if you want to bypass the search page.
Okay, I think I get it, but what can cause it to trip up?
Well, there are 3 major things that will bring you back to the search page versus getting directly into the component.
Let’s go through each of these one at a time
Not all primary search fields are Passed
This was actually the problem with opening up the Job page. You see, the EMPL_RCD field is a primary search field for the Job component. This is because employees could potentially be in more than one job (although in my experience it doesn’t happen that often). In this example, just adding &EMPL_RCD=0 to the URL will do the trick if your employees only have 1 job. Although you could create a new menu item that overrides the search record for certain situations, it wouldn’t work here because the key structure of the level 0 record of the component expects EMPL_RCD key to be passed in.
One other thing to note, is that quite often it is desirable to invoke the search page with a subset of parameters populated (to target the search results). One example that we show is drilling into tree manager, populating the fieldname, so that you can see all trees built against that field. We use this to facilitate the configuration of our report explorer product, where we know what field the user is interested in, but not which tree they would want to use.
The Component is set to force the search page to display
So, you may ask yourself why anybody would design a page so that you have to display the search page. The answer is that you can use PeopleCode to implement row level security in the SearchInit and SearchSave events (which has been done by PeopleSoft developers in spite of the fact that it isn’t recommended). The only time SearchInit or SearchSave events fire is when the search page is displayed, which means that for those components our little trick of passing in values would actually bypass the security implemented for that page. This is discussed in quite a bit more detail here.
The component processor encounters an unexpected condition
So, let’s say that you have a URL that opens up a component in add mode, and there is already a row in the search table that contains all of the keys passed in. Or, let’s say that you pass in a set of search keys to open the page in update mode, but there isn’t any data in the search record table. In both of these circumstances, the component processor will determine that it can’t meet the request and will display the search page to allow the user to correct the problem (i.e. change the values passed in or change the mode in which the page will be invoked).