Pomona PeopleSoft Development StandardsDRAFT
/ Cal Poly PomonaPeopleSoft Development Standards
Last Revised: / 11/04/2010
REVISION CONTROL
Document Title: / Pomona PeopleSoft Development StandardsAuthor: / Tim Raymond
File Reference: / Pomona PeopleSoft Development Standards.doc
Date / By / Action / Pages
2/20/2008 / Tim Raymond / New Document / All
11/10/2010 / Tim Raymond / Removed “Draft” status.
Review/Approval History
Date / By / Action / PagesTable of Contents
Page
Section 1Naming Conventions
1.1Module Names
1.2Report/Process Naming
1.2.1Cloning CSU delivered reports/processes
1.2.2Cloning PeopleSoft delivered reports/processes
1.2.3Pomona reports/processes
1.3PeopleSoft Object Naming
1.3.1Records
1.3.2Pages
1.3.3Components
1.3.4Menu Items
1.3.5Portal Registry
Section 2Documentation Guidelines
2.1Documenting New Files or Objects
2.1.1SQR/SQCs
2.1.2PeopleSoft Objects
2.2Documenting Changes to Existing Files or Objects
2.2.1SQR/SQCs
2.2.2PeopleSoft Objects
2.3Changing and/or Removing Previously Documented Changes
Section 3Development Standards
3.1SQR/SQC
3.1.1Program Text File Width - Guideline
3.1.2Procedures - Standard
3.1.3Defined Variables – Standard
3.1.4Using Input/Output Files
3.2PeopleSoft Objects
3.2.1Standards Common to all PeopleSoft Objects
3.2.2Records
3.2.3Pages
3.2.4Message Catalog Entries
Section 4Appendix
4.1Appendix A – New SQR Documentation Example
4.2Appendix B – PeopleSoft Object Documentation Example
4.3Appendix C – PeopleCode Documentation Example
Last Revised: 10/28/2018
Section 1Naming Conventions
The standard Pomona naming conventionbegins with POM. Additionally the name should also contain the abbreviated module namewhen applicable (see below). How the abbreviated module name is included in the name is dependent on the type of item. This document will provide guidelines as to how to name various items/objects that you develop.
1.1Module Names
The following is a list of the module abbreviations for HCM:
HR - Human Resources (general HR reports)
BD – Budgets (in the HR system)
BN – Benefits
PY – Payroll
RR – Regulatory Reports
RS – Recruiting Solutions
TL – Time & Labor
WA –Workforce Administration
SSH – Self-Service Human Resources
SA – Student Administration (general SA reports that DO NOT fall into a module)
AD – Admissions
AA – Academic Advisement
EU – Extended University
FA – Financial Aid
FC – Faculty Affairs
SF – Student Financials
SR – Student Records
CC – Campus Community
SSS – Self-Service Student
The following is a list of the module abbreviations for Finance:
FN – General Finance Application
AM – Asset Management
AP – Accounts Payable
AR – Accounts Receivable
BG – Budgets
GL – General Ledger
PO – Purchasing
1.2Report/Process Naming
1.2.1Cloning CSU delivered reports/processes
If the report/process is CSU delivered and is being cloned by Pomona, the Pomona version should retain (if not already taken) the same module designation and number (if it is not already used), and replace ‘CSU’ with ‘POM’.
For example CSUSR104.sqr becomes POMSR104.sqr.
1.2.2Cloning PeopleSoft delivered reports/processes
If the report/process is PeopleSoft delivered and is being cloned by Pomona, the Pomona version should attempt to preserve as much of the original name as possible, while pre-pending ‘POM’ to the beginning of the name.When possible the module name should be preserved, however in these cases it is realized that space is an issue.
For example CCLTRGEN.sqr becomes POMLTRGN.sqr.
1.2.3Pomonareports/processes
Pomona reports/processes will be named using the following convention:
POMXXNNN
Where XX is the module abbreviation (SR, FA, AD, CC, etc.) and NNN is the report/process number. Report numbers shall be between 101 and 499, incremented sequentially. Process number shall be a number greater than 499 incremented sequentially. Numbers below 101 are reserved for CSU use. The next sequential number for the given module can be found on the I&IT Applications website at:
The tracking spreadsheet should be immediately updated (incremented) after the number is determined. This will avoid the possibility that multiple developers may develop a report/process using the same number.
1.3PeopleSoft Object Naming
1.3.1Fields
In order to create the most flexibility and reusability of Pomona fields, field names should not contain the module name and should be named using the following naming convention:
POM_...
The ellipses (…) should be replaced by text that makes sense. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.
1.3.2Records
Run Control Records
Pomona has defined common run control records for each module. In HCM these records are:
POM_HR_RNCTL – Human Resources
POM_PY_RNCTL – Payroll
POM_RS_RNCTL – Recruiting Solutions
POM_TL_RNCTL – Time & Labor
POM_SA_RNCTL – Student Administration
POM_AD_RNCTL – Admissions
POM_CC_RNCTL – Campus Community
POM_FC_RNCTL – Faculty Affairs
POM_SF_RNCTL – Student Financials
POM_SR_RNCTL – Student Records
POM_EU_RNCTL – Extended University
In Finance these records are:
POM_FN_RNCTL – General Finance
POM_AM_RNCTL – Asset Management
POM_AP_RNCTL – Accounts Payable
POM_GL_RNCTL – General Ledger
POM_PO_RNCTL – Purchasing
When developing for any of these modules, the common run control record should be used. If the fields needed by the process do not exist they should be added (non-destructively) to the common run control record. The only occasion when a new run control record should be created is when the run control page will have a scroll level that the common run control record does not support. In that case the record should be named using the following naming convention:
POM_XXNNNN_RNCTL
Where XX is the module abbreviation and NNN is the report/process number.
Set-Up Records
If a record is created as a set-up record for a report or process, the record should be named using the following naming convention:
POM_XXNNN_SETUP
or if the record is effective dated:
POM_XXNNN_EFFDT
If child tables are utilized they should be named using the standard report/process prefix of:
POM_XXNNNN_
Where XX is the module abbreviation and NNN is the report/process number.
The remainder of the name is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining five characters.
Data Records
Data records are rarely associated with a report or process and as such have more leeway in their naming. Data records should be named using the following naming prefix:
POM_XX_
Where XX is the abbreviated module name. The remainder of the name is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters. In rare circumstances an additional character many be needed when naming the record. If that is the case, then the trailing underscore shown in the convention above may be dropped.
Derived Records (Work Records)
Derived records should be named using the following naming conventions:
POM_..._WRK
or
POM_DERIVED_…
The ellipses (…) should be replaced by a module name if the record is being created specific to a module, or other text that makes sense. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters
Temporary Records
Temporary records are often associated with a report/process. The type of process (SQR or Application Engine) will determine the naming convention. The records should be named using the following naming convention:
Application Engine:POM_XXNNN_TAO
Non Application Engine: POM_XXNNN_TMP
Where XX is the module name and NNN is the report/process number. If multiple temporary tables are needed for a single report/process, the tables should be named using the following naming convention:
Application Engine:POM_XXNNNA_TAO
POM_XXNNNB_TAO
Non Application Engine: POM_XXNNNA_TMP
POM_XXNNNB_TMP
Where XX is the module name and NNN is the report/process number.
If a temporary table is needed for a purpose other than a report/process, it should be named using the following naming convention:
POM_..._TMP
The text used to replaces the ellipses (…) is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.
Application Engine State Records
Application Engine state records hold the value of variables while an Application Engine program is running. The records should be named using the following naming convention:
POM_XXNNN_AET
Where XX is the module name and NNN is the report/process number.
Views
Views that are created as a search view should be named using the following naming convention:
POM_..._SRCH
The text used to replaces the ellipses (…) is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.
Views that are created in support of a report/processshould be named using the following naming convention:
POM_XXNNN_VW
Where XX is the module name and NNN is the report/process number.
If the view is not created in support of a process/process, it should be named using the following naming convention:
POM_XX…_VW
Where XX is the module name. The text used to replaces the ellipses (…) is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.
1.3.3Pages
Run Control Pages
Run control pages should be named using the following naming convention:
POM_XXNNNN_RNCTL
Where XX is the module abbreviation and NNN is the report/process number. Note this would be identical to the record name if a record were created specifically for the process.
Run Control Set-Up Pages
If a set-up page is created as part of a process, the page should be named using the following naming convention:
POM_XXNNN_SETUP
or if the page is effective dated:
POM_XXNNN_EFFDT
Where XX is the module abbreviation and NNN is the report/process number. If additional pages including secondary and/or subpages are utilized they should be named using the standard report/process prefix of:
POM_XXNNNN_
However the remainder of the name is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining five characters. Note that this will cause the pages and their associated records have the same name. This is intended.
Other Set-Up Pages
Set-up pages not associated with a report/process should be named using the following naming prefix:
POM_XX_
Where XX is the module abbreviation. The remainder of the name is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining nine characters.
Inquire/Use Pages
Inquire/Use pages should be named using the following naming prefix:
POM_XX_
Where XX is the module abbreviation. The remainder of the name is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining nine characters.
Subpages
Subpages should be named using the following naming convention:
POM_XX…_SBP
Where XX is the module abbreviation, however this may be omitted if the subpage has the ability to be used by various modules. The text used to replaces the ellipses (…) is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.
Secondary Pages
Secondary pages should be named using the following naming convention:
POM_XX…_SEC
Where XX is the module abbreviation. The text used to replaces the ellipses (…) is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.
1.3.4Components
Run Control Components
Run control components should be named the same as the run control page that it contains. If the component contains multiple pages, it should be named the same as the main run control page:
POM_XXNNN_RNCTL
Where XX is the module abbreviation and NNN is the report/process number.
Run Control Set-Up Components
If a set-up component is created as part of a process, the component should be named using the following naming convention:
POM_XXNNN_SETUP
Where XX is the module abbreviation. This name should match the name of the main page in the component.
Other Set-Up Components
Components that contain set-up pages not associated with a report/process should be named using the following naming prefix:
POM_XX_
Where XX is the module abbreviation. This name should match the name of the main page in the component.
Inquire/Use Components
Components that contain Inquire/Use pages should be named using the following naming prefix:
POM_XX_
Where XX is the module abbreviation.This name should match the name of the main page in the component.
1.3.5Menu Items
Pomona Custom Menu
The Pomona Custom menu is the menu that is updated regularly. Menu items contain two entries, Name and Label. All names added to this menu should be named using the following naming convention:
Name: The name of the component the menu item is for
The label may vary depending on the type of component the menu item refers to. In all cases the label should begin with the two letter module abbreviation that the menu item is for. Menu labels should be named using one of the following naming prefixes:
Label: XXNNN-…
Label: XX-…
Where XX is the module abbreviation. If the item being added is a report/process, the module abbreviation should be followed by the 3 digit report/process number and a dash. If the item being added is not a report/process then the module abbreviation and dash is sufficient. The text used to replaces the ellipses (…) is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.
Delivered Menu
On occasion we will seek an exemption and modify a delivered menu. All names and labels added to delivered menus should be named using the following naming convention:
Name: The name of the component the menu item is for
Label: POM-…
The use of the prefix POM is to assist in easily identifying Pomona changes to delivered menus. The text used to replaces the ellipses (…) is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.
1.3.6Portal Registry
Portal Registry Entries
Portal Registry Entries contain Name, Label, and Long Description fields to be entered. Portal Registry entry names should be named using the following naming convention:
Name: COMPONENT_NAME_MARKET
Where COMPONENT_NAME is the name of the component the Portal Registry is being created for, and _MARKET is the market that the component was saved as. E.G.:POM_AA101_RNCTL_USA.
The label and long description of a portal registry entry should be named using one of the following naming prefixes:
Label & Long Description: XXNNN-…
Label & Long Description: XX-…
Where XX is the module abbreviation. If the item being added is a report/process, the module abbreviation should be followed by the 3 digit report/process number and a dash. If the item being added is not a report/process then the module abbreviation and dash is sufficient. The text used to replaces the ellipses (…) is at the developer’s discretion. Every attempt should be made to make the name as meaningful and descriptive as possible utilizing the remaining characters.
Section 2Documentation Guidelines
All development should be appropriately documented. How that is accomplished varies depending on the object type being developed. This section will provide guidance on how to appropriately document development at Cal Poly Pomona.
2.1Documenting New Files or Objects
Currently SQRsand PeopleSoft objects reflect a variety of documentation standards as they have changed over time. This section will provide guidance as to what the current standard is, as well as when documentation should be removed from files or objects that are being modified.
2.1.1SQR/SQCs
A sample document displaying the following standards can be found in Appendix A.
All SQR/SQCs should have a standard header consisting of multiple sections that contain the following information:
- Campus, Report Name (File Name), Developer Name, Creation Date, and Program Name
- Program Description (and for SQCs “Used By”)
- The program description should be a concise and relatively non-technical description of the program
- Used By should reference SQRs that include the SQC
- Table Usage
- This should contain afull list of all tables utilized by the process.The list should include the full table name, a brief description of the table, and the actions performed on the table by the program. Options may contain one, two, or all of the following actions separated by a / character:
- SELECT
- UPDATE
- INSERT
- Debugging Levels
- This section should note the various types of debug statements in use throughout the program and a description of what each type do when enabled in the process definition.
- Maintenance History and Programming Notes
- This section may or may not contain any information when the program is initially written.
- For standards to follow when populating this section, please see Section 2.2.1.
The standard delimiter between the header documentation sections is an exclamation point followed by hyphens equal to the file width -1 (i.e.: !------…). Using the standard delimiter is important as it used by a script that pulls the first two sections from each SQR/SQC and stores it in a text file.
All SQRs should also contain the following four constants:
- PROCESS_NAME
- VERSION_NUMBER
- LAST_UPDATE_DATE
- CREATE_DATE
All SQRs should contain the following line in the Init-Report procedure to produce the standard Cal Poly Pomona log file header:
Do Display-Pomona-Report-Header
All SQRs should contain the following include statement to allow for the printing of the standard Cal Poly Pomona report header:
#include ‘pomloghdr.sqc’ !Standard Cal Poly Pomona Log Header
2.1.2PeopleSoft Objects
Pomona Custom Menus
The Pomona custom menus’ object properties should be updated each time an item is added. The update should include:
Date, User, Menu, Action
Where User is the person performing the update, Menu is the portion of the menu being updated (i.e.: SetUp, Process, etc.), and Action is what was added.
Example:
**********************************************************************************
DATE USER MENU ACTION
------
11/25/03 Mauricio Calderon CreatedMenu for SA Custom Reports
11/25/03 Mauricio Calderon Process Added CC500.sqr
Other Objects Including but not limited to: Application Engine, Component, Menu, Page, and Record, Delivered PS/CSU Objects (including Menus)
The object definition properties of all PeopleSoft objects should contain a description. The comments section should also contain the campus name, the name of the developer who created the object, the date the object was created, and a description of the object or its use. If there is additional information of value (such as the name of the modification or process that the object is associated with) that should be documented in the comments section as well. A sample displaying the following standards can be found below as well as in Appendix B: