Blog

Created on Friday, 19 August 2005 15:25

Written by Larry Grey

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.

Wouldn't a Portal solve this?

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.

Okay, so what are my options?

Well, there are 4 ways to approach this problem:

1. Move all reports into the PeopleSoft report repository.
2. Register all reports to PeopleSoft report manager.
3. Move all reports to a 3rd party tool.
4. Register all reports to a 3rd party tool.

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:

1. With PeopleSoft, the users, passwords, and roles are the same as the application users, passwords, and roles.
2. PeopleSoft does not charge additional licensing fees to use its report distribution framework, whereas 3rd party tools generally charge on a per-user basis.
3. The UI for report manager is generally more limited than other report tools. However, these areas can be addressed through the following packaged services (warning... shameless marketing at the other end of this hyperlink).
4. You should determine which is the primary environment for your users. If the majority of your users aren't PeopleSoft application users, then it may be better to use the 3rd party 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:

1. How important is interacting with the output? In other words, if you want to provide drilling or page on demand (features that require viewing functionality generally only available when the report is kept in its original repository), then you will want to keep the output in place and register the URL for accessing the instance.
2. How important is it to have a single repository of all your reports? If you register in place with several different reporting environments, then each environment is responsible for storing, securing, and archiving its own content. This can cause an administrative overhead that you may not want to deal with.

Okay, so let's look at how one would accomplish each.

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:

1. PostReport() PeopleCode function.
2. Utilizing process scheduler distribution agent functionality

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:

1. Creating a shell script that is registered as a process definition in process scheduler.
2. Creating an app engine program
3. Creating an SQR.

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).

Register all reports into report manager

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.

The messages you need to look at are the following:

• PSRF_REPORT_CREATE
• PSRF_REPORT_DELETE
• PSRF_FOLDER_CREATE

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.

Move all reports to a 3rd party tool

If you want to move your PeopleSoft reports to a 3rd party tool, there are also several techniques available.

1. Run the report to a directory. Many customers give access to windows directories and secure the directories at the operating system. Others will copy the reports from the directory into the other system.
2. Print the report using a special print driver. This is a technique used by Vista Plus and Cypress. The process scheduler prints the report to the print driver, and then the print stream is consumed by the 3rd party tool, parsed, organized, and stored.
3. Subscribe to the XML messages generated by PeopleSoft distribution agent, and then call the URL to copy the file. Again, this is standard integration broker functionality.

The approach you take is primarily dependent on the functionality available in the 3rd party system.

Register content in the 3rd party tool

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:

1. Subscribe to the XML messages generated by PeopleSoft distribution agent and register the URL and users.
2. Write a program that reads the data from the PeopleSoft report manager (which are PS_CDM_LIST for the list of reports, and PS_CDM_AUTH for the list of users).

Labels: Process_Scheduler, Report_Manager