Setting Record Properties
After you create a record definition, you will want to apply attributes so that the record functions. Access the dialog box by selecting Record Properties, and then select either the General tab or the Use tab. This section discusses how to:
Set general properties.
Set use properties.
Create user-defined audit record definitions.
Access the Record Properties, General tab.
Field or Control |
Definition |
---|---|
Description |
Enter a descriptive name for the record. |
Record Definition |
Enter appropriate comments in this area, including details about the record type, use, parent and child relationships, or other information that is important to other application designers. |
Owner ID |
Displays a list of applications with which this record is used. This list is helpful to identify the applications with which the record is associated during application development. |
Last Updated |
Displays the date and time of the last modification that was made to the record and the name of the user who made the modification. |
Access the Record Properties, Use tab.
These properties control the way the record definition is used in the system.
Specify the field with which the system maps between the original key and the tablesets in the Set Control Field drop-down list box.
See Defining Set Control Fields.
Record Relationship Settings
Field or Control |
Definition |
---|---|
Parent Record |
If this is a subordinate or child record, specify the parent record. |
Related Language Record |
Specify a related language record:
|
Query Security Record |
Specify a query security record if you want secure access to a record using a security view. |
Advanced Query Security |
Click to display Advanced Query Security Record Mapping dialog box, which you can use to specify multiple query security records. Using multiple query security records is described in more detail in the product documentation for PeopleTools: Query. See Using Row-Level Security and Query Security Record Definitions. |
Analytic Delete Record |
Specify a delete record to use for optimization. |
Record Name |
Specify the user-defined audit record. |
Audit Options
While you can audit individual fields at the field level, you might find it more efficient to have the system audit the entire row whenever a user adds, changes, or deletes information. For record-level audits, the system focuses on rows of data instead of specific fields. Consequently, a record-level audit writes a single row of audit data rather than writing multiple rows for each insert, change, or delete transaction at the field level.
Field or Control |
Definition |
---|---|
Add |
Inserts an audit table row whenever a new row is added to the table underlying the record definition. |
Change |
Inserts one or two audit table rows whenever a row is changed in the table underlying this record definition. |
Selective |
Inserts one or two audit table rows whenever a field that is also included in the record definition for the audit table is changed. |
Delete |
Inserts an audit table row whenever a row is deleted from the table underlying the record definition. |
Record-Level Auto-Update Options
These settings are used exclusively for mobile applications, enabling developers to display derived values on a mobile page. These settings are not available for subrecords.
Important! PeopleSoft Mobile Agent is a deprecated product. These features exist for backward compatibility only.
Field or Control |
Definition |
---|---|
System ID Field |
Set this field to assign a unique way to identify the record for mobile synchronization purposes. You must create a user-defined index for this field. |
Timestamp Field |
Set this field to automatically update the field with the date and time when there is a change to the record for mobile synchronization purposes. |
Record Information
Record Information contains options used during PeopleSoft upgrades.
Field or Control |
Definition |
---|---|
Tools Table |
Identifies SQL tables owned by PeopleSoft PeopleTools development, which is typically the same ownership as indicated by the PPLTOOLS project. |
Managed |
Identifies SQL tables owned by PeopleSoft PeopleTools development that contain information that is used by managed (cached) objects. |
Field or Control |
Definition |
---|---|
Append ALL (Dynamic Views) |
Applies to dynamic views. If it is set, then at runtime the system appends the WHERE clause generated at runtime to all the SELECT statements in a dynamic view with a UNION. Also, if it is set, at runtime the system generates FILL as the table alias in the WHERE clause condition. For example, FILL.<record field name> LIKE '%O%'. You need to specify which table corresponds to the FILL in the dynamic view definition. For example, FROM table A FILL. You must specify the corresponding table because the same record field name may exist in two different records. |
Oracle In Memory
These settings apply only to the Oracle database, beginning with Oracle 12c. Use these settings to implement Oracle In-memory Column Store (IM column store) technology with your PeopleSoft system.
For more information on the Oracle In Memory feature, see Working With Oracle Database In-Memory.
Field or Control |
Definition |
---|---|
All Fields |
Select if you want all fields in the record definition to be stored in the IM column store. When selected, the system prepares all record fields to become part of the IM column store, except for those fields which are not supported for IM operations. That is, the In Memory check box will be enabled and selected for all record fields in the record definition where the record field is supported for IM column store processing. IM column store technology does not support these data types:
Note: If you select All Fields, and the table contains any fields with a data type that is not supported for IM processing, the system will change your selection to Selective Fields upon Save. Only the record fields that are supported for IM column store processing will have the In Memory check box selected automatically by the system in the record field properties. Note: If All Fields is selected, and the record definition contains fields that are not supported for IM column store processing, those fields will be explicitly excluded from the build process DDL. |
Selective Fields |
Select if you want to choose individual fields to include in IM column store processing. Once selected, the In Memory check box becomes enabled on the Record Field Properties, Use tab for all record fields supported for IM column store processing. For more information on the In Memory record field property, see Setting Record Field Use Properties. |
Note: After selecting any Oracle In Memory options, you must alter the table in order for the feature to take effect. See Specifying Alter Options.
To audit at the record level, you must create a record definition and SQL table in which you store audit information. When you create a new audit record definition, name it with an AUDIT_ prefix. Some processes, such as the Employee ID Change and Employee ID Delete processes in the PeopleSoft Human Resources Management product line, change fields, such as EMPLID (employee identification). These processes do not affect record definitions that begin with the AUDIT_ prefix, leaving your audit data secure.
The easiest way to create an audit table is to open the record definition that you want to audit and save it as a new record definition, prefaced with AUDIT_. Audit record definitions cannot contain key fields. Therefore, if you clone a record definition to create an audit record definition, you must remove all key attributes.
You should also use the audit-specific fields that are already defined for the PeopleTools audit tables (PSAUDIT and PSAUDITEXT), which the PeopleSoft application uses to track field-level audits. Place these audit fields at the top of the audit record definition, as you would keys. If you are creating several user-defined audit record definitions, you might consider creating and using a subrecord definition with these audit fields instead of adding them individually to each audit record definition.
This table lists audit field names and their purpose:
Audit Field Name |
Purpose |
---|---|
AUDIT_OPRID |
Identifies the user who caused 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 the audit was triggered. Note: If there is a possibility that multiple audit rows would be generated within the same second or millisecond, then AUDIT_STAMP must be set as a duplicate key. |
AUDIT_ACTN |
Indicates the type of action that the system audited. Possible actions include:
|
AUDIT_RECNAME |
Identifies the name of the record definition that was audited. |
In most cases, you should include AUDIT_OPRID, AUDIT_STAMP, and AUDIT_ACTN. The AUDIT_STAMP must be given the attribute AUTOUPDATE. You might also add AUDIT_RECNAME if you are creating an audit table to audit more than one record definition.
Note: Select the Auto-Update check box in the Record Field Properties dialog box; otherwise, the audit record does not receive a date and time stamp.