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