This came as a comment from the following posting, and I felt that it deserved its own blog entry.

The exact question is as follows:

What would be the best approach to share reports between two PeopleSoft environments, considering we use drill down extensively?

Background

This is an extremely good question, and it brings back memories of some of the discussions we had when updating the report repository in PeopleTools 8.40. Therefore, it makes sense to talk a bit about the history of the report repository as a starting point.

Prior to PeopleTools 8.0

Prior to PeopleTools 8.0, the report repository did not exist. Customers would run reports either locally using the client/server tools (PSQED.EXE, PSNVS.EXE, PSSQR.EXE, CRW32.EXE), or on the process scheduler server. The reports would either be viewed with online viewers (when using the client/server tools), or saved in the file system accessible to the process scheduler server. Users would then access the files using network shares (and secured using network security).

PeopleTools 8.13

PeopleTools 8.13 represents the first release where we had a report repository and report manager. At the time, it was architected to work with only one system, and would not actually authenticate the user accessing a report (it would create an RBAN that was impossible to guess as the identifier of the report --- for those geeks out there, RBAN stands for Really Big Alpha-Numeric). Other limitations include a lack of using folders to categorize reports in the user interface.

PeopleTools 8.40

One of the main projects in PeopleTools 8.40 was to extend report manager to address some of its limitations. One of the primary use cases was to make it easier for users of nVision to utilize it. Here is a snopsis of some of the features that went into that release

• Folders, so that reports could have some level of categorization.
• Support for cross-system report lists
• Improved security over accessing reports (thus eliminating the imfamous RBAN).

The designs for this release pulled together all the requirements into one solution. Because foldering and cross-system access required additional data and infrastructure, it was decided to leverage integration broker for both (and the PSRF application messages were born). The report manager pages were reorganized, including two additional pages added to report manager that utilize the information published and subscribed by these new messages.

• The List tab is a standard search page against cross-system data and the first level of foldering.
• The Explorer tab is a tree view over the foldering metadata attached to the reports.
• Finally, the old report manager page was renamed to "Administration", so that you could access reports on the local system, even if integration broker wasn't working in your environment.

About Deployment Strategies

Okay, now that we have some of the background covered, let's go into a little more detail about how the cross-system report access was intended to work (because we leverage the same concepts in our Report Explorer product).

Notification versus Ownership

The key to understanding deployment options is to understand that conceptually we are separating report notification from report ownership. In other words, the system that generated a report is always owned by that report. Ownership means that the system continues to secure and grant access to the report, and any actions taken when viewing that report are specific to the system that generated the report (more on this later). This also means that any means of aggregating the list of reports and/ore notifying end-users of those reports (with links back) is just that: a list of reports with links to access them in place.

For a product like nVision, where you need to drill, the information needed to do the drilling is embedded directly in the report from the system running the nVision report. There's actually PeopleCode that embeds this information as a parameter on the command line. This means that regardless of how you open the nVision report, it will go back to the system that ran the report to perform the drill (which is exactly what you would want it to do). This works the same way if you use one of the drilling techniques discussed in the following blog entry. Because the local system is running and managing the report, you don't have to worry about it if you use the PSRF integration broker messages as a means of pulling it together. Even if you physically move the reports to a new location, the metadata needed to drill contains the URL to access the system it was generated from (but if you delete the report from the report repository after you move it, you will prevent the drilling from occurring because the process scheduler won't be able to find it).

So, the simple answer is that because the system that ran the report also puts in the additional drilling metadata (including the URLs to access the system), drilling will continue to work even if you copy or aggregate the links to access the reports elsewhere.

Labels: Drilling, Report_Manager