Creating Audit Record Definitions
To audit a record using triggers, you must create a record definition in Application Designer and build the SQL table in which you store audit information. When creating the audit record, remove any attributes, such as Parent records, Query Security Records, and PeopleCode.
The easiest way to create an audit table is to open the record definition of the base record that you want to audit. Save it as a new record, prefaced with AUDIT_.
Note: When you create a new audit record definition, be sure to name it with an AUDIT_ prefix. Some processes, such as the Employee ID Change and Employee ID Delete in PeopleSoft HCM product line, make changes to certain fields, such as EMPLID. These processes do not affect any record definitions that begin with the AUDIT_ prefix, leaving the audit data secure.
Remove all edit and key attributes from the newly saved record. Add to the top of the audit record the following audit-specific fields:
AUDIT_OPRID
AUDIT_STAMP
AUDIT_ACTN
Make these fields required and keys. The following table explains the purpose of each audit-specific field.
Note: When you add these fields to the audit record, add them in the same order that they appear in the following table.
Audit Field Name |
Purpose |
---|---|
AUDIT_OPRID |
Identifies the user who causes the system to trigger the audits, either by performing an add, change, or delete to an audited field. |
AUDIT_STAMP |
Identifies the date and time that the audit is triggered. Note: If there is a possibility that multiple audit rows would be generated within the same second or millisecond, then AUDIT_STAMP should be made a Duplicate Key. |
AUDIT_ACTN |
Indicates the type of action the system audited. Possible action values include:
|
The audit table does not have to include all the columns of the base table. In fact, for performance reasons, it's best to only include those fields in the audit record that are deemed sensitive or significant. When adding fields to the audit record, PeopleSoft recommends that you conform to the order that they appear in the base record.
Note: This functionality allows for the Microsoft SQL Server requirement of not including ntext, text columns in the trigger syntax, as well as Oracle's requirement to exclude the LONG data type from audit records.
The following example compares the base table to the audit table, showing the audit-specific fields and the fields that are to be audited in the audit table.
Base Table PS_ABSENCE_HIST |
Audit Table PS_AUDIT_ABSENCE |
---|---|
AUDIT_OPRID |
|
AUDIT_STAMP |
|
AUDIT_ACTN |
|
EMPLID |
EMPLID |
ABSENCE_TYPE |
ABSENCE_TYPE |
BEGIN_DT |
|
RETURN_DT |
|
DURATION_DAYS |
|
DURATION_HOURS |
|
REASON |
REASON |
PAID_UNPAID |
|
EMPLOYER_APPROVED |
|
COMMENTS |
Once you save the record definition, you need to run the SQL Build procedure to build the SQL table in the relational database management system (RDBMS).
Following is an example of a SQL script for an audit record that audits the PS_ABSENCE_HIST table:
-- WARNING:
--
-- This script should not be run in Data Mover. It may contain platform
-- specific syntax that Data Mover is unable to comprehend. Please use the
-- SQL query tool included with your database engine to process this script.
--
USE PT8A
go
SET IMPLICIT_TRANSACTIONS ON
go
IF EXISTS (SELECT 'X' FROM SYSOBJECTS WHERE TYPE = 'U' AND NAME =
'PS_AUDIT_ABSENCE') DROP TABLE PS_AUDIT_ABSENCE
go
CREATE TABLE PS_AUDIT_ABSENCE (AUDIT_OPRID CHAR(8) NULL,
AUDIT_STAMP PSDATETIME NOT NULL,
AUDIT_ACTN CHAR(1) NOT NULL,
EMPLID CHAR(11) NOT NULL,
ABSENCE_TYPE CHAR(3) NOT NULL,
BEGIN_DT PSDATE NULL,
RETURN_DT PSDATE NULL,
DURATION_DAYS SMALLINT NOT NULL,
DURATION_HOURS DECIMAL(2,1) NOT NULL,
REASON CHAR(30) NOT NULL,
PAID_UNPAID CHAR(1) NOT NULL,
EMPLOYER_APPROVED CHAR(1) NOT NULL)
-- COMMENTS TEXT NULL) Text and Image Fields are not allowed
go
COMMIT
Go
If COMMENTS is not allowed during the actual creation of the audit table, drop the column or do not choose the column when you create the audit table definition.