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.

• Adding hyperlinks to Queries and nVision reports (described in this powerpoint).
• Drilling to other Content in nVision blog posting.
• Drilling Deeper into PeopleSoft Pages blog entry.
• Code to drill to any chartfield blog entry.
• Drilling to a performance or development document from a URL blog posting.

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.

http://www.psserver.com/	Server
psp	Portal or Content psp=Show portal frame psc=Show content only
/ps/
EMPLOYEE	Portal Name
/ERP/	Site
c/
PROCESS_JOURNALS	PeopleSoft Menu
.JOURNAL_ENTRY_IE.GBL	Component and Market
?
BUSINESS_UNIT=US005&	Search Parameter
JOURNAL_DATE=2004-03-31&	Search Parameter
JOURNAL_ID=MKMAR5&	Search Parameter
ACTION=U&	Mode A=Add U=Update C=Correction
PAGE=JOURNAL_ENTRY1	Page Name

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.

• Not all primary search fields are passed in the URL
• The component is set to force the search page to display
• The component processor encounters an unexpected condition.

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). Labels: Drilling

 

For those who are familiar with our demo and posting that discusses how to drill from a report into a page (blog posting here), you may or may not notice a limitation in what was presented. The example showed drilling from a financial report to the journal entry where the number came from. Unfortunately, drilling to the journal is just not granular enough to tell you exactly where the number came from (journals can have hundreds of lines, and a number in a financial report is governed by the chartfield values that are used).

This means that what you really want to do is to drill to items that are at scroll level 1 or greater in the page. Because the standard URLs to PeopleSoft pages are driven by the search records for those pages, you need to be able to (1) pass parameters to identify what values you want to navigate to, and (2) write code to do the navigation.

Sounds interesting, so how do you do it?

Well, the first part was answered in this posting on how to add parameters to your PeopleSoft pages.

The second part can be acoomplished in multiple ways (depending on the following):

• Whether the page or scroll items are read only.
• Whether the data to be navigated to is chunked by application code or by PeopleTools.

Using the SetCursorPos PeopleCode Function

The first approach we will discuss is using the SetCursorPos function. This works by iterating through the data in the component buffer until you find the row you want to be on, and setting the focus (or cursor position) to a field on that row. Because you can’t navigate to fields that are grayed out (or are read only), this only works when that occurs. Also, since you are navigating through what’s already in the component buffer, if the only loads a subset of the data at a time into the component buffer, then you may be navigating through a small part of the data you want to search. Navigating to a posted journal entry in PeopleTools is a perfect example of where both of these conditions would prevent this from occurring.

Here is an example of code you would use for a page with updatable data where the component buffer contains the full data set you want to search

Local Rowset &rsJrnlLines = GetLevel0().GetRow(1).GetRowset(Scroll.JRNL_LN);

Local number &j;
For &j = 1 To &rsJrnlLines.ActiveRowCount


• 
  &rowTest.GetRecord(Record.JRNL_LN).GetField(Field.ACCOUNT).SetCursorPos(%Page);
  
  Break;
Local Row &rowTest = &rsJrnlLines.GetRow(&j);

If &rowTest.GetRecord(Record.JRNL_LN).GetField(Field.ACCOUNT).Value = &sAcctNum ThenEnd-If;

End-For;


Adding a navigation element to the grid

If all the items in the scroll are read-only (or grayed out), then another option is to put a push button or other element in the grid that isn’t grayed out to set focus to. It’s actually as simple as that. You add the item, and then set the cursor position to it. Of course, this gets into customizing the page itself, which can be an issue at upgrade time.

Leverage selection code written into the page

This approach can be used very effectively in inquiry pages or even pages where there search logic is used written by application developers to populate the scroll. The journal line page is a great example of this. There’s a link in the Financials 8.9 journal entry page that allows you to enter search criteria for your journal lines. This page actually displays fields in the JRNL_PANELS_WRK record, which is in the componenet buffer for the page. By merrely setting the values of chartifelds in this work record and calling the adjust_line_scroll function, you can use parameters to restrict the set of journal lines displayed in the page (ultimately drilling to those values).

Here is the code to do that.

Declare Function adjust_line_scroll PeopleCode FUNCLIB_GL.JOURNAL_LINE FieldFormula;

/* Code to drill to row with account number passed in as a parameter */

Local string &sAcctNum = %Request.GetParameter("ACCOUNT");
If All(&sAcctNum) Then

• JRNL_HEADER.JRNL_HDR_STATUS = “P”Or
  JRNL_HEADER.JRNL_HDR_STATUS = “U”Then
  
  /* Journal is read only */
  JRNL_PANELS_WRK.ACCOUNT = &sAcctNum;
  adjust_line_scroll();
If JRNL_HEADER.JRNL_HDR_STATUS = "D" Or
End-if;

End-if;

One last item of note: if there is already Page Activate PeopleCode, you will probably want to put yours at the end for the navigation (this ensures that all other logic has already been executed). The JOURNAL_ENTRY2_IE page is an example of this.

Labels: Drilling, nVision, PeopleCode

Although I put together a previous posting on Drilling and nVision, I only included a single nVision drill layout to illustrate this. I already put together comprehensive packages to show:

• Reporting in HCM (Orig Posting, Demo, and Code)
• Reporing in Student Admin (Orig Posting, Demo, and Code)

Code for Financials Drilling to Pages and Queries (among other things).

I decided to put together a package for Reporting in Financials (Orig Posting and Code). As with the other packages, the code includes a working example with our nVision drilling product.

Labels: Drilling, nVision, Query

Over the past 24 hours, I’ve had lots of folks wanting to learn more about the HCM reporting examples in yesterday’s post. I decided to record a flash demo that shows how one would use the queries as well as the nVision reports (and drills).

In order to simplify the navigation in the demo, I did use the nVision Drilling Snap-on (which is separately licensable, but is not required to use the queries and nVision objects in the project). However, it does make it much easier to find and use them together.

Click here to watch the HCM Reporting in action…

Labels: Drilling, HCM, nVision, PeopleSoft, Query, Tree_Manager