This is a topic that comes up quite frequently when looking at reporting from an enterprise perspective. No user wants to go to several different places to do his job. This is the reason why portals have sprung up. Because PeopleSof has both a set of reporting tools and a report distribution/access framework, and because many customers have many different reporting tools in-house the span many different applications, many customers want to figure out how to combine them together.
Well, actually, no. Although PeopleSoft does deliver the report list as a portal pagelet that can be embedded into the PeopleSoft portal or another portal, this is not what customers want. Customers want a single integrated list of their reports, so that they can go to one place, see all the reports generated in the past day, and view them. This means that customers want the lists of reports across their different reporting tools merged into a single list.
Well, there are 4 ways to approach this problem:
So, the first question is: do you want PeopleSoft to be the place where people go to access their reports or another tool? There are several things to consider when determining whether to use PeopleSoft or another tool:
The second question is: do you want to move the reports or register them in place? Here is what you should consider when making this decision:
Move all reports into the PeopleSoft repository.
There are a couple of techniques you can follow to accomplish this (and the one you take is primarily dependent on the tools release you are on). Here is a list:
The first is the easiest one to use, because it is well documented. The PostReport() function (which is only available on PeopleTools 8.4 and greater) allows you to specify a location of a file, as well as the metadata needed to organize it in the report repository (such as who has access to it, and the folder it should be placed in). You can use PostReport() in app engine or in a PeopleSoft page. When used in app engine, you can set up a daemon process to look in a directory for a file and then move it when it finds it (PeopleSoft delivers a sample daemon process out of the box that is also well documented).
The second method is to use the way process scheduler manages output to your advantage (and is the way you need to do it for tools releases that don’t have PostReport(). Let’s talk a little bit about how process scheduler works.
When process scheduler starts a new process, it creates a unique temporary working directory for it (it containes the process instance ID, so that all running processes get their own directory). All output of programs get put into that directory by default. When the process has completed (either by ending normally and updating the status to either error or successful, or by having the process scheduler detect that the PID of the process doesn’t exist any more), all output in this directory is collected and copied to the report repository (which is what happens when the state of a process is “posting”).
Therefore, one can move output to the report repository by merely running a process in the process scheduler and copying a file into the default output directory of that process. The distribution settings of the process would be used and the file would be moved to the report repository. This physical act of copying can be done through any of the following methods:
Each of the different tools has its own substitution variable for the standard output directory, and is documented in the process scheduler documentation (but for example, %SQOT is the output directory for SQR).
Now, it’s important to note that the distribution rule of the process that does the copying is the rule that is used for putting output into report manager. This means that the list of users who have access to it as well as the folder it shows up in comes from the calling program and cannot be overridden. Therefore, many organizations will write a separate program in application engine that uses the ScheduleProcess PeopleCode function to set the distribution rules and then run the program that does the copying. This calling program is often implemented as a Daemon, which also has logic to figure out which settings to apply to a given file (which could merely be a second file in the same directory with that information in it).
This is actually relatively easy to accomplish, if you’re willing to use integration broker. The report distribution infrastructure was designed to work in an environment with multiple PeopleSoft environments (such as Enterprise Portal, HR, and Financials). To do this, we implemented messages to publish information about a new report when it is posted. This allows the different PeopleSoft environments to subscribe to those messages to have reports from the other PeopleSoft system registered to it. Because PeopleSoft messages are exposed as XML, you merely need to generate the appropriate set of XML messages to register external content.
There’s also a message for updating a report, but I forget the name (just look for the PSRF prefix and you’ll find it). When generating the XML, the most important things to provide are the URL for accessing the content, and the list of users or roles who have access to it.
When the 3rd party system generates the XML message, it merely needs to send it to the integration gateway URL you set up with integration broker.
If you want to move your PeopleSoft reports to a 3rd party tool, there are also several techniques available.
The approach you take is primarily dependent on the functionality available in the 3rd party system.
There are two techniques you can use to register the URL to access a report from the report repository using a 3rd party tool. They are as follows: