With the move from Client/Server to web, the drilling functionality in nVision has suffered. There are two main issues that were introduced:

1. the fact that when invoking a drill, the user had to navigate himself to determine when the processing has completed, and then navigate to open the report.


2. the fact that there was no way of organizing the drilldown layouts to make them easier to find.

The first item was addressed in PeopleTools 8.42. However, the second one still remains.

Improving the drilling usability

I'm going to start this part of the posting by providing some information that will cause me to lose all credibility to the loyal readers of this blog: I'm the person who developed that god-awful drilldown page (and I'm very embarrased that it hasn't been replaced). As product manager at the time, I had a minimal development staff that I could dedicate to the development. Thus, I had two difficult choices available to me:

1. Not move nVision drilling to the web.


2. Move it to the web with limited functionality, pitching in wherever I could.

Therefore, in addition to managing the development of tree manager, query, cube manager, and supporting infrastructure to EPM, I jhad to develop the nVision report request page, the Scope page, and the Drilldown page.

So, you got me into this mess, tell me how to improve it

Well, I didn't quite get you into that mess completely. Those familiar with how drilldown navigation works in the client/server environment, you'll know that the navigation was an issue there, but that there were some options to give users control over the sequence of the layouts in the drilldown menu in excel.

Quick and dirty solution...

We'll start with the quick and dirty solution (i.e. no changes to the god-awful pages I created).

When looking at this problem, the best way to improve the drilldown navigation is to minimize the number of items displayed in the drilldown list page. Unfortunately, the financials application ships with lots and lots of drills. This is because they deliver drilldown layouts that nPlode two differen axes and hard-code the metrics that they display in the drilldown layout. This causes layout explosion.

One technique I demonstrated to the PeopleSoft salespeople was to throw away those layouts and develop layouts that did two major things:

1. nPloded on only one axis. Because nVision allows drilling from drilldown results, instead of nPloding on two axes, you can drill into one field, and the drill into the other. This reduces the permutations of layouts, because you're not creating a layout for every combination of fields, you're only doing 2 for each (one for going to details, and one for drilling down 1 level using the tree nPlosion nPlode to immediate children).


2. Maximize the inheritance of those layouts. Most people create drilldown layouts that have the amount field hard coded in it. This is because in order for nVision to know where to put numbers, there has to be an intersection between row specifications and column specifications. Instead of picking a field, like posted total amount for a column, my recommendation is to add business unit criteria, but to pick "selected field all values" for the criteria. Just about every data source for nVision has business unit in it, and by saying all values, all you're doing is identifying where to put the numbers.

In the end, my recommended methodology is as follows:

1. Create 1 layout per chartfield that nPlodes the rows for that field at the detail level. Here is an example of one.


2. Create 1 layout per chartfield that nPlodes the rows to the next level of your primary tree for that chartfield. Here's an example of one.


3. Create 1 layout per tabular listing you want to drill to (such as journal lines, employees, voucher lines). This will allow you to drill to the lowest level of detail for them. Here's an example of one.

More involved solutions

Another set of solutions is to modify the drilldown pages delivered by PeopleSoft. One solution could be as simple as giving users the opportunity to personalize the order of the layouts. Others could be more involved (such as adding functionality to identify whether a drill makes sense with a report and prune the list, and using metadata about the drill layout to categorize them).

We believe that this is the right solution in the end. This is why we have defined a set of nVision drill enhancements like that above. Our methodology is to capture the information that's in the excel nVision layout and store it in tables in the PeopleSoft system. We can then use that information to prune the drill list and organize the drill layouts. As part of this we also add the ability to personalize the set of drills. From the feedback we've received so far, this seems to be a very valuable thing for most PeopleSoft customers.
    

Labels: Drilling, nVision

Going to Oracle Open World? So are we!

Grey Sparling Solutions will continue the tradition the PeopleSoft "Meet the experts" forum. If you've been reading this blog, you've seen our knowledge in action. If you are coming to Open World and want to meet with us get the same quality expert product advice or troubleshooting techniques, you can schedule a meeting with us (free of charge) emailing mailto:Info@GreySparling.com or calling us at 925-217-1298.

Warning: more shameless marketing follows.

The experts at Grey Sparling Solutions represents the most knowledgeable individuals at the company formerly known as PeopleSoft. Most PeopleSoft customers will recognize us from the combined 24 years of manning the "Meet the Experts" booth at Peoplesoft conferences and over 200 sessions presented at Connect Americas, Connect EMEA, HEUG, and DMUG. Most recently, we facilitated the technical roundtable at the Northern California PeopleSoft Regional User Group (NORCALPRUG)

