Audit Reports in PeopleSoft

For truly understanding the purpose of the peoplesoft audit reports, it is required to back-track a little to recall on what kind of data will be available in the peoplesoft database. 

The peoplesoft database is basically a combination of three layers, 

1. The Database System tables.

2. The Peopletools tables.

3. The Peoplesoft application tables.

The database system tables consists of all the system metadata and the core tables which is required for the proper functioning of the database.

The peopletools tables is populated during the creation of the peoplesoft application. These tables generally start with a PS*** example PSOPRDEFN.

The application tables are also created during the implementation phase of the application. The type of application tables depends upon what kind of data is imported such as it could be HRMS, FSCM and so on. These tables begin with a PS_*** example PS_JOB.

Now that we are clear on what kind of data the Peoplesoft database is composed of we can move on to learn about the peoplesoft audit reports.

Audit reports are generally used pre or post an upgrade or any changes in the application. This is used to check the sanity of the database. The below listed are the reports which are available for use.

1. Alter Audit

2. SYSAUDIT 

3. DDDAUDT

The alter audit is not a process, it is created using application designer by filtering all the records that will be required to be part of this audit and then using alter options as alter in place and building the selected objects with execute and build options. This will help to understand which all tables require an alter to be processed in the database.

The sysaudit is used to check all the orphaned objects which are present in the database. For example there could be a piece of peoplecode which is not being referenced anywhere.

The dddaudit is an sqr program which is used to check the differences in data between the system tables and the peopletools and application tables.

SchedulerTransfer Servlet error

ISSUE:
The PeopleSoft process has completed, but the report posting status has completed with Not Posted. When the message log of the process was checked the error message says Scheduler Transfer error.

Error getting report repository location. (63,85)

SchedulerTransfer Servlet error.

PSEXA failed to post files to the report repository. Server

scheduled to try again on 2013-11-18-10.48.57.782504.

CAUSE:
This issue occurs because the servlet SchedulerTransfer which is used be the application for posting the reports from the peoplesoft process scheduler to the web server repository has failed.

SOLUTION:
This issue can be resolved by manually invoking the SchedulerTransfer servlet and resending the contents of the process.

PeopleSoft Signon Process.

For understanding the peoplesoft signon process it is crucial to be aware of the various IDs which PeopleSoft uses.

The below list of IDs are used by peoplesoft to perform the connection to the database,

1. User ID
2. Connect ID
3. Symbolic ID
4. Access ID

User ID:
The user ID is used by the user to enter his personal login credentials in the PIA login page.
Connect ID:
The connect ID is stored in the psappsrv.cfg file of the application server, and is used to make the initial connection to the database. The connect ID has select access on the PSACCESSPRFL, PSOPRDEFN and PSSTATUS and PS.PSDBOWNER tables.
Symbolic ID:
The symbolic ID acts as a bridge between the connect ID and the Access ID.
Access ID:
The access ID is the database owner ID. The final connection is made with this ID to access the tables of the application.

Signon Process:
The basic outline of the peoplesoft signon process is as below,

1. The User enters his user ID and password in the PeopleSoft signon page.
2. The application server retrieves the password of the Connect ID from the psappsrv.cfg file and makes the initial connection to the database.
3. Using the connect ID the application checks the PSOPRDEFN for the user details and the symbolic ID. The application then uses the symbolic ID to fetch the appropriate Access ID from the PSACCESSPRFL table and checks the Version and Owner ID from the PSSTATUS tables. The owner ID and database name is retrieved from the PS.PSDBOWNER table.
4. Once all these information is retrieved the application will disconnect and connect using the access ID.

If there is ever an issue in booting up the application server, the issue will probably be in these 4 tables.