End: shameless marketing.

If you cannot make it to Oracle Open world, we will continue to offer expert ongoing online open communication in the form of the Grey Sparling blogs and webcasts.

Labels: Events

One of my good friends, Tom Pitra, of Pitra Consulting came up with a very ingenious technique for working around limitations in report manager in PeopleTools 8.1x which doesn't require modification of the application. Although he presented the solution it at Connect in 2002, I feel that it deserves being reposted in this forum (mainly because there are probably a lot of PeopleSoft customers on that tools release who aren't going to get the money to do an application upgrade to a version that has folders in report manager)

Folders? What are folders and what do they do?
Well, folders is a way of organizing all the reports that are generated. If you think of a report as being analogous to a file on your computer, imagine what it would be like if you didn't have folders to organize these files. It would very hard for you to wade through the long lists of files to find one you wanted to run or edit. Therefore, one can think of folders as something similar to directories.

The ironic thing is that the reports in report managers actually ARE files in a file system (which is the report repository).

Prior to PeopleSoft 8 and the internet, customers would run nVision reports to the file system with directories to organize the reports, using a feature called the directory template. This allowed a company to organize all reports for period 3, 2002, department 1001 into a folder structure like Financial reports --> 2002 --> Period 3 --> Department 1001, where all financial reports for that combination of year, period, and department would be placed.

Prior to PeopleTools 8.4, report manager was merely a means of listing out the reports one had, and although one could search on the limited attributes of the process running the report, there was really no way of organizing this output (which is a challenge for people who have lots of reports over time to wade through). Even in PeopleTools 8.4, the features for organizing reports are rudimentary (which is why we've identified some additional features that we are selling as a packaged service)

What attributes are available to me in PeopleTools 8.1x?
Good question, because this is what explains both the limitation as well as provides the foundation for understanding the solution. Here's the list:

1. User ID or Role


2. Process Type


3. Process Name


4. When it was generated (search on the last X days)


5. Process Status


6. Process Instance

As you can see, these attributes aren’t that useful for finding reports.

So, how did Tom do it?
Tom utilized an interesting set of features in PeopleSoft's security infrastructure to make it happen (which still impresses me to this day).

Security in PeopleTools is organized by Users, Roles, and Permission Lists. Permission lists represent a set of privileges that are assigned as a grouping. These permission lists can either be directly assigned to users, or can be assigned as roles (to simplify the aministration of security). Users can then get a set of privileges through the roles he or she are assigned to.

For example, there could be a role called "FS Call Center Analysts". Anybody who is a financials call center analyst could be assigned that role (and others if they play other roles in the system, such as "Manager"). The permission list for that role would provide the appropriate rights for reporting, pages access, etc. All security in PeopleSoft is the union of all privileges across all roles and permission lists. Of course the key thing is that users can be members of any number of different roles.

One other thing is that roles do not have to be used in permission lists. A good example is a super user role (such as RPT_Super_User), which by getting that role, the user has access to all the reporting features in report manager, regardless of other settings.

The solution was to use the fact that you could filter on roles in report manager, that you could distribute reports to roles when scheduling them, and that you could assign people roles with no permission lists. This provided a very concise solution that made distribution simple (to distribute to a user, you merely added him to that role), and searching simple (to find a set of common reports, you filtered on a role in report manager).

More on the steps involved...
The first step was to pick a set of categories to use for the reports. I forget the exact categories Tom used, but they could be anything from a cost center ID to a type of report. These categories would then be created as roles in the security infrastructure.

The second step was to determine whether the roles would be used for securing the reports or merely for navigation. If it is used for security, then users would be assigned the appropriate roles for accessing the reports. If the role is merely for navigation, then users would not be assigned (the users would be manually distributed to in the next step).

The third step is to run the reports and set the distribution settings from the process request page (which is the icon that looks like people). When scheduling the report, you would pick the role to distribute to, so that you can filter on that role in report manager. If the role is also used for security, then you don't have to manually add users to distribute to. However, if you aren't using the role for granting security to report instances, then you need to add the list of users who have access to the results of that report run.

When using report manager with reports that have been run, the user can then search for the list of reports distributed to that role. Bada Boom!

Labels: Report_Manager