PeopleSoft Application Development Standards
Version 9
Enterprise Systems – UHS
PeopleSoft Application Development Standards
Table of Contents
1. DOCUMENT REVIEW ......................................................................................................................................... 5
1.1 ACKNOWLEDGEMENTS ...................................................................................................................................... 5
2. INTRODUCTION .................................................................................................................................................. 6
2.1 HISTORY ............................................................................................................................................................ 6
2.1 AUDIENCE ......................................................................................................................................................... 6
2.2 APPLICABILITY .................................................................................................................................................. 6
2.3 PURPOSE ............................................................................................................................................................ 6
2.4 ENFORCEMENT .............................................................................................................................................. 7
3. PEOPLESOFT ENVIRONMENTS ....................................................................................................................... 8
3.1 APPLICATIONS ................................................................................................................................................... 8
3.2 DATABASES ....................................................................................................................................................... 8
3.3 MIGRATION PATHS .................................................................................................................................... 10
3.4 SOURCE CODE TREES ...................................................................................................................................... 11
4. NAMING CONVENTIONS ................................................................................................................................ 12
4.1 ABBREVIATIONS .............................................................................................................................................. 12
4.2 PREFIXES ......................................................................................................................................................... 12
4.3 SUFFIXES ......................................................................................................................................................... 12
4.4 APPLICATION MODULES .................................................................................................................................. 12
4.5 INTERNAL OBJECTS ......................................................................................................................................... 13
4.6 EXTERNAL OBJECTS ........................................................................................................................................ 15
4.7 OUTPUT FILES ................................................................................................................................................. 16
5. ORACLE .............................................................................................................................................................. 18
5.1 INSTALLATIONS, UPGRADES, PATCHES, AND MAINTENANCE PACKS ................................................................ 18
5.2 BACKUP AND RECOVERY ................................................................................................................................. 18
5.3 PERFORMANCE TUNING ................................................................................................................................... 18
5.4 MAINTENANCE AND MANAGEMENT ................................................................................................................ 18
6. PATCHES, UPGRADES, AND CUSTOMIZATION ......................................................................................... 19
6.1 LOCATION AND NAMING CONVENTION ............................................................................................... 19
6.2 PEOPLETOOLS ................................................................................................................................................. 20
6.3 PATCHES AND FIXES ........................................................................................................................................ 20
6.4 CUSTOMIZATIONS ..................................................................................................................................... 21
7. SOFTWARE QUALITY ASSURANCE ............................................................................................................. 23
7.1 APPLICATION DEVELOPMENT LIFE CYCLE ....................................................................................................... 23
7.2 APPLICATION CHANGE MANAGEMENT ............................................................................................................ 24
8. PROGRAMMING STANDARDS ....................................................................................................................... 35
8.1 TRAINING REQUIREMENTS............................................................................................................................... 35
8.2 ONLINE PROGRAMMING .................................................................................................................................. 35
8.3 PEOPLECODE ............................................................................................................................................... 36
8.4 APPLICATION ENGINE ...................................................................................................................................... 38
8.5 REPORTING OPTIONS ....................................................................................................................................... 38
8.6 SQR................................................................................................................................................................. 40
8.7 CRYSTAL REPORTS .......................................................................................................................................... 47
8.8 NVISION REPORTS ........................................................................................................................................... 48
8.9 COBOL ............................................................................................................................................................. 49
8.10 BATCH PROCESSING ...................................................................................................................................... 51
8.11 INTEGRATION TECHNOLOGIES ....................................................................................................................... 58
8.12 AUDIT TABLES............................................................................................................................................... 60
8.13 CUSTOM QUERY TREES ............................................................................................................................... 61
8.14 TREES ............................................................................................................................................................ 64
Version 7.1
Enterprise Systems - UHS
Page 2 of 120
PeopleSoft Application Development Standards
9. APPLICATION TESTING .................................................................................................................................. 65
9.1 TESTING PHILOSOPHY...................................................................................................................................... 65
9.2 UNIT TEST ....................................................................................................................................................... 65
9.3 PROGRESSIVE TESTING .................................................................................................................................... 66
9.4 REGRESSION TESTING...................................................................................................................................... 66
9.5 INTEGRATION TEST.......................................................................................................................................... 66
9.6 SYSTEM TEST .................................................................................................................................................. 66
9.7 END TO END TESTING ...................................................................................................................................... 67
9.8 USER ACCEPTANCE TEST................................................................................................................................. 67
9.9 SECURITY TESTING .......................................................................................................................................... 67
9.10 LOCALITY TESTING ....................................................................................................................................... 67
9.11 LOAD TESTING .......................................................................................................................................... 67
9.12 TESTING GUIDELINES ............................................................................................................................. 68
9.14 APPLICATION REVIEW ................................................................................................................................... 70
10. PROJECT STANDARDS .................................................................................................................................. 74
10.1 STATE REQUIREMENTS .......................................................................................................................... 74
10.2 UH REQUIREMENTS .................................................................................................................................. 74
10.2 TOP TIER PROJECT PRACTICES ...................................................................................................................... 75
10.3 ENTERPRISE PROJECT MANAGER (EPM) ....................................................................................................... 75
10.4 PROJECT DOCUMENTATION ........................................................................................................................... 77
10.5 PROJECT DELIVERABLES .......................................................................................................................... 77
10.6 PROJECT TEMPLATES ..................................................................................................................................... 79
10.7 PROJECT STANDARDIZATION PROCESS ............................................................................................. 79
11. SECURITY......................................................................................................................................................... 80
11.1 BACKDOOR POLICY FOR PRODUCTION AND REPORTING DATABASES .............................................................. 80
11.2 ACCESS TO UNIX AND NT ENVIRONMENTS .................................................................................................. 80
11.3 DATABASE LINKS ........................................................................................................................................... 80
11.4 USERID ......................................................................................................................................................... 80
11.5 PASSWORD SECURITY .................................................................................................................................... 81
11.6 ROLES, PERMISSIONS, AND ROW LEVEL SECURITY ......................................................................................... 88
11.7 QUERY SECURITY .......................................................................................................................................... 88
11.8 DEVELOPER AND FUNCTIONAL ACCESS MATRIX ........................................................................................... 88
12. DOCUMENTATION ......................................................................................................................................... 89
12.1 USER’S GUIDE ........................................................................................................................................... 89
12.2 TECHNICAL REFERENCE ........................................................................................................................ 89
12.3 OPERATIONS GUIDE ................................................................................................................................ 90
12.4 APPLICATION DEVELOPMENT STANDARDS...................................................................................... 90
12.5 IN-CODE DOCUMENTATION .................................................................................................................. 90
12.6 UHS FORMS ................................................................................................................................................ 90
12.7 PEOPLEBOOKS .......................................................................................................................................... 90
12.8 PEOPLETOOLS OBJECT DEFINITIONS .................................................................................................. 90
12.9 OTHER DELIVERED DOCUMENTATION .............................................................................................. 92
12.10 PROJECT / ASSIGNMENT TRACKING .................................................................................................. 92
12.11 MODIFIED OBJECTS LIST ........................................................................................................................... 92
13. PERIODIC REVIEW ....................................................................................................................................... 101
14. READER’S COMMENTS ............................................................................................................................... 102
APPENDIX A: Modification Log .......................................................................................................................... 103
APPENDIX B - Glossary ....................................................................................................................................... 104
APPENDIX C - Abbreviations ............................................................................................................................... 104
APPENDIX D – Customer Connection Roadmaps and Schedules ........................................................................ 110
APPENDIX E – Customer Connection Updates and Fixes .................................................................................... 113
Version 7.1
Enterprise Systems - UHS
Page 3 of 120
PeopleSoft Application Development Standards
APPENDIX F – Customer Connection Filing Cases .............................................................................................. 115
APPENDIX G -- PeopleBooks ............................................................................................................................... 117
APPENDIX H – Report Format ............................................................................................................................. 120
Version 7.1
Enterprise Systems - UHS
Page 4 of 120
PeopleSoft Application Development Standards
1. DOCUMENT REVIEW
1.1 ACKNOWLEDGEMENTS
Document Review began on 9/20/07 and was completed on ____________.
Review Team:
PeopleSoft Finance – Mike Chang
PeopleSoft HRMS – Mike Lovelady
PeopleSoft Student – Meredith LaGrone
Portal & Security – Susie Winters
DBA & System Administration – Grace A. Davila
Chapter/Section
1. Document Review
2. Introduction
3. PeopleSoft Environments
4. Naming Conventions
5. Oracle
6. Patches, Upgrades, and Customization
7. Software Quality Assurance
8. Programming Standards
9. Application Testing
10. Project Standards
11. Security
12. Documentation
13. Periodic Review
14. Readers Comments
Appendix
Version 7.1
Assigned To
Mike Lovelady
Mike Lovelady
Grace A. Davila
All
Grace A. Davila
Grace A. Davila
Mike Lovelady, Mike
Chang,
Meredith LaGrone,
Grace A. Davila
Mike Lovelady, Mike
Chang,
Meredith LaGrone
Mike Lovelady, Mike
Chang,
Meredith LaGrone
Mike Lovelady
Susie Winters
Mike Lovelady, Mike
Chang,
Meredith LaGrone
Mike Lovelady
Mike Lovelady
All
Enterprise Systems - UHS
Complete
11/15/07
11/15/07
3/13/08
2/14/08
8/16/07
11/29/07
3/13/08
Approved
Y
Y
Y
Y
Y
Y
Y
1/24/08
Y
3/13/08
Y
2/14/08
1/24/08
3/6/08
Y
Y
Y
2/7/08
2/14/08
Y
Y
Page 5 of 120
PeopleSoft Application Development Standards
2. INTRODUCTION
2.1 HISTORY
On Sep. 1, 2001, University of Houston System implemented PeopleSoft Applications for Finance, Human
Resources, and Student Administration. Finance and Human Resources applications were distributed to all
components. Student Administration was implemented at the University of Houston at Clear Lake only.
In the fall of 2003, the first Application Development Standards document was developed and distributed to
PeopleSoft application developers and DBAs. Sessions were held with both groups to acquaint them with the
document and to reinforce the need to begin using these standards for all future development.
Efforts to retrofit previous development work to these standards was not made due to budgetary constraints.
As of April 22, 2008, E. S. application managers and directors are responsible for ensuring that all future
development complies with the standards contained within this document.
This document represents the second release of Application Development Standards which was completed on
March 13, 2008.
2.1 AUDIENCE
These standards are written for University of Houston System personnel developing or maintaining PeopleSoft and
related software. These include managers, technical specialists, application developers, and users having similar
computer responsibilities. The reader is assumed to be technically oriented and to have some exposure to higherlevel languages, database management systems, and systems development of PeopleSoft administrative
applications. This Application Development Standards Document is available on the web at the following URL
link.
http://www.uh.edu/infotech/php/template.php?nonsvc_id=557
2.2 APPLICABILITY
These Application Development Standards are applicable until the Application Development Standards Committee
specifies otherwise. The Application Development Standards Committee is composed of application developers,
managers, and/or directors who are appointed to serve on the committee at the time of annual review.
2.3 PURPOSE
Standards define the general form of the software development environment. Standards serve as descriptive and
instructive patterns to follow in order to achieve the best results, and are criteria for measuring work quality.
The reasons for having standards include the following:
 Information systems have developed into critical operating and strategic resources for successful commercial,
government, and educational institutions. This means that high quality control standards in computing must
prevail.
 Changes in computer system hardware or new software releases will have minimal negative organizational
impact if programs and procedures are documented and programmers adhere to a familiar set of guidelines.
 Standardized procedures and documentation enable smooth transition during personnel changes. New staff
begins productive work sooner if they learn standard work procedures and documentation techniques.
Program authors do not take a system with them when they leave or are assigned to other responsibilities.
 Understanding and enhancing system functions and procedures are made much easier through standard
documentation and communication methods. Furthermore, this understanding is shared at all levels of
management, user departments, project staffs and computer operating personnel.
 Standardized reusable software components reduce costs (requirements, design, specification, coding, testing,
and maintenance), increase application reliability, improve future maintenance efforts, and allow personnel to
concentrate on enhancing applications and other analysis work. Inflexible standards, however, can become a
barrier to meeting user needs -- "We can't do that. It doesn't fit the Standards." Invoking the standards as an
Version 7.1
Enterprise Systems - UHS
Page 6 of 120
PeopleSoft Application Development Standards
excuse for not fulfilling a request is not acceptable. Usually discussion with other developers will reveal how
the standards can meet user needs. If a user's request cannot be accommodated by current standards, then
changes to the standards should be considered. The Standards Committee was established to prepare,
maintain, and review standards. The following procedures have been adopted:
 All proposals for additions, deletions, or revisions to the Standards may be submitted to any member
of the Standards Committee.
 The Standards Committee will review proposed changes to the Standards, will work closely with
people affected by the proposed changes, and will submit proposed changes to the management team
for final approval.
 The Standards Committee chairperson will be responsible for ensuring that Standards are published
and all concerned receive updates. Application developer teams will conduct reviews of new or
existing systems, for adherence to standards. The standards are guidelines for internally developed
software only. A decision to use externally developed software is a decision not to comply with
standards. As such, an effort to transform PeopleSoft to fit this standards document is not expected
or realistic, however, development and modification of PeopleSoft software must conform to these
standards.
2.4 ENFORCEMENT
NOTE: PeopleSoft Application managers and directors and the DBA manager are responsible for the
enforcement of these standards.
Version 7.1
Enterprise Systems - UHS
Page 7 of 120
PeopleSoft Application Development Standards
3. PEOPLESOFT ENVIRONMENTS
3.1 APPLICATIONS
UHS purchased 3 applications as an enterprise wide solution for all campuses. These applications are PeopleSoft
Financials, PeopleSoft Human Capital Management, (HCM) and PeopleSoft Campus Solutions (CS).
HCM and CS applications reside on the same database and share tables with each other. PeopleSoft Financials
resides on a separate database. Data feeds between HCM/CS to PeopleSoft Financials are accomplished through
integration broker.
3.2 DATABASES
The Oracle database environments listed below are established both for Financials and for HCM/CS. Each
database resides as a separate Oracle instance and is associated with its own source code tree, which is accessible
via Windows Explorer. Reference Section 3.4 for more information on source code trees.
There are multiple databases used by Enterprise Systems for development, testing, training, production, etc. The
naming convention is
Prefix + PeopleSoft version + environment.
The prefix can be:
 FS – Financial Accounting database
 SA – Student Academic and Administration database + HR database
 PA – Portal Database used to provide single sign-on to PeopleSoft applications
 UH – Custom Application Database
The environment can be:
 CNV – conversion database
 DEV – development database
 DMO – demo database
 PRD – production database
 RPT – reporting database
 SBXn – sandbox database
 TST – test database
 TRN – training database
 UAT – user acceptance test database
 UPG – release upgrade database
 DCn – Date change database
 LOAD – Load testing Database
The diagram of the production and development environments can be found at:
Esshare$ on mis4u:\Peoplesoft\Architecture\PS_Environments.vsd
Version 7.1
Enterprise Systems - UHS
Page 8 of 120
PeopleSoft Application Development Standards
3.2.1 Sandbox Environments
The Sandbox databases are copies of the production database. They provide special troubleshooting for functional
and technical staff. The Sandbox environments are not intended to be development or training databases. During
the application patching process, one Sandbox environment may be kept on the same patch level as production.
The Sandbox environment will be used for emergency production support. Database links to production
environments are not generally established in the sandbox environment.
(FSnnSBX)
The FSnnSBX sandbox database is a copy of the financials FSPRD database.
(SAnnSBXn)
SAnnSBXn sandbox database is a copy of the student/human resources production database.
(SAnnDCx)
SAnnDCx allows the changing of system date on the server for special date sensitive process testing.
3.2.2 Demo (FSnnDMO, SAnnDMO, SAnnDMOP)
The demo databases are used by the database administrators to import patches and maintenance packs from
PeopleSoft. A PeopleSoft demo database is an application database that does not contain any customer (UHS)
customizations or modifications. A Peoplesoft Comparison Report is run against a UH customized database and
the PS demo database in order to identify the differences in PeopleSoft modified objects. The comparison reports
do not identify differences between PeopleSoft externals (SQR, SQC, Crystal, etc.). After patches and upgrade
comparison reports are reviewed, the patches continue through the migration path and are applied to the
development database.
3.2.3 Development (FSnnDEV, SAnnDEV)
The development database is where application developers create customizations to the PeopleSoft application.
When patches or maintenance packs are applied to the customized PS application, developers are required to
review/reapply previous customizations to the affected objects within the development database. All
modifications and patches must be unit tested by the developer before migrating the changes to the next database.
3.2.4 Test (FSnnTST, SAnnTST)
The test database is where functional users test patches, maintenance packs, and customizations. The test database
can also be used for system testing and integration testing. Developers are not authorized to make changes to the
test environment.
3.2.5 Production (FSnnPRD, SAnnRD)
The production database is where end users have authorized access to the PeopleSoft application. Users are
granted access to maintain application data and processes. Developers do not have access to make changes in the
production environment. PeopleSoft delivers a query utility with their product that can be used by anyone to query
data from the database and who has been granted Query access. Developers may have read access to Oracle
production databases.
3.2.6 Reporting Database (FSnnRPT, SAnnRPT)
The reporting database is refreshed nightly from the production database. It does not contain dynamic real-time
data. The reporting database is read only and exists to provide support for reporting and querying of data and to
reduce the workload on the production database environment.
3.2.7 Training (FSnnTRN, SAnnTRN)
Training databases are used for functional and technical training. Multiple copies of a training master database
may be created to accommodate a particular class. Training databases are refreshed upon request.
3.2.8 Staging Database (DWSTAGE)
This is a standard Oracle database and not part of the PeopleSoft application. This database can typically used as a
staging database for data conversion.
Version 7.1
Enterprise Systems - UHS
Page 9 of 120
PeopleSoft Application Development Standards
3.2.9 Conversion (FSnnCNV, SAnnCNV)
Conversion databases are used for conversion of legacy data to PeopleSoft tables. Legacy data may have been
stored in intermediate tables in DWSTAGE.
3.2.10 Upgrade Database (FSnnUPG, SAnnUPG)
New application releases often require a parallel set of databases (demo, development, and test) to facilitate the
upgrade process and not conflict with the existing development environments.
3.2.11 User Acceptance Test Database (SAnnQAT, FSnnQAT)
During a major application upgrade, a database may be designated as the ‘master’ tools PS application database.
Developers may need to migrate any revisions to QAT database.
3.3 MIGRATION PATHS
The following flow chart illustrates the typical migration path for patches, maintenance packs, and UHS
customizations as well as future upgrade releases. The example given, although specific to SAHR, would be used
for any upgrade of a PeopleSoft Application.
Overview of SAHR databases MP process
Phase I
Download of
MPx to P: drive
Phase II
Phase III
SAPRD (Pre-MPx)
SAPRD
(Pre-MPx)
Application of
MPx
SA89DMOP
(MPx)
Refresh
SA89SBX2
Emergency Fixes
Applied to SASBX2
Final Phase
SAPRD
(Pre-MPx)
Application of
MPx
Refresh
SA89DEV
SA89TST
Application of
MPx
SAPRD (MPx)
Application of
MPx
Refresh
Developer
Retrofits
SA89SBX2
(Pre-MPx)
Emergency Fixes to be
applied to SAPRD
and SA89DEV(MPx)
SA89DEV(MPx)
SA89TST(MPx)
Developer
Retrofits
- SASBX
- SA89DEV
-SA89DC1
- SA89SBX2
- etc.
SAPRD
(Pre-MPx)
Version 7.1
120
Enterprise Systems - UHS
Page 10 of
PeopleSoft Application Development Standards
3.4 SOURCE CODE TREES
Source code for the PeopleSoft applications reside in directories on NT and Unix servers. These directories are
referred to as “source code trees”. Each database is associated with its own source code tree.
The Configuration Manager will identify the source code tree path. The UH Development launcher will
automatically establish the appropriate source code tree upon login. The settings on the Configuration Manager
may be overwritten when necessary to perform testing in the development environment.
The following tables identify the source code trees used for the various applications and environments and
standard drive assignments.
Source code trees are located on a production drive located on \\psuh1\psdev$. The recommended configuration is
to map the drive to the ‘P’ drive.
In order to find a particular code tree the format is
1. Application Prefix (ex: SA, FS)
2. Application Environment (DEV, SBX, PRD)
Code Tree Standards: (ex: xxxx = SAnnDEV, FSnnDMO, etc)
PeopleSoft delivered SQR and
SQCs
UHS Modified or New
SQR/SQCs
PeopleSoft delivered Cobol
UHS Custom Cobol
All Crystals (PS & UHS)
All WinWord (PS & UHS)
Version 7.1
120
Finance
P:\xxxx\sqr
HRMS / SAA
P:\xxxx\sqr
P:\xxxx\user\sqr
P:\xxxx\user\sqr
P:\xxxx\src\cbl\base
P:\xxxx\user\src\cbl\base
P:\xxxx\user\crw
P:\xxxx\winword
P:\xxxx\src\cbl\base
P:\xxxx\user\src\cbl\base
P:\xxxx\user\crw
P:\xxxx\winword
Enterprise Systems - UHS
Page 11 of
PeopleSoft Application Development Standards
4. NAMING CONVENTIONS
4.1 ABBREVIATIONS
Names should be no longer in length than is necessary to identify their contents. However, do not sacrifice clarity
for the sake of brevity. Abbreviations may be used, but should be limited to easily understood and widely accepted
acronyms such as SSN for social security number.
Appendix C provides a list of commonly used abbreviations.
4.2 PREFIXES
UHS developed PeopleSoft internal objects shall have the prefix of “UHS”. Use an underscore character “_”
following the prefix if space allows.
UHS developed PeopleSoft external objects (SQC, SQR, Crystal Reports, etc.) shall have the prefix of “U”.
4.3 SUFFIXES
Suffixes should always be preceded by an underscore “_”.
The following PeopleSoft standard suffixes will be used for field names:
AMT
Amount; numeric value of currency type
CD
Code; user defined value from the Translate or other table
CNT
Count; numeric value containing a constant
DT
Date field; format DD-MMM-YYYY
DTTM
Date-Time field; format DD-MMM-YYYY and HH:MM:SS
ID
Identification; (e.g. emplid, deptid)
PCT
Percent; stored as a decimal (i.e. 50% = .5)
RT
Rate; a numeric field expressing an amount per unit (e.g. payrate)
TM
Time; format (HH:MM:SS)
The following PeopleSoft standard suffixes will be used for records names:
AET
Application Engine State Records
DVW
Dynamic View; a record definition that is implemented by defining a dynamic SQL view
(this kind of view is not a physical table).
SBR
Subrecords
SRCH
Search View; a view that is used to select specific records to be displayed to the user on a
search panel. Search views can be used to add department level security to SQR reports.
TBL
Table; a record definition that contains data that controls the application as opposed to being
maintained by the application. A “reference” table or “general” table.
TMP or
Temporary or Work; a table that is created either temporarily or permanently for a specific
WRK
purpose. Data is normally lost or truncated at the beginning of a process each time the
process is ran.
VW
View; a record definition that is physically implemented by defining an SQL view
4.4 APPLICATION MODULES
The following abbreviations are defined by PeopleBooks.
Appl
FS
FS
FS
FS
FS
FS
Module
AM
AP
AR
BI
BD
CA
Version 7.1
120
Description
Asset Management
Accounts Payable
Account Receivable
Billing
Budget
Contracts Administration
Enterprise Systems - UHS
Page 12 of
PeopleSoft Application Development Standards
Appl
FS
FS
FS
FS
FS
FS
FS
FS
FS
FS
FS
FS
FS
HR
HR
HR
HR
HR
HR
HR
HR
HR
HR
SA
SA
SA
SA
SA
SA
SA
SA
SA
SA
SA/HR
Module
CMS
DM
EX
FIN
FR
GL
IN
MR
PLS
PO
SFS
TE
TRC
ABS
APP
BEN
BUD
TL
PAY
PER
POS
TAX
TRN
AD
AA
CR
CB
FA
IS
ME
PR
SF
SR
CC
Description
Catalog Management System
Deduction Management
Expense
Financials
Financial Reports
General Ledger
Inventory
Management Reports
Planning
Purchase Order
Production Report
Travel and Expense
Treasure Cash Management
Absence
Applicant
Benefits
Budget
Time and Labor
Payroll
Personnel
Position
Tax Reporting
Training
Admissions
Advisement
Advancement – Contributor Relations
Coordinating Board
Financial Aid
International Scholars
Measurement & Evaluation
PROMES
Student Financials
Student Records
Campus Community
4.5 INTERNAL OBJECTS
Internal objects are objects that are created and maintained inside the PeopleSoft database. PeopleSoft provides a
development tool which allows developers to create and maintain these objects. Internal objects may be created
either by PeopleSoft or the University of Houston developers.
PeopleSoft delivered internal objects must never be deleted or modified. Internal objects may be modified or
cloned using the standard naming conventions described within this document.
Note: Changing PeopleSoft delivered internal objects is discouraged and requires management approval.
4.5.1 Projects
The following naming convention for UHS developed projects is
“UHS_mmm_desc”
where mmm is the application module which may be 2 or 3 characters long. See section 4.4 for approved
application modules.
Version 7.1
120
Enterprise Systems - UHS
Page 13 of
PeopleSoft Application Development Standards
The project name may include the CSR number assigned in STAT for easy identification. (Example: uhs_1234).
Each project must have the description field populated under File, Project Properties.
4.5.2 Fields
Note: Changing PeopleSoft delivered internal objects is discouraged and requires management approval.
Multiple records and panels use these fields. PeopleSoft fields can be cloned using the naming convention
standards described within this document.
The following naming convention will be used for UHS developed fields:
UHS_desc_sfx
where “UHS” is the designated prefix, and the desc is a free format description followed by a suffix.
4.5.3 Records & Subrecords
Note: Changing PeopleSoft delivered internal objects is discouraged and requires management approval.
These records are used by multiple processes. If necessary, PeopleSoft delivered records can be cloned.
The following naming convention will be used for records:
UHS_desc_sfx (for records which are not used for run control)
UHS_RC_desc (for records used for run control)
Each record must have the description field populated in record properties.
4.5.4 State Records
Application Engine employs the use of state records as a means of passing data between application engine
processes. The state record must follow the following naming convention:
2-digit Product Identifier || “_” || Description “_” ‘AET’.
Name can be mixed case.
4.5.5 Pages & Subpages
The following naming convention will be used for pages and subpages:
UHS_desc
where “UHS” is the designated prefix, and the desc is a free format description.
4.5.6 Components
The following naming convention will be used for components:
UHS_desc
where “UHS” is the designated prefix, and the desc is a free format description.
4.5.7 Menus
The following naming convention will be used for menus:
Version 7.1
120
Enterprise Systems - UHS
Page 14 of
PeopleSoft Application Development Standards
UHS_desc
where “UHS” is the designated prefix, and the desc is a free format description.
4.5.8 Process Definitions
The process definition name must match the PeopleSoft external object to be executed (sqr, Cobol, or Crystal, etc.)
4.5.9 Job Definitions
Naming convention is Uxxxxxxx
The job definition should begin with “U”.
4.5.10 Query
Naming conventions do not exist because the functional community is free to name them anything they want.
Developers should create queries beginning with UHS.
For Query used by Crystal Reports the description field can be the Crystal Report id being invoked.
4.6 EXTERNAL OBJECTS
External objects are objects that are created outside the PeopleSoft database such as COBOL, SQR, Crystal
Reports. These reside as flat files on the source code tree.
The following abbreviations and file extensions are used for PeopleSoft external objects.
Object Type
Cobol
Crystal Report
nVision Report
SQR Report
SQR include module
File Extension
Cbl
crw
Xnv
sqr
sqc
The UHS naming convention for PeopleSoft external objects or source code, with the exception of Cobol, is
u mmm nnn.ext
u mmm desc.ext
or
u mm s nnn.ext
where
u is the designated prefix of ‘U’,
mmm is a 2 or 3 character application module abbreviation (reference section 4.4),
s is a 1 character program type designation (c=Cobol, r=Crystal Report, s= Sqr/SQc, n = nVision)
nnn is a sequence number and ext is the standard file name extension associated with the type of objects.
Cobol programs and copy book naming conventions require that in the 3 rd character of the name either a “P”
(program) or a “C” for copybook appears in the name.
Version 7.1
120
Enterprise Systems - UHS
Page 15 of
PeopleSoft Application Development Standards
Unix requires all external objects should be named in lower case.
4.7 OUTPUT FILES
There are a variety of possible output types depending on the type of process being run.
4.7.1 Report Files
The default output format for Crystal is Web PDF. The output type for PS/nVision defaults to the default output
type in Report Requests. The default output type for SQR is Web PDF. COBOL and Application Engine processes
defaults create output in the log file.
The format entered for individual processes or jobs attached to a job will override the format entered for the parent
job.
The following table shows a list of file extensions that can be created by process type.
Crystal
SQR
nVision
Application
Engine
Excel (*.xls)
X
X
X
X
Word (*.doc)
X
Acrobat (*.pdf)
(Must have Acrobat Reader installed to read
these files.)
X
File type
HP Format (*.lis)
X
Line Printer (*.lis)
X
Rich Text Files (*.rtf)
X
SQR Portable Format (*.spf)
Text Files (*.txt)
X
X
Comma Delimited (*.csv)
HTML (*.htm)
X
X
Post Script Files (*.lis)
Adobe Acrobat (*.pdf)
X
X
X
X
X
X
X
X
X
X
X
X
4.7.2 Trace Files
Trace files are created whenever a developer turns trace on. Trace files trace the program code being executed and
is used for debugging purposes. Trace files should not be turned on in normal production runs. Trace files may
create extremely large files that may cause problems during execution time or post-execution when the developer
attempts to edit the trace file.
The format for report files created or maintained by batch programs
Version 7.1
120
Enterprise Systems - UHS
Page 16 of
PeopleSoft Application Development Standards
programid.trc
where programid is the name of the sqr which created the trace file.
4.7.3 Data Files
Data files are flat files that may be imported or exported to batch processes. Data files are not report files, Excel
files, or MicroSoft Access files. They typically do not contain column headings or report headings.
The naming convention is a free format using an extension of .dat.
desc.dat
where desc is a free format description.
Other files may be created for the express purpose of loading into Excel, Access, or Word, etc. As such,
appropriate file extensions may be used.
Version 7.1
120
Enterprise Systems - UHS
Page 17 of
PeopleSoft Application Development Standards
5. ORACLE
The PeopleSoft environment requires the use of a relational database management system (RDBMS). At UHS
PeopleSoft Oracle databases are maintained by the Database Administration staff in Enterprise Systems.
5.1 INSTALLATIONS, UPGRADES, PATCHES, AND MAINTENANCE PACKS
Any installation, upgrades, patches, or maintenance packs applied to the PeopleSoft application databases are
strictly the responsibility of the database administrators. Most modifications to the databases will be done on a
case-by-case basis and will be done with due consideration to the impact the change may have to the PeopleSoft
application. Unless it is an emergency situation, changes will be done to the production environments will occur
on Tuesday or Thursday between 7 p.m. and 7 a.m. or during the Sunday maintenance window between 6 a.m. to 2
p.m. If the Sunday maintenance window time period is insufficient, a three-week notice will be given to the
university community, via the Change Management Committee Calendar, and any other methods determined by
the CMC committee, in order to minimize the impact of the extended maintenance time.
5.1.1 Installations
Any new server purchased for use in the PeopleSoft environment may have some components of Oracle installed
on the machine. The version of Oracle installed will be determined by the current environment needs or any
project needs that may require a higher version of Oracle.
5.2 BACKUP AND RECOVERY
The DBAs perform several types of Oracle database backups.
5.2.1 Hot Backup
The DBAs take a full (hot) backup of all production databases every night. The hot backup allows recovery for an
entire database. It does not allow recovery for a single table or table space. The hot backup is a complete copy of
the files that make up the production database and the archive logs with the transactions that have occurred
between the time of the last hot backup and the current one. This scenario allows the DBAs to recover the database
from the point of failure. Should a database fail, the DBA will remove the corrupt copy of the database from the
server and replace it with the copied files. The recovery of a production database will be done only upon request
from the technical managers or in the event of media failure on the production server that renders the current
production database unusable. These backups are stored offsite in a secure, environmentally safe, locked facility.
5.2.2 Exports
An export will allow the recovery of an individual object or an individual schema or the entire database. The
DBAs take a full export of all databases every night except for databases not required to support daily operations.
The export differs from the hot backup in terms of recovery because it is a copy of the database placed into one
file. The export allows for point in time recovery. Should a table be dropped from the database, the DBA can
recover the table, as of the time the export was taken. The transactions entered since the time the export was taken
will be lost and must be entered by the user. If the entire database must be recovered from an export, the DBA
will recreate an empty database and then import the data from the export file. The recovery of objects from an
export of any database will be done upon request from the technical managers or in the event of media failure.
5.3 PERFORMANCE TUNING
The DBAs are responsible for tuning the database parameters for performance enhancements. Changes to
performance are typically added or modified to the init.ora file of the database. If a production database needs
tuning, the DBA will perform any changes to the init.ora file during the Sunday maintenance window. Any
changes made to this file will require the database being shutdown and restarted for the change to take place. If
the database is not a production database, the shutdown/startup of the database will be coordinated with the
technical managers, so to allow minimal disruption during the business day.
5.4 MAINTENANCE AND MANAGEMENT
The Database Administration group will maintain and manage all PeopleSoft databases. Maintenance to the
production databases is strictly limited to the Sunday maintenance window. Other non-production databases may
be performed during business hours with the approval of the technical managers.
Version 7.1
120
Enterprise Systems - UHS
Page 18 of
PeopleSoft Application Development Standards
6. PATCHES, UPGRADES, AND CUSTOMIZATION
PeopleSoft applies updates its applications via a series of patches or maintenance packs. The modifications can be
made via PeopleTools updates, application patches and fixes, or application version upgrades.
6.1 LOCATION AND NAMING CONVENTION
6.1.1 Directory Structure
Documentation for Application Patches, Maintenance Packs, Bundles, Regulatory Releases, and PeopleTools will
be downloaded from Oracle Customer Connection into the following directory structure.
P:Documentation
PS_Upgrade
FS
FSxxx (Where xxx is the PS application version number, FS84)
SA
SAxxx (Where xxx is the PS application version number, SA89)
PS_Patches
FS
nnn-xxxxxxxx (where nnn is a sequential number 001, 002, etc.; and xxxxxx is a description of the
patch)
SA
nnn-xxxxxxxx (where nnn is a sequential number 001, 002, etc.; and xxxxxx is a description of the
patch)
PS_PTools
FS
PTvxxxx (where v is the version number and xxxxx is the release number, i.e. PT84619)
SA
PTvxxxx (where v is the version number and xxxxx is the release number, i.e. PT84619)
PS_Archive
PS_Upgrade
FS
FSxxx (Where xxx is the PS application version number, FS84)
SA
SAxxx (Where xxx is the PS application version number, SA89)
PS_PTools
FS
PTvxxxx (where v is the version number and xxxxx is the release number, i.e. PT84619)
SA
PTvxxxx (where v is the version number and xxxxx is the release number, i.e. PT84619)
PS_Patches
FS
mtp_mmddyyyy (this is the date the application patches went into production)
SA
mtp_mmddyyyy (this is the date the application patches went into production)
6.1.2 Patch Set Reports
In addition to the PeopleSoft delivered documentation, the following reports will be created by the DBA and
placed in the appropriate documentation directory before patches are applied to the target database.

Compare Reports identify changes between the source (demo) database and the target (development)
database. Application developers are responsible for reviewing compare reports.
Version 7.1
120
Enterprise Systems - UHS
Page 19 of
PeopleSoft Application Development Standards

Internal Object Compare Report is a spreadsheet created by the DBA by running sql after the Compare
Reports have been created. The SQL uses tables updated by the compare reports to indicate objects that
were changed. Application developers are responsible for reviewing the Internal Object Compare Report.

The SYSAUDIT report is an audit report of discrepancies between PeopleSoft and Oracle system tables.
The SYSAUDIT report is created only when installing maintenance packs.

The DDDAUDIT report is an audit report of discrepancies between PeopleSoft and Oracle application
tables, views, and indexes. The DDDAUDIT report is created only when installing maintenance packs.
6.2 PEOPLETOOLS
PeopleSoft releases upgrades to PeopleTools approximately every quarter. A PeopleTools upgrade usually
involves changing the structure of PeopleTools tables. As of version 8, there are Tools structural changes with
each minor Tools release.
The release numbering scheme is identified as follows: 8.19.12 or 8.42.13
The first digit represents the version of application and tools software you are on. The second two digits represent
the major version of tools and the last two digits represent the minor release or patch level of tools. Minor changes
are released more often in response to urgent fixes that come from PeopleSoft. The PeopleTools upgrade is
installed by the DBA staff. All major upgrades must be downloaded from the PeopleSoft website. They also send
cd package with the software updates on it. All documentation can be downloaded from PeopleSoft’s Customer
Connection web site. Minor releases of the upgrade can be downloaded as well from this web site along with the
corresponding documentation.
The following steps are performed by the DBA staff, however, it is important for the Application Managers to
become familiar with the preparation phase of the upgrade and understand the fixes and enhancements that will be
available with the upgrade.
6.2.1. PREPARATION
Application Managers will give the approval to load PeopleTools from the Demo to Dev to Test and then to the
Production environment, performing testing along the way. They will also determine the schedule in which it will
move from database to database.
A PeopleTools upgrade will require the application servers, process schedulers and web servers to be brought
down, reconfigured and/or recreated to incorporate the changes. The COBOL programs will need to be
recompiled as well. The DBA staff is responsible for these tasks.
Once the upgrade has been completed, the Application Managers are notified.
6.3 PATCHES AND FIXES
This section addresses how patches and fixes are applied to the three primary applications (finance, student
administration, and human resources).
For the purpose of this document, the word “patches” shall refer to PeopleSoft issued patches, bundles, tax
updates, regs releases, and maintenance packs.
The normal migration path is
PeopleSoft  demo database  development database  test database  production database.
The process flow for applying patches to PeopleSoft is:
Version 7.1
120
Enterprise Systems - UHS
Page 20 of
PeopleSoft Application Development Standards
DBA
DBA
DBA
DBA
Developers
Developers
DBA
Functional Users
DBA
Determine which patches to download and builds patch set spreadsheet.
Download patch set, bundle, maintenance pack to the demo database.
Create audit and compare reports sends out to developers for review
Migrate patches to development database. Compile COBOL.
Reapply customizations to PeopleSoft delivered objects.
Perform unit tests.
Migrate patches to test database.
Perform system and integration tests.
Migrate patches to production database.
Database Administrators will maintain a procedure manual for installation of patches and upgrades.
PeopleSoft application patches are downloaded every 2 – 3 months from the PeopleSoft web site for Finance,
Student Administration, Human Resources, and PeopleTools.
The DBA team applies the patches. The DBA analyst applying patches should be familiar with PeopleSoft
Application Designer, Data Mover, SQL+, COBOL compiler tools, and Oracle, Unix and NT environments. It is
recommended that database administrators applying patches complete PeopleTools I and Data Management /
Upgrade classes offered by PeopleSoft.
6.3.1. PeopleSoft Patches
PeopleSoft patches must be extracted from PeopleSoft Customer Connection. Search criteria for the various
applications and modules are presented in Appendix D.
6.3.2 PS Maintenance Schedule
The application managers determine the PS Maintenance Schedule. The DBAs will work from the PS
Maintenance Schedule to determine download dates, apply to demo database and deliver compare reports dates.
Each phase of the patch set move requires application manager notification. Occasionally, business process dates
will conflict with a patch set making it to production in a timely manner and the schedule slides a bit. Business
processes could cause the schedule to slide. All schedule conflicts must go through the application managers.
6.3.4 Testing & Retrofitting a Patch set
After patches have migrated to the target database, the technical support manager should be notified via email.
Application developers can begin reapplying customizations and unit testing. CSRs are created for application
developers to document and migrate retrofits.
6.3.5 Patch set Migrations
Once the application manager approves the migration of the patches to the target database, the DBA will perform
the move. An email will be sent to the DBA listserv after the move is completed. Patch migrations to the target
database will occur during the Sunday maintenance, after hours, or during the day. Patch set migrations to the
production database will occur during the Sunday maintenance window.
In addition to the migration request, the DBA manager must complete a change notification form and present to
the Change Management Committee.
6.4 CUSTOMIZATIONS
6.4.1 Internal Objects
A patch set or application release will often modify PeopleSoft internal objects. As such customizations made to
PeopleSoft delivered objects will be lost and must be reapplied by the application developer. To manage this, two
tools are available to developers:
1. Compare Report
2. Objects Spreadsheet
Version 7.1
120
Enterprise Systems - UHS
Page 21 of
PeopleSoft Application Development Standards
Compare Reports
Compare reports identify which internal objects were changed by PeopleSoft by comparing a source (demo)
database and a target (development) database. These reports identify detailed changes to PeopleSoft internal
objects and should be carefully reviewed before applying patches to the development database. Application
developers are responsible for reviewing compare reports.
Objects Spreadsheet
After the compare reports are created, the DBAs will run a SQL process to create an objects spreadsheet. This
SQL uses compare report tables. The DBAs will also enter external objects that need to be retrofitted. The
spreadsheet can be filtered for objects changed, the last person to update that object, etc.
After patch sets are migrated to the development database, application developers may begin the retrofit process of
reapplying customizations and testing. At this point, it is only necessary to conduct unit testing. Full testing will
be conducted by functional users after the patch set migrates to the test environment.
Developers should place any internal or external objects they retrofit into a CSR within STAT.
6.4.1 Previous Versions
When DBAs install a maintenance pack, they will copy the current SAnnDEV/USER directory to
SAnnDEV/USER_OLD and copy SAnnDEV/USER_OLD TO SAnnDEV_USER_OLDER. The
SAnnDEV/USER directory will be refreshed from SAPRD. The old directories are for reference only or could be
used to bring custom process in progress back to the SAnnDEV/USER directory.
Note: PeopleSoft delivered objects that were modified should not be copied back from old directories. The
objects should be retrofitted instead.
6.4.2 Crystal, nVision, MicroSoft Word Objects
The DBA will copy Crystal Reports, nVision, and WinWord objects directly into the /user directories on the
database source code tree. If any of these objects have been customized, developers should refer to previous
versions and reapply customizations.
6.4.3 Unit Testing
Unit testing of internal and external objects in the patch set or application release is conducted in the development
environment by the application developers. Unit testing ensures that the object will execute and desired outputs
are produced. Debugging and verification of output results are performed by the developer. When unit testing has
completed, the patch set can migrate to test.
6.4.4 System Testing
System testing is performed by functional users and key functional users in the test environment. System testing
includes testing of complete processes including upstream and downstream processes as applicable. System
testing may also include integration testing between two or more applications and load testing to verify that the
hardware and network infrastructure can support the changes being made.
Version 7.1
120
Enterprise Systems - UHS
Page 22 of
PeopleSoft Application Development Standards
7. SOFTWARE QUALITY ASSURANCE
7.1 APPLICATION DEVELOPMENT LIFE CYCLE
Software Quality Assurance (SQA) application development life cycle is illustrated in the following diagram:
Request for
Enhancement/
Modificatiion
Analysis &
Design
Functional lead submits request for enhancement
or modification to tech appl mgr.
Analysis and design specs are
developed.
Coding
Developer writes / modifys code.
Unit Test
Developer tests program module.
Migrate to
test
Developer initiates request to migrate to
test environment
Functional
Testing
(process,
system)
Functional analysts/users perform unit,
process, integration, and system tests.
Migrate to
production
Production
Verification
Developer initiates request
to migrate to production
Developer verifiies migration worked successfully.
Email is sent to functional lead/security
administrator to update menu security.
This process is managed by a product from Quest called STAT. All Change Service Requests (CSR) are routed
through STAT. STAT is self-documenting. It will record change requests, track the change service request (CSR)
as it moved through the stages, and provides necessary approvals from functional and technical managers before
final migration to production. STAT also provides version control for PeopleSoft internal objects such as pages,
components, records, etc. and external objects such as SQRs, COBOL, etc.
Version 7.1
120
Enterprise Systems - UHS
Page 23 of
PeopleSoft Application Development Standards
Training for functional and technical staff is required before using STAT. This document is not intended to be a
training document for STAT but will provide basic information at the conceptual level.
7.2 APPLICATION CHANGE MANAGEMENT
PeopleSoft Application Change Management procedures provide a common development and implementation
path for all changes. These procedures explain the many stages a change may go through from its inception to
final implementation.
The steps of the Change Control Process are provided below:
7.2.1 Initiating a Customer Service Request
Approved Functional Managers or technical support staff member can propose a change to the system and enter
the request into STAT. Original requests may come in various forms such as email, verbal, screen prints, etc.,
however, each request must be entered into STAT by either the functional analyst, manager, or technical support
staff.
All requests for development work should provide detailed functional specs. This should be documented within
STAT either in the description area or by adding it as an attachment.
STAT does allow attachment of files for further documentation or specs as required.
STAT Change Management Request Page
Version 7.1
120
Enterprise Systems - UHS
Page 24 of
PeopleSoft Application Development Standards
Version 7.1
120
Enterprise Systems - UHS
Page 25 of
PeopleSoft Application Development Standards
Upon completing the initial CSR, the requestor must enter a UserId before they can save the page. The UserId
defaults to the technical managers supporting that application. Upon saving the page, an email will be sent to the
customer and to the technical manager notifying them that a request has been entered into STAT.
7.2.2 STAT Workflow
Once the CSR has been created, STAT will create a workflow to manage movement of the CSR and attached
objects. Only the person to whom the CSR is assigned or a manager can update the CSR and move it to the next
step in the workflow.
Version 7.1
120
Enterprise Systems - UHS
Page 26 of
PeopleSoft Application Development Standards
STAT Workflow
In the example above, the CSR is in “Accepted” status waiting to be moved to “Development” and assigned to a
developer. As the CSR moves to various statuses, the CSR will be assigned to the next person who is to perform
that activity. If approvals are required, STAT will restrict movement of the CSR to the next status until the
approvals are made electronically within STAT.
7.2.3 Initial Approvals
The E. S. Technical Applications Manager is responsible for reviewing the request and deciding which action must
be taken. The request may be denied, placed on hold, moved to an “Accepted” status waiting for reassignment to a
developer, or moved to “Development” status and assigned to a developer.
The E. S. Technical Applications Manager determines if the request has received approval from the Application
Advisory/Leadership Group or their designee. All requests for processes to access, retrieve, or update data on
production databases require the approval the Application Advisory/Leadership Group. The E. S. Technical
Applications Manager is responsible for managing the work and priorities of his staff subject to priorities set by
the Application Advisory/Leadership Group.
7.2.4 Approval by the Application Advisory/Leadership Group
There are three Application Advisory/Leadership Groups representing Human Resource Management System,
Financials, and Student Academics and Administration. Each Application Advisory/Leadership Group shall define
its own procedures for how requests will be approved internally by the Application Advisory/Leadership Group.
The E. S. Technical Manager or the Application Functional Lead will determine whether a request must be
presented to the Application Advisory/Leadership Group for clarification and/or approval.
Version 7.1
120
Enterprise Systems - UHS
Page 27 of
PeopleSoft Application Development Standards
Note: A suitable notification to Application Advisory/Leadership Group would be a group e-mail referencing the
identification number of the Development Request. Whenever possible, that e-mail notification should be made at
least 24 hours prior to the meeting so that the team members have a chance to review and print out any relevant
information. As a practical matter, the Requestor should also confirm that especially relevant team members have
received notification and that they have any necessary documentation.
The E. S. Technical Application Manager is responsible for presenting material requests to the respective
Application Advisory/Leadership Group. Specifically included in the review are areas affected by the change and
the request's priority and tentative implementation schedule. The Application Advisory/Leadership group may
take any of the following actions:




Approve the development request
Refer the development request to the Executive Management Committee for approval
Refer the development request to the Technical Application Manager for more information or for impact and
cost analysis
Deny the request
The Technical Application Manager is responsible for communicating the status of the request to the requestor.
7.2.5 Approval By The Executive Committee
The Application Advisory/Leadership Group is accountable to the Executive Management Committee and as such
shall determine which requests require approval by the Executive Management Committee. Such referrals may be
based on political, policy, environmental, functional application processes, or cost considerations.
7.2.6 Migrate From Production To Development
The E. S. Technical Application Manager may be required to develop an impact or cost analysis of the request
before any further work is completed. The CSR should be moved to “Hold” status until such analysis is complete.
When development work is ready to begin, the E. S. Technical Application Manager will move the CSR to
“Development” and assign the CSR to a developer via STAT workflow. STAT will send an email notification to
the developer. Once the Development Request is approved, the technical manager or application developer will
develop technical specifications, a test plan, and identify which objects, tables, or files will require modification.
STAT provides the ability for an application developer to attach a PeopleSoft object to the CSR and “lock out”
other CSRs from using this object. This lockout occurs only within STAT.
NOTE: Although objects are locked in STAT, this only prevents another developer from migrating those
objects via STAT.
There is nothing to prevent a developer from modifying objects locked by another developer in STAT.
This practice is not approved or encouraged.
Developers should lock objects in STAT before modification begins to prevent other developers from
migrating objects they are working on.
STAT will copy the production objects to be modified to development environment to ensure they are working on
a current production copy.
Version 7.1
120
Enterprise Systems - UHS
Page 28 of
PeopleSoft Application Development Standards
STAT Change Management Version Control
STAT migrations are a 2-step process:
1. The object is copied from the source database to a STAT archive database.
2. The object is copied from the STAT archive database to the target database.
Version 7.1
120
Enterprise Systems - UHS
Page 29 of
PeopleSoft Application Development Standards
If a developer needs to move a previous version of what they have modified to the target database, they simply
migrate from appropriate archive set to the target database.
The STAT Baseline Set is a copy of the objects from the production database prior to making any modifications.
The baseline set is stored in the STAT archive database and copied to the development environment.
When the objects are moved to production and the original version needs to be restored, the baseline archive set
can be used to move the objects back to production, HOWEVER, this must be done before the DBAs move the
CSR to a completed status which removes the objects from the CSR and releases the lock.
NOTE: Once the CSR is closed and the locks on the objects released, it is not possible to install previous
versions of the objects via STAT.
7.2.7 Development Activity
The development activity begins with analysis and design by the application developer. After the technical
specifications are completed, the application developer begins development activities, such as coding and testing,
following the standards contained within this document.
During the development phase, the application developer is responsible for:
 Development of the technical specifications
 Programming activities – coding, debugging, and testing
 Performing unit testing
 Initiating a development walkthrough / technical review of the change with the requestor. (Reference Chapter
7.6)
In some cases the application developer will perform some of these tasks with the assistance of the functional
users.
7.2.8 Migration to Test Environment
Migrations to the test environment is a 2-step process performed within STAT by the developer.
1. Migrate PeopleSoft objects from development database to the test database
2. Move the CSR via workflow to “Test” status and reassigning the CSR to the functional analyst who will
conduct the testing. STAT will automatically send email notification to the functional analyst that the
CSR has been reassigned to them.
Application Developers should not have access to make menu security changes in test or production environments.
Application Developers should not be able to run update SQL in test or production environments. DBAs can run
SQL if instructed to do so within the CSR.
NOTE: Do not have Application Designer open when migrating objects in STAT. Application Designer will
automatically add objects to a project you have open in STAT. The developer would unknowingly migrate
objects that do not belong to the project and have been modified and possibly untested.
After completing unit and/or system testing, the functional analyst can perform two actions
1. Return the CSR to the developer for further modifications
2. Approve the CSR to be moved to production and move the CSR to “Manager Approval” status.
7.2.9 User Acceptance Testing
The test database is the standard default test database for functional users. The sandbox database, which is
refreshed weekly, may be used for unit, system, or user acceptance testing because the test environment does not
contain the complete production environment data set. There are 2 additional databases, DC1 and DC2, which can
be used for testing time sensitive processes. The dates can be changed on the servers supporting these databases.
Version 7.1
120
Enterprise Systems - UHS
Page 30 of
PeopleSoft Application Development Standards
System and integration testing are conducted at this point. Functional users are responsible for developing a test
team and conducting user acceptance testing in the test environment. Key functional users will provide the test
team with the test plan and scripts to be used during the user acceptance test. The testing team may supplement
these test plans and scripts with standard and/or specific tests relevant to the change. If additional changes are
required, they are returned to the application developer for rework in development, at which point the process of
migrating to the test environment must repeat itself.
The following tests should be considered and/or conducted:
 Complete system testing of the application processes and
 Complete system testing of application interfaces to other applications or external applications.
 Complete system testing of voice and data networks
 Load testing
User acceptance testing should be completed prior to approving the CSR and moving it to “Manager Approval”
status.
7.2.10 Migration to Production
Once the CSR is in “Manager Approval” status, the E. S. Technical Application Manager can approve the CSR
and move the CSR to “Move To Production” status. Email notice is automatically sent to all DBAs via STAT to
indicate that the CSR is ready to migrate. Final migrations are performed within STAT by a DBA.
After the objects have been migrated, the DBA will route the CSR either to security for menu security updates or
to a “Completion” status. An email notification will be sent to the customer and the E. S. Technical Applications
Manager when the CSR status is completed.
A completion status will remove the locks on PeopleSoft objects attached to the CSR.
The following matrix identifies the 2 types of migrations and when they can occur.
Normal Migration
Type I External Objects can migrate at any time.
Extra approval not required.
Emergency Migration
Type I External Objects can migrate at any time.
Extra approval not required
Type II. Internal Objects will migrate on Tue. & Thr.
after 7 p.m and before 7 a.m. on the following day
and on Sun. during the Sunday maintenance window.
All app servers will be brought down prior to
migrating objects and then brought back up.
No extra approvals required.
Type II. Internal Objects will migrate on after 7 p.m
and before 7 a.m. on the following day. All app
servers will be brought down prior to migrating
objects and then brought back up.
Requires approval from two technical managers.
n/a
Type II. In extreme emergencies, Internal Objects
may migrate during business hours. All app servers
will be brought down prior to migrating objects and
then brought back up.
Requires approval from the Associate Vice President
of Enterprise Systems
Functional users may designate a request as an emergency. Within STAT, this is done by setting the customer
priority to “Urgent”. The process for moving the CSR and migrating objects for emergency CSRS is no different
than regular CSRs. The process is simply expedited.
NOTE: DBAs should not perform emergency migrations until two technical manager approvals have been
received.
Version 7.1
120
Enterprise Systems - UHS
Page 31 of
PeopleSoft Application Development Standards
Emergency migrations should be avoided if at all possible because the application server services may be restarted
which results in temporary unavailability of the application or application server cache may need to be rebuilt.
Emergency changes should not violate the integrity or the intent of change control processes.
The E. S. Technical Manager is responsible for notifying his superior and peers that an emergency migration that
will cause a disruption of service is about to occur. The E. S. Technical Managers that will be affected by the
migration are responsible for contacting key functional personnel providing the time disruption is expected to
occur and for how long. Email notification is sufficient, however, the technical manager may want to provide a
verbal notification as well.
7.2.11 Failed Migrations To Production
Occasionally, it is not possible for the DBA to migrate objects to production. This could because the objects are
not locked in STAT, unclear instructions within the CSR, etc.
Application developers are required to enter their home phone and cell phone in the description area of the CSR
before moving the CSR out of development.
In the event the DBAs are unable to migrate a CSR, they shall immediately call the application developer to notify
them of the problem. If necessary, the DBAs will return the CSR to the developer.
Application developers may indicate in the description area of the CSR that the CSR is not critical and they should
not be called.
7.2.12 Special Instructions for WinWord Migrations
Only users in the PS-Dev-WinWord and PS-Dev-DBA Windows access groups have access to write to
P:\SAnnTST\Winword and P:\SAnnTST\user\winword directories. This was introduced to allow campus student
administration staff to make minor modifications to their letters and put into the production environment directly,
without DBA assistance. Secured users will test their modifications in P:\SAnnTST\winword directory and run
against the SAnnTST database, and once they are ready to move the letter to production, they copy it
to p:\SAnnTST\user\winword. P:\SAnnTST\user\winword is replicated hourly to the production code tree.
Developers do have access to p:\SAnnDEV\winword and p:\SAnnDEV\user\winword directories. When running
WinWord from a PeopleSoft panel/process, the WinWord document must reside in the \WinWord directory and
NOT in \user\WinWord. \user\WinWord is used to keep a copy for reference and maintain consistency with the
development environment (i.e. keep all the modified codes in \user\..... directory).
Because users can modify the letter (in the SAnnTST code tree), the latest version should be copied from
SAPRD/WinWord before modifying the letter.
7.2.13 STAT Documentation
CSRs can easily be viewed through status and through various filters including CSR status and assignment queue.
This allows functional managers, technical managers, and developers to research previously completed CSRs.
STAT also provides a variety of canned reports.
Version 7.1
120
Enterprise Systems - UHS
Page 32 of
PeopleSoft Application Development Standards
STAT Console
Version 7.1
120
Enterprise Systems - UHS
Page 33 of
PeopleSoft Application Development Standards
STAT also maintains a history of anyone who made changes to the CSR.
STAT History Page
Version 7.1
120
Enterprise Systems - UHS
Page 34 of
PeopleSoft Application Development Standards
8. PROGRAMMING STANDARDS
8.1 TRAINING REQUIREMENTS
Minimum technical training requirements for entry level application developers is SQL, SQR, Query, PeopleTools
I. Additional technical training may include PeopleTools II, PeopleCode, application engine, component interface,
application messaging.
8.2 ONLINE PROGRAMMING
8.2.1 Page Design
Windows GUI and HTML standards will be applied in the development of page design. PeopleSoft Application
Designer is the development tool and automatically invokes these standards.
As a matter of convenience for the user, a page should be no longer than 3 scroll clicks (by clicking in the middle
of the scroll bar.)
When a panel or page displays multiple rows that are effective dated, the rows should be sorted in effective date
descending order to present the most recent effective dated rows first.
8.2.2 Response Time
Screen fields should be arranged and assigned display attributes in order to reduce both the user response time and
the computer response time:
 Reduce learning curve for new users. If fields that serve the same purpose are always placed in the same
location on screens, the inexperienced user will know where to look on a new screen.
 Reduce eye-movement for the experienced user. The natural flow of a screen should be in the order users
expect for text, which is left to right, top to bottom. If fields that serve the same purpose are always put in the
same place, the user's eye can move straight to them rather than searching the screen. In addition, if the user
can anticipate where the first "important" field will be before a screen appears, the eye can be focused on the
appropriate spot while the screen is changing.
 Reduce eyestrain. The screen should be uncluttered, and arranged in columns which the eye can easily follow.
8.2.3 Pages
Avoid renaming an original page as PEOPLECODE may be referencing the page. Never delete a field from a
delivered or existing page. If the field is not desired, make the field invisible. Removing fields may affect
functionality on this or another page.
Key fields on a page should always be DISPLAY ONLY.
Check boxes should be used for YES/NO fields.
Only use radio buttons for a translate field if the translate values are absolutely static.
Related Display fields should be used where appropriate. (ex. DEPTID, BUSINESS_UNIT …).
The page should be organized in a manner consistent with the flow of data as well as being as intuitive as possible
for the user. If the page is to be primarily used for data entry, the field layout should coincide with the order that
the information is obtained by the user. If the source of data is a report or form, the page layout should match that
of the source.
The tab order of the fields on the page should flow logically with the layout of the fields on the page.
All custom pages should be prefixed with UHS_.
8.2.4 Menus
Never delete a delivered menu. If the menu is not desired, use operator security to hide the menus from
all operator id’s and operator classes.
PeopleSoft delivered menus should not be modified. UHS custom menus should be used.
Version 7.1
120
Enterprise Systems - UHS
Page 35 of
PeopleSoft Application Development Standards
Menus should be organized logically according to the menu group it is in and the nature of the
application. If there are several components associated with an application, those components should be
grouped together.
Menu Labels should be in Mixed Case.
Menu item names should be descriptive of the process so that they are easily identifiable in security administrator.
8.2.5 Mixed Case
Mixed case text is easier to read. All new applications should use mixed case for non-variable text, such as
column headings and labels, unless the text is a mnemonic or an acronym. Decisions regarding case on existing
applications should be made in the manner that is the least disruptive to the user. If a new screen is
added to an application that employs upper case, factors such as the overall aesthetic effect of the mixture, as well
as the likelihood that the remaining screens will be revised in the near future, should be considered. No single
screen should use both mixed case and upper case for label and column headings. In addition, screens should
provide for the input of mixed case data where appropriate -- for example, descriptive text that is not used for a
search.
8.3 PEOPLECODE
8.3.1 Coding Standards
PeopleCode is commonly used to customize PeopleSoft. Code should be commented to facilitate the maintenance
of PeopleCode. These comments are critical when PeopleSoft patches are installed.
When PeopleCode is written, the editor enforces the structure of the code. For discussions on writing PeopleCode
see the PeopleCode Class Manual and the PeopleCode PeopleBooks. The use of the FieldFormula event is
primarily used to store functions. Because code in this event always processes, it should only be used for function
libraries and web libraries.
8.3.2 Code Documentation
The application developer is responsible for code level comments in all cases. Commenting rules are as follows:




Comments need to be included with all coding tasks, such as new development,
enhancements/modifications and bug fixes. (Example 1)
Included in all comments should be a “UHS” tag, CSR#, date of modification/creation, developer name,
and explanation/background of the new/modified code. (Example 1)
Code should be broken up into logical blocks, and at each major step in the application logic a new
comment should be created. When the block is complete an end comment should be created.
When code is changed, the original code needs to be commented out and replaced with the updated
code. To make it easier to identify, the commented code needs to be above the modified code. To
provide future reference, do not delete the old code. (Example 2)
Example 1 (Adding the starting and ending comments )
Original Code
If %PanelGroup = "MAINTAIN_PO_CF" Then
&AMTVCHR = PO_Vchr_Amt_Active(PO_LINE_FS.BUSINESS_UNIT,
PO_LINE_FS.PO_ID, PO_LINE_FS.LINE_NBR, 0, 0);
End-If;
UHS Modified Code:
If %PanelGroup = "MAINTAIN_PO_CF" Then
/* UHS, CSR-1234,03/01/2002, Start, FSnnnnn, <developer name here> */
/* Description of the change being made. */
Version 7.1
120
Enterprise Systems - UHS
Page 36 of
PeopleSoft Application Development Standards
/* &AMTVCHR = PO_Vchr_Amt_Active(PO_LINE_FS.BUSINESS_UNIT,
PO_LINE_FS.PO_ID, PO_LINE_FS.LINE_NBR, 0, 0);*/
&AMTVCHR = PO_Vchr_Amt_Active(PO_LINE_DISTRIB.BUSINESS_UNIT,
PO_LINE_DISTRIB.PO_ID, PO_LINE_DISTRIB.LINE_NBR, PO_LINE_DISTRIB.SCHED_NBR,
PO_LINE_DISTRIB.DISTRIB_LINE_NUM);
/* UHS, 03/01/2002, End */
End-If;
Example 2 ( Commenting out existing code and adding custom code)
Original Code:
If %PanelGroup = "MAINTAIN_PO_CF" Then
&AMTVCHR = PO_Vchr_Amt_Active(PO_LINE_FS.BUSINESS_UNIT,
PO_LINE_FS.PO_ID, PO_LINE_FS.LINE_NBR, 0, 0);
End-If;
UHS Modified Code:
If %PanelGroup = "MAINTAIN_PO_CF" Then
/* UHS, CSR-1234,03/01/2002, Start, FSnnnnn, <developer name here> */
/* Description of the change being made. */
/* &AMTVCHR = PO_Vchr_Amt_Active(PO_LINE_FS.BUSINESS_UNIT,
PO_LINE_FS.PO_ID, PO_LINE_FS.LINE_NBR, 0, 0);*/
&AMTVCHR = PO_Vchr_Amt_Active(PO_LINE_DISTRIB.BUSINESS_UNIT,
PO_LINE_DISTRIB.PO_ID, PO_LINE_DISTRIB.LINE_NBR,
PO_LINE_DISTRIB.SCHED_NBR, PO_LINE_DISTRIB.DISTRIB_LINE_NUM);
/* UHS, 03/01/2002, End */
End-If;
Version 7.1
120
Enterprise Systems - UHS
Page 37 of
PeopleSoft Application Development Standards
8.4 APPLICATION ENGINE
Application Engine allows comments to be added to the step using a right click. Comments should be used to
indicate changes made, CSR#, date, and developer.
PeopleCode and SQL coding conventions should be followed when placed within an App Engine program.
8.5 REPORTING OPTIONS
The Process Scheduler Distribution Agent transfers all system generated files to the Report Repository when a
process completes. Code must be written if a file or spreadsheet is created and needs to be placed in the Report
Repository. The Report Repository is where process output resides. Reports or log files can be viewed from either
Report Manager or Process Monitor when they are in the Report Repository. Files transferred to the Report
Repository can include reports, logs, and trace files.
PeopleSoft Query
Crystal Reports
Version 7.1
120
PeopleSoft Query is the backbone for Crystal, nVision, and Excel. All
reported information, whether it is an online report, a listing in a grid control,
or a customized report using Crystal, uses PeopleSoft Query to gather the
data. Although PeopleSoft Query can be used independently to run queries
for immediate viewing, it also serves as the link between the data stored in
PeopleSoft tables and all other reporting tools.
Crystal Reports is a third-party report designer from Seagate Software.
Queries created in PeopleSoft are used to create customized reports, forms,
mailing labels, and more. This tool, which extracts real-time data from
PeopleSoft, provides great flexibility in terms of layout, organization, and
design. Crystal Reports is ideal for reports used in presentations or
meetings.
Enterprise Systems - UHS
Page 38 of
PeopleSoft Application Development Standards
Microsoft Excel
PeopleSoft nVision
SQR (Structured Query
Report Writer)
Queries created in PeopleSoft can be directly sent to Microsoft Excel. By
running queries to a spreadsheet, you can manipulate the data using the
features and formulas available with Microsoft Excel.
You would typically choose this reporting option if you do not have
PS/nVision and want to use the data for analysis purposes.
PeopleSoft nVision enables you to create business reports in Microsoft
Excel. This tool allows you to include an aggregate value from a selected
query in your report. Through PS/nVision, you control how the report looks
by designing the layout and format of the report.
This reporting tool is commonly used to build summary reports using
aggregate functions such as Sum or Average, when you want to create charts
or graphs, and with mail merge documents.
SQR is a very powerful and complex reporting option but also has the ability
to manipulate data and tables. SQR reports are generated by application
developers. In most cases, one of the other reporting options explained
would provide the information that you need.
Reporting Tools General Criteria
Max Number of Tables
SQR
Unlimited or
requires
multiple
selects
9
nVision
Unlimited
Process
scheduler time
limit
9
Process
Scheduler time
limit
Excel Limit
Unix Server
or
NT Server
4
2
No
Yes
Yes
Defined by
program.
Report
output
defined by
Process
scheduler.
NT Server
2
4
Yes
No
Yes
.LIS, RPT, PDF
Report output
defined by
Process
scheduler.
NT Server
3
4
Yes
Yes
Yes
.XLS, PDF
Report output
defined by
Process
scheduler.
Rows returned
Server
Complexity of reporting *
Speed of process **
Drilldown
Excel Format
Charts & Graphs
Extension
Crystal
PS Query
9
(6 is the UHS
recommended
limit)
App server time
limit
App Server
(Unix)
1
1
No
Yes
No
N/a
* Complexity: 1 (Easy) - 4 (Complex)
** Speed: 1 (Fast) - 4 (Slow)
Version 7.1
120
Enterprise Systems - UHS
Page 39 of
PeopleSoft Application Development Standards
8.6 SQR
SQR (Structured Query ReportWriter) is delivered with the PeopleSoft system. SQR is usually the tool of choice
for complex batch reports and processes. Additionally, PeopleSoft delivers various listing reports that detail the
contents of a given table such as the valid value for fields.
Note that SQRs can be executed from within the PeopleSoft on-line environment via the Process Scheduler. The
output will be written to the report repository directory.
8.6.1 SQR Programming Standards
When vanilla reports require customization, the SQR should be copied and placed in the user/sqr directory where
modifications are made.
Except where changes are minimal, new programs should be created rather than modifying delivered vanilla
programs using the standard naming convention contained within this document.
In order to ease portability you should resist using platform-specific SQL functions/expressions, where possible.
8.6.2 SQR Performance Optimization
The performance of an SQR program is greatly affected by the performance of the SQL used in the program. The
main SQL paragraph should contain the maximum number of joins necessary to obtain the primary data as
opposed to having a fewer number of joins and calling subroutines to perform additional selects that could be
accomplished in the original select.
Other methods of enhancing performance include creation of additional indexes on the tables involved and the use
of Oracle hints. Many tools, including SQL Expert, allow you to obtain the Oracle plan of execution for the SQL
being performed. The plan of execution determines and demonstrates the efficiency of the SQL being executed.
8.6.3 SQR Modularity
Procedures should be coded in the order
Begin-Setup
Begin-Program (Note: Begin-Report has been replaced with Begin-Program)
do Init-DateTime
do Init-Number
do Get-Current-DateTime
do Init-Report
do Process-Main
do Reset
do Stdapi-Term
End-Program
Begin-Heading
Begin-Footing
Begin-Procedure Process-Main
Begin-Procedure xxxxx (called from Process-Main or other procedures)
….
(Continuing from highest to lowest level)
….
….
8.6.4 SQR Program Structure
Procedures local to the SQR should appear in a logical order.
SQR files must have an extension of .sqr while external procedures are stored in files with an extension of .sqc.
Version 7.1
120
Enterprise Systems - UHS
Page 40 of
PeopleSoft Application Development Standards
The UHS standard headings and standard trailers should be used within UHS custom SQR programs.
following SQCs should be used for standard report titles and headings.
The
SA
UHSHDG001 Report by business unit for month ending
HR
UHSHDG001 Report by business unit for month ending
UHSHDG002 Standard heading with business unit & dept name optional
UHSHDG003 Uses UHSHDG002 with AsOfDate included
FS
UHSFSHDG01 Standard Heading
UHSFSHDG02 Uses UHSFSHDG01 with business unit
8.6.5 Interaction With The PeopleSoft Application
SQR programs must always be Application Process Interface (API) aware in order to properly update the
PeopleSoft Process Scheduler. The PeopleSoft delivered procedure STDAPI-Init is called to initialize parameter
values. STDAPI-Term performs end of report processing.
do Init-Number
do Init-DateTime
do Get-Current-DateTime
do Stdapi-Init
do Init-Report
do Process-Main
do Stdapi-Term
If the SQR encounters an error condition, the process status must be updated in order for the Process Scheduler to
recognize the error and for the Process Monitor to display the correct status. An example would be as:
If {error condition}
ROLLBACK
Let $Msg = 'Invalid … - Abort'
SHOW $Msg
If #prcs_process_instance > 0
Let #prcs_run_status = #prcs_run_status_error
Let $prcs_message_parm1 = $Msg
If $prcs_in_update_prcs_run_stat <> 'Y'
Do Update-Prcs-Run-Status (this procedure has a commit coded within it. This will commit all
updates unless a rollback is performed)
End-if
End-if
STOP
End-If
8.6.6 SQR Include Procedures
SQR include procedures are contained in modules calls SQCs. The PeopleSoft delivered SQC “setenv.sqc” should
be included in all SQRs. It defines database specific parameters. These appear immediately before “beginprogram”. Typically all other include SQCs will appear at the bottom of the SQR and should be in lower case.
All procedures implemented as external reusable program modules should pass all values into and out of the
procedure using parameters. Avoid using global variables in reusable procedures. Reusable procedures that pass
no parameters should be declared LOCAL.
Version 7.1
120
Enterprise Systems - UHS
Page 41 of
PeopleSoft Application Development Standards
Begin-Procedure Report_Data Local
! …
End-Procedure
If a procedure passes parameters, it is considered to be local.
Begin-Procedure Report_Data ($Data_Selection_Param)
!…
End-Procedure
Procedures specific to a program may use global variables, but this practice is recommended only for the
smallest of programs. These procedures should be declared within the program file (not #included).
As UNIX is case-sensitive, all SQCs should be saved using lowercase names to ensure that multiple
copies of the SQC do not exist on the server.
Any "#INCLUDE" needed by a reusable program module should be added to the bottom of the SQR.
8.6.7 SQR Input-Data Verification
If the user is to enter an input and/or output file, the path should not be hard coded. The user should enter the path
as part of the input/output file name.
If input parameters are being specified using a run control record, the input data should be validated by the
procedure that is selecting the parameter data. This enhances modularity and allows improved program
maintenance.
8.6.8 SQR Sorting
Bubble Sort, Insertion Sort and Recursive Sort (QuickSort) are several methods that may be used to sort SQR
internal arrays. Example code for these sorting techniques may be found by searching online SQR sources. An
alternative to sorting internal arrays is to use an operating system command to sort a flat file. The UNIX system
has a command called “sort” (Call System Using ‘sort –t: +3 file1.dat > file2.dat’ #status). This method might be
used as an alternative to accessing the database multiple times just to order the data correctly, as would be the case
with nested SELECT paragraphs.
8.6.9 SQR Database Links
Database links are not the preferred method for retrieving information across databases, however, they can be used
with director approval. The Integration Broker should be used instead. Great care should be exercised when
utilizing DB links, as the program will now be affecting two databases. Code utilizing DB Links should be
carefully crafted to be the most efficient possible.
When running programs with DB Links on the server, it is important to note that the access time allowed to the
link is limited. Currently it is set in the neighborhood of 20 minutes. When selecting from a large table across a
link, provisions for this timeout may have to be made.
See DBA to create or use an existing DB link.
Additional links may be established upon demand to assist developers and functional users in testing processes.
DB links should be utilized dynamically in SQR. The best solution is to populate a table in PeopleSoft with the
environment as the key and the link name as the data. The SQL select can then be built dynamically using this
information.
EXAMPLE
Version 7.1
120
Enterprise Systems - UHS
Page 42 of
PeopleSoft Application Development Standards
Let $FS-DB-Link
= &HFM.UHS_FS_DB_Link
Let $PS-UHS-Cost-Center = 'PS_UHS_COST_CENTER@' || $FS-DB-Link
SELECT ******
From [$PS-UHS-Cost-Center] UCC
8.6.10 SQR Error Handling
When a STOP or STOP QUIET is used to terminate a program with unsuccessful completion, the SQR reserved
variable #return-status must be set to a positive value greater than zero. Care should also be taken not to call
"Successful-eoj" or other cleanup routines that will set #return-status back to zero. Refer to the prior section on
Interaction with the PeopleSoft Application for additional information.
In the code below, the SQR OPEN command issues an instruction to the OS to open a file for writing. By
including the “Status” parameter in the command, the OS will return the success or failure of the command. A
true value indicates a failure. The IF statement evaluates the return and will set variables and call the error code if
failure is true.
Open $Ftpscript as 9 For-Writing Record=250 Status=#OpenStat
If #OpenStat <> 0
Let $Error_Text = Rtrim('Error opening ' || $Ftpscript, ' ')
Let #Ret_code = #OpenStat
Do File_Error
End-If
In the following example a procedure is invoked to update the process monitor in the event of an error. It will
update the process status as well as insert a message as to the nature of the error in the process monitor. This
allows the user to better understand the reason for the error. WARNING - A COMMIT IS ISSUED BY THE
UPDATE-PRCS-RUN-STATUS PROCEDURE! Developer should consider issuing a ROLLBACK prior to
calling this procedure.
ROLLBACK
======= May want to ROLLBACK to prevent unwanted data from being
Committed.
Begin-Procedure File_Error
Show $Error_Text
If #prcs_process_instance > 0
Let #prcs_message_set_nbr = #prcs_msg_set_nbr
Let #prcs_message_nbr = 30 ! Set to blank.
Let #prcs_run_status = #prcs_run_status_error
Let #prcs_rc = #Ret_Code
Let $prcs_message_parm1 = $Error_Text !custom error message
Let #prcs_continuejob = 0
Do Update-Prcs-Run-Status ! in stdapi.sqc ====== ISSUES A COMMIT!
STOP QUIET
End-Procedure File_Error
Version 7.1
120
Enterprise Systems - UHS
Page 43 of
PeopleSoft Application Development Standards
8.6.11 SQR Coding Practices
Never change a program that exists in the PS delivered \sqr directory. This directory should remain untouched and
vanilla. PeopleSoft delivered SQRs which require modification should be moved to the /user/sqr directory in the
code tree.
Avoid using strings to store and manipulate dates. Variables in the SQR date data type are always stored
internally using a 4-digit year.
Dates in string format are required when comparing dates in an If statement or Evaluate statement. Dates should
be in a date format when used in a sql statement (Where clause).
To maintain platform independence, avoid calling operating system commands from within your SQR. Use an
equivalent SQR function instead. If that is not possible, check the $sqr-platform SQR predefined variable and
execute the appropriate operating system commands based on its value.
No line should continue past the 80th position in the file for the sake of portability.
Place debugging statements in your SQR as you write it. Using the –DEBUG SQR command flag will allow these
debugging statements to be executed when desired, but otherwise ignored by the compiler.
-DEBUG command can be expanded to allow developers to turn on and off individual sections of code for
debugging by identifying sections.
Example -
#ifdef debugx
display 'Entering DATEMATH.SQC: Convert-To-DTU-Date'
display ' Input $date_in: ' noline
display $date_in
#end-if
#ifdef debuga
display ' $DDLZero modified. Probably assigned from numeric.'
#end-if
In the above examples, the “X” code would be displayed be entering -DEBUGX in the SQR Command flag
line. To display both, enter either –DEBUG or –DEBUGAX.
8.6.12 SQR Syntax
Database table and column names when used in variable names or procedure names should not be abbreviated or
changed except where necessary. This more clearly associates the variable or procedure with the source column or
table, and makes it easier to search for affected code when changing a table or column.
SQR is case-insensitive. However, case may be used to improve a program’s readability. Using underscores and
dashes serves a similar function. Recommendations for the usage of case, underscores and dashes are:
Avoid use of the hyphen "-" in variable names. Use the underscore "_" instead. The hyphen is sometimes
confusing (e.g., #count-1 is VERY different from #count - 1). Also, user-defined variables may be more easily
distinguished from SQR predefined (reserved) variables that do use a hyphen between words.
"Begin-Setup", "Begin-Program", "Begin-Report", "Begin-Procedure", and "BEGIN-SELECT" sections should
begin at the left margin as well as their corresponding "End" statements.
Each level inside the SQR should have an indentation of 3 spaces. When continuing a statement, the continuation
should be indented either 3 spaces, or enough to align with semantically equivalent portions of the previous line.
i.e.
Version 7.1
120
Enterprise Systems - UHS
Page 44 of
PeopleSoft Application Development Standards
let {varname} = {statements.............}
{continued statements...}
do {procedure name} ({arg1},{arg2}....{argx},
{argx+1}..........)
"if", "while", and "evaluate" sections increase the indentation by 3 spaces. "else", "end-if", "end-while", "when",
"when-other", and "end-evaluate" should have the same indentation as their corresponding "if", "while", or
"evaluate".
Using "go to" is not recommended.
8.6.13 SQL Formatting
No "moves" unless necessary. In other words, don't MOVE every &variable into a $variable or
move those that are required by the logic of your program.
#variable; only
Processing code should be found between the BEGIN-SELECT and the "from" of the Select paragraph.
Sub SQL statements should follow the same form, but indented.
All key words in the structure should stand out.
"There are 2 rules of precedence. Multiply before you add and use parentheses everywhere else." (paraphrase from
O'Reilly and Assoc.)
8.6.14 Boolean Expressions
Define the values True and False for use in Boolean tests rather than using the integers 0 and 1. This helps selfdocument the code and allows less potential for error. It is more difficult to accidentally assign True when you
mean False than it is to assign 1 when you mean 0. Future maintenance of the program will be made easier by this
practice.
Version 7.1
120
Enterprise Systems - UHS
Page 45 of
PeopleSoft Application Development Standards
8.6.15 SQR Header
The header portion of the SQR includes general information a subsequent programmer would need to refer to:
!*******************************************************************************
! UPER031: ERS TO UH Address DIFFERENCE REPORT
*
!*******************************************************************************
! Description: Reads file from ERS and reports differences in employees
*
!
Address between ERS and HRMS.
*
!*******************************************************************************
! Mod Date Author CSR# Mod Description
*
! xx/xx/xx xxxxxx xxxx xxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx*
!*******************************************************************************
8.6.16 SQR Code Documentation
Procedure Documentation
Documentation pertaining to a called procedure is optional. Developers should always supply documentation to
provide clarification as needed. The Begin-procedure statement should follow the procedure documentation.
Example:
!*******************************************************************************
! Procedure: get_term_descr($strm, :$strm_descr)
*
! Desc:
This procedure retrieves the term description from PS_TERM_TBL.
*
!
It is called from begin-heading and main. This is a local proced- *
!
ure.
*
!
*
!
$strm is passed by value
*
!
$strm_descr is passed by reference
*
!*******************************************************************************
Begin-procedure get_term_descr($strm, $strm_descr)
Code Documentation
Documenting changes to lines of code should adhere to the following rules:
1. Never delete lines of code. Comment them out instead.
2. Use begin and end documentation statements to indicate where changes begin and end.
3. Use the same begin and end structure as indicated in the examples below.
4. To enhance readability, large sections may require commenting out when multiple changes have occurred
within a section.
5. The mod number does not refer to the number of changes within a SQR but the number of times the SQR
was changed. One mod can have multiple changes to the code. The mod reference is the same for all of
them.
Example 1: Changing a line of code
! UHS Begin Mod 01 programmer initials 06/25/2002
! #define non_degree_ugrd_sumr_tran_enrl 'NONDEG'
#define non_degree_ugrd_sumr_tran_enrl 'NONDEGSMRT'
! UHS End Mod 01
!
Example 2: Deleting Code
! UHS Begin Mod 02
!
LET $B = $C
!
LET $A = $B
LET $A = $C
! UHS End Mod 02
Version 7.1
120
Enterprise Systems - UHS
Page 46 of
PeopleSoft Application Development Standards
8.7 CRYSTAL REPORTS
PeopleSoft offers a variety of reporting tools each with a different purpose. These tools allow end-users to create
meaningful, informative, presentation-style reports. Depending on your reporting needs, you may use any one of
these reporting tools.
Reporting tools pull data from your PeopleSoft system to create customized reports. The reports you create can be
used for data analysis and comparison, monthly reporting, meetings and presentations, and much more.
PeopleSoft Reporting Tools enables you to use your data in useful, visual ways.
Crystal Reports is a reporting tool from Seagate software that works with PeopleSoft. As a report formatter,
Crystal Reports can generate custom reports containing information from your PeopleSoft database.
Operating seamlessly with PeopleSoft Query, Crystal Reports offers advanced features to create sophisticated
reports from standard queries. Crystal Reports offers the formatting features of most word processing applications
including sorting, grouping, summary operations. The report can include logos, dates, page numbers, multiple font
sizes and styles.
Creating Crystal reports involves two major steps. Queries are created first in PeopleSoft. Report templates are
then created in Crystal. These report templates serve as shells that are populated with data when you link a query
to the report.
8.7.1 Documenting the Crystal Report
Documenting your report is helpful for managing your reports. To do so follow these steps: Select File/ Summary
Info
 Enter the developer name in Author Box.
 Type internal documentation of your report in the Comments Box. It should contain the date, original
purpose of report, and a modifications log.
 Enter Title that can be added to your report.
8.7.2 Crystal Sort
Crystal Reports allows the output from Query to be resorted. The Crystal sort order takes precedence over the
Query sort order. To improve performance, sorts should occur in Crystal and not in Query.
8.7.3 Summary Operations
The aggregate function in Query performs the same tasks as the summary function in Crystal.
Query’s aggregate function returns only a calculated row of data where as Crystal’s Summary function returns
both detail rows & the calculated row. The detail rows can be hidden on the report.
Whenever a formula is added to the report, the formula editor window should include documentation.
Note: Text, Boolean, and Date fields cannot be summed or averaged.
8.7.4 Sub Reports
A sub report allows information from two reports to appear on one report. It can either be linked or unlinked.
A Linked subreport matches up the rows in the subreport with rows in the primary report. It’s important when
creating linked subreports that all reports are linked by common keys.
An Unlinked subreport does not have data coordinated with the data in the primary report.
Times when you would want to use a subreport:

To combine unrelated reports in a single report.
Version 7.1
120
Enterprise Systems - UHS
Page 47 of
PeopleSoft Application Development Standards

To coordinate data that cannot otherwise be linked.

To present different views of the same data in a single report.
8.7.5 Crystal Criteria
There may be times when it is necessary to filter out unwanted data in Crystal instead of Query.
8.7.5.1 Select Expert
The Select Expert in Crystal is the equivalent of the Criteria tab in PS/Query.
8.7.5.2 Parameter Fields
The Parameter field in Crystal is the equivalent of the run time Prompts of PS/Query. This allows multiple users
to run the same report with different values.
Note: Using selection criteria and parameters, all rows of data will be retrieved from the database and filtered in
crystal. This may cause some performance issues. It is recommended to do all filtering of data in query whenever
possible.
8.8 nVision Reports
PeopleSoft nVision is a reporting tool that exists inside your PeopleSoft system. As a reporting tool, PS/nVision
allows users to work inside Microsoft Excel spreadsheets to generate custom printed reports containing
information from PeopleSoft database.
Operating inside of Microsoft Excel, PS/nVision uses the intersections in the spreadsheet as a base when creating
reports. PS/nVision combines the mathematical and formatting features of Excel with advanced reporting features
such as scope, variables, and labels.
As a reporting tool, PS/nVision is multifaceted. Because this reporting tool is so complex, it is highly
recommended that developer should be familiar with PeopleSoft, Excel, Trees, and PeopleSoft Query before
proceeding to the concepts and procedures of PS/nVision.
When starting to create reports in PS/nVision, queries serve a number of functions. Depending on the type of
report layout, PS/nVision uses information from PeopleSoft queries to populate the report in different ways. In a
matrix layout, PS/nVision can use only those fields from a query that are assigned aggregate functions. In a
tabular layout, PS/nVision allows use of any field from a query to populate the report.
PS/nVision works inside Microsoft Excel. Even when running a query to Excel, PS/nVision provides the
QueryLink that connects the two applications. PS/nVision is linked to Microsoft Excel through Configuration
Manager.
The benefit of PS/nVision working inside Microsoft Excel is that it has the advanced reporting features of nVision
and the command and formatting options of Excel in one application.
8.8.1 Scope
Scope is an optional component that enables you to create multiple instances of a report using a single Report
Request. When you define the scope of a report, you are defining the values that you want the report to contain.
Several PS/nVision variables are designed to work in conjunction with scopes. Variables can be
 Included in your report headings to identify and distinguish report instances based on the same layout.
 Used in the report request to name directories and files to facilitate distribution.
8.8.2 Variables
Use variables in a PS/nVision layout when you have specific information pertaining to the report that may be
different each time the report is run. Examples of variables include the report date and the operator ID of the
person running the report.
Version 7.1
120
Enterprise Systems - UHS
Page 48 of
PeopleSoft Application Development Standards
Information in the heading of your report most often contains variables (e.g. report title, date, and operator ID).
8.8.3 Methods for securing PS/nVision Reports
PS/nVision utilizes several methods in securing data presented on a PS/nVision report. Issues such as performance
and ease of implementation need to be considered before determining the method(s) to use.
Row level Security
Tree-based Security
Query Security
Network Security
Uses authorization table in conjunction with a data table to restrict the
data the user is allowed to access.
Using trees to create authorization tables combines ease of use with
efficiency in implementing security provisions.
Used in query reports
PS/nVision report request works together with network security in
allowing only authorized users the ability to access the report
instances within directories.
8.9 COBOL
Modifications to COBOL programs should only be done when absolutely necessary. The reason for this is
COBOL programs are much more difficult to maintain in PS due to patches.
When a modification to an existing COBOL program is done update the “MODIFICATION HISTORY” section of
the program. This section should be delivered in the program. Add a new subsection “UHS Modifications” at the
end of the Modification History. The information placed here is the CSR#, mod #, date, developer name, and
comments. Put a description of the modification in the comments section.
Example:
******************************************************************
*
*
*
MODIFICATION HISTORY
*
*
*
* Mod Date Author CSR# Mod Description
*
* ======== ====== ==== === =================================*
* 04/16/02 LEM
1234
01 Added code to process session
*
*
Adjust Until Dates.
*
******************************************************************
8.9.1 COBOL Code Documentation
The following is code within the COBOL, procedure descriptions and modifications. If code is replaced, the
original code should also be commented and not removed so the logic of the change can be followed.
*------------------------------------------------------------------------------------------------------------------ *
* Procedure: get_term_descr($strm, :$strm_descr)
*
* Desc:
This procedure retrieves the term description from PS_TERM_TBL. It is
*
*
called from begin-heading and main. This is a local procedure.
*
*
*
*
$strm is passed byvalue
*
*(
:$strm_descr is passed by reference
*
*------------------------------------------------------------------------------------------------------------------ *
*
* uhs begin csr# mod 01 programmer 06/25/2002
* #define non_degree_ugrd_sumr_tran_enrl 'NONDEG'
#define non_degree_ugrd_sumr_tran_enrl 'NONDEGSMRT'
* uhs end Mod 01
*
*
Version 7.1
120
Enterprise Systems - UHS
Page 49 of
PeopleSoft Application Development Standards
* uhs begin csr# mod 01 programmer 06/25/2002 ; added {non_degree_ugrd_sumr_tran_enrl} to the list
* AND B.ACAD_PLAN IN ({non_degree_ugrd_tran_enrl}, {non_degree_grad_tran_enrl},
*{non_degree_ugrd_sumr_tran_enrl})
* uhs end Mod 01
8.9.2 COBOL DMS
The COBOL DMS is a file that is run by Data Mover to load the PS_SQLSTMT_TBL with all of the SQL
statements that will be used by the COBOL program. The program does not have to be compiled when changes
are made to the DMS. The Data Mover can only be run by the DBAs in all environments except Development.
Any changes made to the fields selected and/or the criteria used must match what the COBOL program is
expecting.
Example:
COBOL(example):
03 REPORT-ONLY
PIC X(01) VALUE SPACES.
03 SRVC-IND-CD
PIC X(03) VALUE SPACES.
* UHS Begin Mod 561 *
03 WITHDRAW-FLAG
PIC X(01) VALUE SPACES.
* UHS End Mod 561 *
DMS(example):
,REPORT_ONLY
,SRVC_IND_CD
* UHS Begin Mod 561 *
,WITHDRAW_FLAG
* UHS End Mod 561 *
FROM PS_RUN_CNTL_CALC
WHERE OPRID
= :1
AND RUN_CNTL_ID = :2
When a modification to a DMS file is made, it will be commented at the top of the file and the new code will
commented with begin and end markers.
The comments at the top of the DMS file will contain the CSR#, the modification number, developer name, date,
and description of the change.
Example:
--- UHS CSR# Mod 561 LEM 16 SEP 01 Added "WITHDRAW_FLAG" field to
SFPCLCAN_S_RUNCTL Change Sort order of SFPCLCAN_S_ENROLL
-The comments marking the modified code must contain “Begin” or “End”, Modification number, developer name
or initials, date, and description.
Example:
-- UHS Begin MOD 561 LEM 16 SEP 01 Added "WITHDRAW_FLAG" field to Select
STORE SFPCLCAN_S_RUNCTL
SELECT
BATCH_ID
,BUSINESS_UNIT
,CANCEL_TYPE
,STRM
,SESSION_CODE
Version 7.1
120
Enterprise Systems - UHS
Page 50 of
PeopleSoft Application Development Standards
,FA_ITEM_GROUP
,FROM_TERM_FINAID
,TO_TERM_FINAID
,REPORT_ONLY
,SRVC_IND_CD
,WITHDRAW_FLAG
FROM PS_RUN_CNTL_CALC
WHERE OPRID
= :1
AND RUN_CNTL_ID = :2
-- UHS End MOD 561 LEM 16 SEP 01 Added "WITHDRAW_FLAG" field to Select
;
Comments cannot be imbedded within the SQL statement. Comments describing what was changed, added, or
removed must be placed before or after the SQL statement. These comments must include fields added.
If any part of the SQL statement needs to be removed, it will only be commented out.
Example:
-- UHS Begin MOD 561 LEM 6 NOV 01
-- Change SQL to sort courses in the order they were enrolled in
-- Comment out following delivered code
-- STORE SFPCLCAN_S_ENROLL
-- SELECT
-- B.CLASS_NBR
-- ,B.SESSION_CODE
-- ,B.UNT_BILLING
-- ,B.CRSE_GRADE_OFF
-- FROM PS_STDNT_CAR_TERM A
-- , PS_STDNT_ENRL B
-- , PS_CLASS_TBL C
-- WHERE A.EMPLID
= :1
-- AND A.BILLING_CAREER = :2
-- AND A.INSTITUTION
= :3
-- AND A.STRM
= :4
-- ORDER BY B.CRSE_GRADE_OFF,B.ENRL_ADD_DT DESC, B.CLASS_NBR
-- UHS Commented out preceding delivered code
STORE SFPCLCAN_S_ENROLL
All comments must be prefixed with “UHS”. This will simplify finding any University of Houston code changes.
8.10 BATCH PROCESSING
This section describes principles and standards of batch processing regardless of which program type or tool is
used for the batch process. These principles generally apply to all batch processes. Application development
standards for programming tools are found in other sections contained within this document.
8.10.1 Training Requirements
Minimum developer training requirements for those who develop batch processes are SQL, SQR, Query, and
PeopleTools I. Advanced training includes application engine and integration broker.
8.10.2 Processing
There are several uses for batch processes:
1.
A batch process is used to process large volumes of information. For example, a batch process is needed to
perform a monthly accounting close or to generate payroll checks and update the payroll history whereas an
interactive process might be used to produce one payroll check. A batch submission page will be used to
Version 7.1
120
Enterprise Systems - UHS
Page 51 of
PeopleSoft Application Development Standards
define the required parameters and to submit (run) a batch job. The parameters collectively are stored in the
run control record defined by the panel and accessed by the batch job.
2.
A batch process may be appropriate for small data volume if program complexity is such that maintaining
both on-line and a batch version of the program is not advisable.
3.
A batch process may be used to provide a report that is complex enough that a PeopleSoft Query will not
suffice.
4.
In some cases, batch process is a way to avoid locking a work station while the transaction process is
completed.
Batch processes run on the Process Scheduler.
Batch processes that update the database must provide the ability to recover from crashes without data corruption.
Since a batch job may repeat thousands of times what an on-line screen does once, efficient processing and crash
recovery are of the utmost importance. The likelihood that a process will not finish successfully should be reduced
by thoroughly trapping errors. Exceptions or minor problems not critical to successful application use should be
reported but should not stop the process.
The documentation within the batch program should explain the recovery process. Two considerations are
especially critical when writing batch update programs:
1. Transaction logic; and
2. Ability to be recovered.
8.10.3 Transaction Logic
As a batch process issues SQL commands to insert, update, or delete records from the database, the record changes
are stored in an area called “the rollback segment.” When a commit command is issued, the records in the rollback
segment are applied to the database. If a rollback command is issued, the records in the rollback segment are
deleted and the database records are not updated.
A "transaction" refers to the unit of work that must be accomplished in its entirety to maintain the logical
consistency of the database. A logical transaction may require updates to one or more different records, or even
different databases, all of which comprise a single transaction or unit of work. In an on-line page, a logical
transaction is usually all of the updates associated with a single press of the save icon. Either everything the user
requested is committed and written to the database or none of it is.
With SQL, a logical transaction is terminated with a COMMIT statement. A single commit is when a single
commit is issued after ALL transactions are processed. The single commit will write all the transactions to the
database at a single time. If a SQR does not contain a single commit, it will automatically perform a single
commit when the SQR process completes successfully.
The advantage of using a single commit is that it makes restart and recovery much easier. The batch process is
simply rerun from the beginning. If you are processing a large volume of data or if it takes a very long time for the
process to run, this may not be practical. Commits may need to be placed logically within the batch process. If so,
a commit should never be issued until at the end of a logical transaction. When the commit is issued, the
developer should consider what is necessary in the event that the process needs to be rerun. The batch process
should begin from the point of the last commit before the process terminated.
The ROLLBACK command can be used to release any records held for update. Any inserts, deletions, or updates
that occurred prior to the ROLLBACK will be lost.
NOTE: Once the COMMIT command has been executed, the rollback command cannot restore records
updated prior to the commit.
Version 7.1
120
Enterprise Systems - UHS
Page 52 of
PeopleSoft Application Development Standards
In order to determine the optimal timing of the COMMIT statement, the batch developer must compromise among
the following conflicting criteria:
1. COMMITs are resource-intensive. Unnecessary commits can increase run time significantly.
2. Single commits should be used whenever possible; however, records that have been stored, updated, or
deleted, are placed in rollback statement until the next COMMIT. Holding too many records could result in
running out of space for the rollback segment causing the program to abort, and may cause other processes to
fail as well. If multiple commits are required, commits should be placed at the end of a logical transaction.
3. Records cannot be held longer than the Transaction Time-out parameter for the database. At the time
the standards were compiled, the transaction time-out parameter for all databases was set at 5 minutes. The
Transaction Time-out measures elapsed time, and elapsed time for different runs of the same process will vary
according to the current load on the system.
4. The COMMIT must not conflict with the logical unit of work (a transaction) required to maintain data
consistency. For example, a program might issue a COMMIT for every account, or every 20 accounts, but not
in the middle of updates for an account.
5. A ROLLBACK command should be issued whenever an error is detected in the batch process. If an SQR
errors, it will automatically issue a rollback command.
8.10.4 Batch Recovery
When a batch update process aborts because of a system error or incorrect program logic, in the case of programs
using multiple commits, rerunning the same program might create duplicate updates or missing records.
Therefore, it is important that all batch programs provide logic and instructions for recovery, i.e., the steps to be
taken in order to bring the job to a successful completion.
8.10.4.1 Recovery Options
There are two approaches to complete a job that has abnormally terminated for some reason. In either case, when
the job has completed successfully all of the updates should have been completed, and none of them duplicated or
skipped.
1. Rerun -- a job stream is run which will start the failed process over from the beginning and run to the end.
The rerun will reprocess all the data processed by the aborted job step.
2. Restart -- a job is submitted which will restart the aborted job step from the point of failure and proceed to the
end. Data, which were processed by the aborted job, will not be reprocessed.
Recovery may be accomplished automatically or with manual intervention.
NOTE: Regardless of the method chosen, all batch update programs must provide for some kind of
recovery that does not require programmer intervention.
The ability to recover a batch program is essential to allow users to perform their own production control. In this
way, if the batch update job does not finish successfully, it can be easily recovered without requiring emergency
ad hoc batch database repairs.
Batch jobs that support deadline-critical processes should also include a mechanism within the log file for
determining the current status of the job. For example, completion status and summary statistics may be written to
the log file after each major step.
8.10.4.2 Restart Recovery
The resources required by a batch job will influence the choice of recovery methods.
NOTE: Batch processes requiring significant resources should be programmed to start from point of
failure, rather than rerunning from the beginning.
The following guidelines offer general suggestions that should be useful for most batch processes. However, each
batch program must be individually analyzed and supplied with custom restart logic. One solution does not fit all.
Version 7.1
120
Enterprise Systems - UHS
Page 53 of
PeopleSoft Application Development Standards
All batch jobs should begin by retrieving the run control parameters from the run control record. The parameters
should be written immediately to the log file to aid in troubleshooting if the job crashes.
A restartable batch job must determine the current job status -- initial run or recovery run. The batch process must
determine point of failure.
Forcing a batch process to skip steps and/or initiate database access loops from variable starting positions requires
that the program be designed in separate phases. Each phase can be performed independently; and, in many
instances, some phases can be started from the point of failure. For example:
Phase 1: Master File Update loop -- read the master file and update for each transaction and/or write report data for
each transaction.
Phase 2: Sort the report data file.
Phase 3: Report loop -- read the sorted data file and generate the report.
Phase 1, the master file update, must update the restart control record with checkpoint information before every
COMMIT. For instance, use the key information. If key fields are modified, then both the old key and the new
key must be stored.
It can be useful to store the operator id, process id, date, and run time in the restart control record, as well as the
name of each flat file as it is opened. Include relevant information for each, such as how many records have been
written or read, and whether processing of the file is complete. When the job has finished, the restart control
record should be properly flagged for success; or, it should be deleted, so that the next run of a periodic batch job
will start fresh.
If the program determines the process aborted in phase 1, the update/data collection step, recovery might include
the following:
1. Read the old output data file created in phase 1 and write it a to new output file. Then the subsequent logic
will continue to update this new file with the additional output data. Or the output data file created by the new
process could be appended to the old data file at the end of phase 1.
2. Enter the master update loop by starting with the record key from the restart control record. If the record key
is not unique, reject records until the key from the control record has been skipped. When the job has
finished, the control record should be properly flagged for success; or, it should be deleted, so that the next
run of a periodic batch job will start fresh. A restart will use the same control record to manage the restart
process. If the program determines the process aborted in phase 1, the update/data collection step, recovery
might include the following:
1)
Read the old output data file created in phase 1 and write it a to new output file. Then the
subsequent logic will continue to update this new file with the additional output data. Or the output
data file created by the new process could be appended to the old data file at the end of phase 1.
2)
Enter the master update loop by starting with the record key from the control record. If the record
key is not unique, reject records until the key from the control record has been skipped.
Other methods for making a batch update process recoverable include:
1. Perform the job in two "passes." On the first pass, create a transaction table that contains the desired changes
for the transaction. On the second pass, update the master record from the transaction table. A recovery could
run both passes, or start with the second pass, depending on where it aborted.
2. Put a special field in the record to indicate whether a row has been processed -- for example; store the date or
set a flag in a field that has been included in the record for that purpose. The select statement that identifies
the rows to be processed for update would use that field in the selection criteria.
3. Use a restart control record. At the beginning of the batch program, if the control record does not exist, create
one. Use the instance number as part of the key. Update the control record with the values of key fields from
the select statement that pulls the population to be updated. If there was a preexisting control record, which
indicates that this is a re-run, start the processing with the first employee whose number is greater than the
Version 7.1
120
Enterprise Systems - UHS
Page 54 of
PeopleSoft Application Development Standards
employee number in the control record. In this manner, not only duplicate updates but also duplicate effort
will be avoided.
8.10.5 Error Handling
Proper error handling is essential in batch processing. Any error that causes the batch process to abnormally
terminate should be trapped and displayed in the log file, report file, and the Process Monitor. The batch process
should include mail notifications to be sent to appropriate staff. Possible batch errors could be system errors
causing the process to terminate or an error the developer has identified in the program code and does not want
processing to continue if a particular error condition exists.
8.10.6 Recurring Batch Processes
Batch processes may be scheduled to run on a recurring basis. For example, a batch process could be scheduled to
run daily at a particular time. This is accomplished through the Process Scheduler. Special precautions must be
taken when changing the recurrence parameters for batch processes. Multiple batch processes can share the
recurrence name.
NOTE: If the recurrence date and time is changed, it affects all processes using that recurrence.
If a batch process’ parameters that control date ranges or semester terms should be calculated for each run rather
than supplied as constants by the submitting user, instructions should state whether a date / term field may be left
blank and what approach the program will use to compute the date / term in that case. For example, a monthly
report could use the current system date to determine the date of the previous month. If this approach is used, the
user will have the option to specify the date range as a constant for a non-periodic run of the job, in case it is
necessary to rerun for older data.
Care must be exercised for periodic batch which uses restart logic (Section 7.3.4.1) for the recovery of aborted
jobs. Restart control records and the parameters stored in them must be created in such a way that each logical run
is distinguishable. For this reason, it is recommended that control records be deleted or renamed upon successful
completion.
The process must be able to distinguish between import/export files that were intended for a previous run and
those for the current run. A naming convention must be devised which uniquely identifies the file(s) created by
the batch process from files created from previous runs. Ideally the process instance number should be used as
part of the file name.
SQR Example:
stdapi will populate #prcs_process_instance. In this example, the value is 0001234567
Let $FileName = ‘abc_extract’
Let $FileName = 'filename_' || edit(#prcs_process_instance,'0000000000') || '.txt'
Result: $File_name = ‘abc_extract_0001234567.txt’
8.10.7 Ad hoc Updates
Ad hoc batch processing against the production database can be done in one of two ways: 1) using SQL scripts
and a utility such as SQL+ to execute those scripts; 2) using SQR.
NOTE: Application developers are not allowed to directly execute SQL scripts or ad hoc SQR that will
update production databases. All scripts that update production databases require functional user approval.
Ad hoc requests are made by creating a CSR in STAT. The CSR will provide instructions to the DBA on the script
to run and expected results.
Ad hocs may be written to create a one-time report. Such reports are written in SQR or may be written in SQL as
queries with output that can be input to Excel spreadsheets. The developer does not need special authorizations to
run these reports.
Version 7.1
120
Enterprise Systems - UHS
Page 55 of
PeopleSoft Application Development Standards
8.10.8 Process Scheduler
The Process Scheduler is the mechanism to submit a program for execution in a batch environment. The SQR
should include the stdapi.sqc for providing a communications link to the Process Monitor. SQR programs should
call stdapi to indicate the SQR is processing. Routines in stdterm.sqc should be used to indicate the process
successfully completed. If the SQR encounters an error, the appropriate stdapi fields should be updated to provide
any useful information.
Alert messages should be sent to the submitter notifying them that their job has aborted.
A job is a set of processes that may run sequentially or concurrently.
The Process Scheduler allows users to schedule their jobs to run in the future. Jobs and processes can be
scheduled to run daily, weekly, etc. using recurrence definitions.
The Process Scheduler provides report distribution and the automatic routing of reports to multiple recipients. The
Process Scheduler cannot split a report file into separate reports and route the individual reports to various
recipients.
8.10.9 Process Monitor
The Process Monitor allows users to monitor batch processes they have submitted. From the Process Monitor
users can cancel currently running or scheduled batch processes. Users can also monitor but not change batch
processes submitted by other users.
A snap shot of the Process Monitor is provided below:
8.10.10 Log Files
Log files are created whenever a batch process runs.
Version 7.1
120
Enterprise Systems - UHS
Page 56 of
PeopleSoft Application Development Standards
Batch log files are important for troubleshooting problems. Programs should print messages to the log file to
identify errors when they occur during processing. Also, processes that handle thousands of records should
periodically write status information to the log. The DISPLAY or SHOW statement is used for this purpose.
The log file should not be used to output information that is part of the regular processing requirements of the job
or to provide information that the user requires for validation or verification. It is not formatted in a user-friendly
fashion and is not intended as an end-user report. Use a report file for this purpose.
8.10.10.1 Log File Location
The log file will be copied to the report repository. The SQR will create a log file with the process instance as part
of the file name. Log files are automatically deleted when they are older than 30 days in production and 10 days in
non-production environments.
8.10.11 Data Files & Unix Directories
When running batch processes on the server, data files may be directed to Unix directories that allow developers
access to secured directories. The purpose of the Unix directories is to facilitate import/export file interfaces via
FTP.
Unix systems administrators are responsible for maintaining security to Unix directories. Users will have indirect
access through the application via submission of a batch process, ftp process, etc. Developers will have direct and
ftp access. One Unix directory will exist for each application area. The technical application manager is owner
and may create subdirectories as needed.
The processes submitted from the PeopleSoft financials application will logon with the psftfs logon id and from
the student/hr application with the logon operator id. The application logon ids have write permissions to the
following directories. Application developers have also been granted privileges as indicated below.
The following directories will be established on Unix servers in development, test, and production environments.
/logs/finance/… - for exclusive use by Financials. Developers have read, write, execute, and control.
/logs/hrms/…
- for exclusive use by HRMS. Developers have read, write, execute, and control.
/logs/student/… - for exclusive use by Student Academic Administration. Developers have read, write, execute,
and control.
8.10.12 Reports
SQR, Crystal Reports, WinWord, and nVision are the primary means to create reports, forms, and letters.
8.10.13.1 Report Contents
A report typically contains the following sections:
Title Area – includes run date, run time, report title(s), program id, As Of Dates, From & Thru Dates, Business
Unit, Deptid and name. Standard SQCs have been developed within each application area to provide a standard
appearance to the report. The developer must analyze the SQC to determine which fields need to be populated to
appear in the Title Area.
Column Headings – each column of data should contain a column heading. Each column heading should be
underlined or underscored for readability purposes.
Report Detail – data that appears in each column of the report. If break processing is used for subtotals or page
breaks, the sort and break fields should appear as the first columns on the report and should be listed in the order in
which they are sorted. The exception to this would be columns that are descriptions of id or code fields, which
may appear with the sorted fields. For example, a report breaking on college id and deptid, would be arranged in
the following order:
collegeid, college name, deptid dept name, emplid, employee name, detail columns…
Version 7.1
120
Enterprise Systems - UHS
Page 57 of
PeopleSoft Application Development Standards
Subtotals – are optional and typically appear in the middle of the report. Page breaking is not required before a
subtotal occurs. Subtotals should have a blank line preceding and following the subtotal line. Subtotal fields
should align underneath corresponding detail fields.
Page Totals – are optional and appear at the bottom of each page. Page totals contain totals for the detail columns
on that page. Page total fields should align underneath corresponding detail fields.
Grand Totals – are optional and appear at the end of the report. Grand totals are printed after the last subtotal line
on the report. Grand total fields should align underneath corresponding detail fields.
8.10.14 SQL Optimization
Batch processes should be analyzed to see if they could be optimized for execution speed and minimum database
access. For daily run or time critical processes, optimization is especially important. Optimization should include
a review of the SQL statements to see if they are as efficient as possible. Oracle’s Explain Plan can be used to
determine how a SQL statement is being executed.
8.11 INTEGRATION TECHNOLOGIES
Data transfers between PeopleSoft applications or to 3 rd party applications must be made using one of the
following technologies:
1. Integration Broker
2. Component Interface
3. Database Links
4. Feed Files
Integration controls should be provided to ensure that all records have been processed.
8.11.1 Integration Broker
This technology provides for the direct transfer of data between a PeopleSoft application and another PeopleSoft
or 3rd party application using XML and Web technology instead of passing flat files or use of database links.
8.11.2 Component Interface
The Component Interface is used to map data to either read or update PeopleSoft application tables. It invokes all
of the logic and edits defined in the Component. PeopleSoft provides delivered Component Interfaces. Developers
can also create custom Component Interfaces.
8.11.4 Database Links
Database links allow databases to pass data to each other via transaction tables or staging tables.
NOTE: Database links are not the preferred means for sharing data between databases.
Integration Broker or the Component Interface should be used whenever possible. Access via database links can
be read only or can allow database updates. Database links can be either private or public. Private links are
normally used which restrict the link to a specific user. Public links allow open access to anyone and should not
be used.
8.11.5 Feed Files
Flat files can be used to import/export large amounts of data from one application to another. These applications
may be PeopleSoft applications or 3rd party applications.
Batch input processing should apply all verification edits. If the input data contain errors, the process may reject
the bad transactions or the entire feed. In either case, if possible, the rejected transactions should either be stored
in the target table with a "suspense" status, or stored in a separate "holding" table. An on-line maintenance page
for processing the suspended or held transactions should be provided for correcting errors in the feed data.
Version 7.1
120
Enterprise Systems - UHS
Page 58 of
PeopleSoft Application Development Standards
To ensure that the correct file can be recognized and duplicates avoided, especially for periodic feeds:
1)
The source application should name the file to uniquely identify each feed.
2)
The target application may post to a table when each feed is processed, so that it can determine which files
have already been fed.
The target application should rename or delete the file after successful completion of the process. The source
application should retain a copy of the feed file.
8.11.6 Interface Controls
Extract files should contain one or more control records which provide control counts and dollar amounts (if
applicable) for verification.
The input process should
 Provide counts of records read with breakdowns by various groups to match control record counts.
 Compare record counts against control record counts.
 Provide counts of records inserted, updated, not updated.
 Total number of records inserted, updated, or not updated should match total control count.
 If counts do not match, send email notification as such. End process in an error state.
 For records not updated, counts for reasons why not updated. Each input record can have multiple edits
that failed; therefore, these counts may not match other counts.
 Provide detail information for records updated. (results can be stored in a custom table.)
 Provide detail information for records not updated. (results can be in a custom table.)
Example:
Extract file contains one control record for each campus and a grand total control record.
UH
2000
UHC
1000
UHD
1000
UHV
500
Grand Total
4500
Records Read:
UH
UHC
UHD
UHV
Total
2000
1000
1000
500
4500
Records Inserted
Records Updated
Records Not Updated
Total
1000
3000
500
4500
Reasons Not Updated:
Invalid Job Code
Invalid Position
Invalid Emplid
Total
200
400
300
900
Version 7.1
120
Enterprise Systems - UHS
Page 59 of
PeopleSoft Application Development Standards
8.12 AUDIT TABLES
An audit table captures changes that have been made to a master data table that is being audited. Functional leads
shall determine which tables require auditing, however, some tables cannot be audited because of their size.
When the master data table is updated, an image of the row is recorded to the audit table including inserts, updates
and deletes. The audit table records a date/time stamp, action type, and operid of the person making the change.
This function is very useful for providing a record of who has made changes to sensitive and critical data. It can
also be used to recover data entered by a user in error.
Oracle database triggers will be used to automatically update audit tables whenever the master data table is updated.
This removes the restrictions to create code to update audit tables in PeopleCode, App Engines, COBOL, and SQRs.
There are, however, some significant limitations to the function of audit tables.
1. There is not a mechanism for looking at the audit tables provided by PeopleSoft. A custom query, report, or
page would need to be created for each audit table.
2. If large numbers of tables are audited a performance penalty will be seen in the system. Do not forget that
for each change being made to the master table, at least one entry is being made in the audit table.
3. For large tables that have many changes made to them an audit table will become very large.
8.12.1 Audit Table Retention Policy
Records within audit tables should be retained for 3 years. A custom process will be required to archive or delete
entries in audit tables.
8.12.2 Field Level Audits
Field level audits are set up to audit a single field on a table.
NOTE: Because of the increased overhead, as a rule, field level audits are not recommended.
A field level audit will enter a row into the PSAUDIT audit table for each audited field that has been changed on the
record. This means that if a record has more than one field being field audited the audit table will get multiple rows
insert for each change to the data table.
8.12.3 Record Level Audits
A record level audit inserts one or two rows of data into the audit table for each change that is made to the data table
being audited. This kind of audit will costs less system resources than a field level audit and can provide more
information than the field level audit. The context of the change of a single field of data in a row can be important
in telling what the change means and in recovering the original data if it is necessary.
8.12.4 Record Level Audit vs. Field Level Audit:
While you can audit individual fields at the field level, you may find it more efficient to have the system audit the
entire row whenever a user adds, changes, or deletes information. With record-level audits, the system focuses on
rows of data, as opposed to specific fields. Instead of writing multiple rows for each insert, change, or delete
transaction at the field level, an audit record writes a single row of audit data.
8.12.5 Field Level Audit Table
Audit Field Name
AUDIT_OPRID
AUDIT_STAMP
AUDIT_ACTN
RECNAME
FIELDNAME
OLDVALUE
Revised Feb. 2008
Purpose
Identifies the operator who caused the system to trigger the audits,
either by performing an add, change, or delete to an audited field.
Identifies the date and time the audit was triggered.
Indicates the type of action the system audited.
Identifies the name of the record definition audited.
Identifies the name of the audited field.
Stores the original values of the field for audit change and delete
actions.
Enterprise Systems - UHS
Page 60 of 120
PeopleSoft Application Development Standards
NEWVALUE
Stores the new values of the field for audit change and delete
actions.
Stores the old values of key fields in order of appearance on the
record definition. PSAUDIT supports up to 15 different keys fields,
each with a maximum field length of up to 50 characters.
KEY# 1-15
8.12.6 Record Level Audit Table
Audit Field Name
AUDIT_OPRID
AUDIT_STAMP
AUDIT_ACTN
RECNAME
Purpose
Identifies the operator who caused the system to trigger the audits,
either by performing an add, change, or delete to an audited field.
Identifies the date and time the audit was triggered.
Indicates the type of action the system audited
Identifies the name of the record definition audited. (Optional)
This field is used when more than one data table may be using this
audit record.
Fields of table being
audited, for example:
EMPLID
NAME
ADDRESS1
ADDRESS2
Etc.
8.12.7 Audit Action Values
Action
A
Description
Add
C
Change
D
K
Delete
Key change Old record
N
Key Change New Record
Comment
The audit record contains the row of data that was added
to the original table.
The audit record contains the row of data as it was
before the change was applied to the original table.
The audit record contains the record that was deleted.
The audit record contains the record that has the original
key information
The audit record contains the record that has the new
key information.
8.13 CUSTOM QUERY TREES
PeopleSoft delivers a number of trees that are used for row level security, report hierarchy, and for Query.
NOTE: PeopleSoft delivered Query trees should never be modified without the technical manager’s approval.
Any changes made to the PeopleSoft delivered Query tables will be lost when the next PeopleSoft release is
installed. These tables can be cloned and modified as necessary to meet the needs of the functional community.
Maintenance of Query Trees is located in PeopleTools, Security, Query Security, Query Access Manager.
Revised Feb. 2008
Enterprise Systems - UHS
Page 61 of 120
PeopleSoft Application Development Standards
Access groups are used by PeopleSoft security to restrict access for a view or a record to a particular set of users.
Multiple access groups may be created for a query tree. Users secured to an access group can access any views or
records belonging to that access group. New access groups should logically describe the group and begin with the
UHS_ prefix.
Revised Feb. 2008
Enterprise Systems - UHS
Page 62 of 120
PeopleSoft Application Development Standards
Within an access group, trees can be logically segregated into smaller groups as shown below:
The application developer must be concerned with Query security and which set of users will need access to a view
or a record before the view or record can be placed on a Query tree. Some data is security sensitive and must be
restricted to authorized personnel.
For example, access to personal bank accounts, grades, or credit card
information should be very restricted or perhaps not made available at all via Query. Application developers must
coordinate with security administrators and functional users before adding a view or record to a query tree.
Records are added as nodes to the tree.
In order for users to view the Query trees, Query Access List Cache must be run.
Revised Feb. 2008
Enterprise Systems - UHS
Page 63 of 120
PeopleSoft Application Development Standards
8.14 TREES
Tree structures and definitions may vary between database environments.
Note: Trees as a rule should never be migrated between environments.
Tree Manager enables you to organize tree structures under high level groupings, called categories. The following
category names are suggested.
Budget
Default
Report
Tools
UHS
Revised Feb. 2008
Budget related Access Groups are placed under this
category.
This is a PeopleSoft delivered Category.
UHS developed reporting related access groups are placed
in this category.
PeopleTools & Workflow related Access Groups are placed
in this category.
This category has Access Groups for UHS Tables.
Enterprise Systems - UHS
Page 64 of 120
PeopleSoft Application Development Standards
9. APPLICATION TESTING
9.1 TESTING PHILOSOPHY
Thorough application testing helps ensure a quality product for the end user and is the responsibility of developers
and functional analysts. Lack of adequate testing by either group could severely impact end users in the production
environment. Problems discovered in production are always more costly than those caught during test. Data may
need to be recovered or corrected, business processes may be halted, and productivity is lost as developer and
functional analysts must recode and retest.
Application developers are committed to providing quality software to allow users to automate their administrative
tasks and thus improve their efficiency. In addition, because of the interaction among departments and the
integration of administrative data, the application development departments are responsible for providing software
that maintains the integrity of all official university data.
Application testing is the execution of a program and/or processes to find its faults. It is important to understand
that testing can be used to show the presence of bugs but never their absence.
“Testing” in this document is defined as the formal evaluation of accuracy, integrity, and usability of the process.
Testing is not an adequate tool for completing code; it should only be used to gauge the integrity of the completed
code. If it is determined that a module has an inordinate number of errors, testing should be stopped until the code
has been reworked. Developers routinely test processes during the development stage. This is considered
development work and is not governed by this section.
Errors introduced as a result of maintenance activities can be particularly disruptive because users are often reliant
on the sustained functionality of the system. The standard testing policy is a two-tiered approach whereby both the
developer and the functional departments are involved. The testing and/or running of programs occur at three levels,
which correspond to the three environments currently defined in the system:
1)
2)
3)
Development -- testing is the sole responsibility of the developers;
Functional Testing -- testing is done in conjunction with users and developers,
Production -- running programs is the sole responsibility of the users. The involvement of developers at this
stage should be minimal, except to investigate results that users think are not correct.
There are two primary methods for conducting tests: Progressive Testing and Regressive Testing. Both methods
should be applied when conducting tests.
9.2 UNIT TEST
The developer ensures that a given module retrieves and updates desired data without jeopardizing the integrity of
the database.
If a unit is composed of several subroutines and/or subprograms, each module must be tested separately as well as
together. Test cases should be constructed using already developed programs, whenever possible. If necessary,
developers can store custom test data in the development database, but they should ensure that all the necessary
fields are documented (if only out of courtesy toward other developers). The developers can also transfer, on
request, a test population from production to development or training for certain tables or files.
Coordination with other developers who may be testing against the same tables or files is essential to avoid
confusion.
For reports and external feeds, developers should create a test file without waiting for the data extraction or feed
programs to be written.
Reports and feeds should always be tested for how they react if the input file is not there or is empty. If a report is
tested on a limited extract from a data file (e.g., the first 100 records), it must be tested at least once with no limit (to
make sure that the last break condition, for instance, is taken into account).
Revised Feb. 2008
Enterprise Systems - UHS
Page 65 of 120
PeopleSoft Application Development Standards
If a module is to be restartable, the restart and recovery must be tested.
9.2.1Unit Test Procedures
The developer should take the following steps:
1)
Go back to the original program specifications and make sure every condition has been taken into account as
far as writing the program is concerned.
2)
Set up test data. Always try to use existing production programs to set up test cases unless impossible. Every
scenario described in the specifications should be part of the test scenarios.
3)
When testing, always think about testing for standard functions.
4)
When updating critical information, test for abnormal termination and evaluating restart possibility.
5)
Make efforts to distribute a quality product: for example, report headings should be centered or consistently
justified; dates and times need to follow standard formats; columns should be aligned on pages and evenly
spaced (i.e., do not leave too many blanks at the end of a line, instead distribute spaces between columns).
9.3 PROGRESSIVE TESTING
Progressive Testing involves testing to identify errors associated with new or modified code. This includes the logic
specific to the code as well as interfaces with previously integrated code.
9.4 REGRESSION TESTING
Regression testing involves testing to verify the sustained integrity of the previously integrated code. Regression
testing of the entire process is particularly important with regard to application maintenance as unexpected new
errors may be introduced within the process (fix one, break three).
9.5 INTEGRATION TEST
The integration test ensures that the module to be tested works across PeopleSoft Applications or between
PeopleSoft and 3rdparty applications. The Integration Test should confirm that the process will not cause problems
when run in conjunction with other dependent or independent processes.
Integration testing is not as important for read-only programs as it is for update programs. For update programs, the
testing plan must include all the programs that use those data elements which the module being tested updates. If
applications send or receive data as part of the process, those applications should be included in the integration test.
9.5.1. Integration Test Procedures
1)
Integration Testing between applications is conducted first in development and continued in the test
environment by functional users.
2)
Downstream processes should be tested to ensure process and data integrity.
9.6 SYSTEM TEST
A system test is usually required when a process is automated for the first time, re-engineered, or when maintenance
packs have been applied.
Note: System Testing consists of evaluating both business procedures and computer resource requirements.
The main goal of a system test is to ensure that every aspect of the process has been taken into account (e.g.,
correction procedures, tracking of results, etc.) and no programmer intervention will be required when the process is
in production. Also, during system testing, developers may assist users on how to test changes, correct errors,
recover (restart or rerun) failed batch jobs, etc.
From the developer's point of view, the system test should include an evaluation of the program for acceptable
performance, although this should be part of the initial development considerations.
Revised Feb. 2008
Enterprise Systems - UHS
Page 66 of 120
PeopleSoft Application Development Standards
9.6.1 System Test Procedures
1)
Developers and functional users are responsible for the evaluation of performance and recovery capability of
computing processes.
2)
Functional users are responsible for the testing of business processes and required functionality.
9.7 END TO END TESTING
End to end testing involves complete process testing, both manual and automated, to ensure automated, manual, and
business practices work as intended.
9.8 USER ACCEPTANCE TEST
The User Acceptance Test is conducted by the users to make sure that a program works the way they want, or if they
did not design the interface, that it is user-friendly enough for them to understand. User Acceptance Test is often
conducted in conjunction with System Testing.
For reports and other batch processes, the user acceptance test consists of evaluating results and being able to
understand them (or cross-examining them with some other report, etc.).
9.8.1 User Acceptance Test Procedures
Users should follow the guidelines of their own departments. When they are reasonably assured that the programs
function correctly, they approve the transfer to production.
9.9 SECURITY TESTING
Security testing ensures that users have access and are able to navigate to processes and adhere to UHS Security
Policy. This normally occurs after system testing is completed and all processes have migrated to production, but
before the process has been released for use by the functional community.
9.10 LOCALITY TESTING
Locality testing ensures that the application will work regardless of where the user is geographically. Various types
of internet browsers should be used as well to ensure the application works on a variety of commonly used
platforms. Geographical testing is especially important if hardware is distributed geographically.
9.11 LOAD TESTING
Load tests are used to measure the impact of heavy usage on the system -- on-line and batch. Load tests place a load
on various servers and software to determine how the system performs when placed under a load.
Load tests should be conducted when
 Oracle is upgraded to a new release
 When PeopleSoft is upgraded to a new release
 Any new network or server hardware or operating systems are installed, reconfigured, or upgraded.
Software is available that will emulate multiple users accessing the system at the same time.
A load test should be conducted on the same type of equipment and software that is used in production.
Revised Feb. 2008
Enterprise Systems - UHS
Page 67 of 120
PeopleSoft Application Development Standards
9.12 TESTING GUIDELINES
On the basis of the type of program and the type of maintenance to be performed, the following tests should be
performed. The User Acceptance test is always the last step.
Type of Test
Unit
Progressive
Regression
Integration
System
End To End
Security Test
Locality Test
Load Test
User Acceptance Test
Prod Support
Developers
Functional
Y
Y
Y
Y
Y
Y
Patches, Upgrades, Major Changes
/ Development
Developers
Functional
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Additional testing requirements and information on the testing procedures may be imposed by technical managers
depending on the degree of criticality of any given application.
9.13 TEST PLANS
Test plans are a valuable aid to both the application developer and the functional analyst who will be performing
various tests. The test plan identifies






Type of test (Unit, Integration, System),
Complete list of testing scenarios,
Setup/configuration requirements for each scenario,
Person who will perform the test,
Date the test was completed, and
Test results.
A thorough test plan will help ensure that the application was thoroughly tested before it is migrated to production.
Each type of test should have its own separate test plan and be maintained by the developer, functional analyst,
and/or business process owner, whoever is appropriate for the type of test.
Test plans should be retained after migration or implementation into the production environment until such a time as
the application has become stable and questions concerning application testing have been satisfied. At a minimum
test plans should be kept at least for 2 cycles of the annual application review done in late summer / early fall
coinciding with fiscal year end activities.
Tests plans should be designed to answer the following two questions:
1. Does the application work as intended?
2. Can the application be broken?
Revised Feb. 2008
Enterprise Systems - UHS
Page 68 of 120
PeopleSoft Application Development Standards
9.13.1 Test Plan Template
The following is an example of a test plan template. This can easily be done in Excel.
CSR# xxxxxx CSR Title xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Developer: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Functional Analyst: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Seq#
Test Description
Revised Feb. 2008
Setup
Expected
Results
Tested By
Enterprise Systems - UHS
Test
Date
Test Results
Status
Page 69 of 120
PeopleSoft Application Development Standards
9.14 APPLICATION REVIEW
Application Review, Design Review, and Walkthrough are quality assurance tools.
The Application Review procedure is adapted from an industry accepted structured walkthrough technique described
below:
"A structured walk-through is a generic name given to review or "paper tests" conducted with peers, supervisors,
etc., to analyze the functional design, detect logic errors, develop test strategy, cross-educate team members, and
motivate full team cooperation. The verification is meant to be a non-malicious collaborative procedure for probing
and problem detection. Errors found at this level can easily be an order of magnitude cheaper to fix than at later
times in the development."
(Robert C. Tausworthe, Standardized Development of Computer Software: Part I Methods, U.S. Government,
1979.)
Much of the following information regarding the Review process is taken from the book by Daniel P. Freedman and
Gerald M. Weinberg, Handbook of Walkthroughs, Inspections, and Technical Reviews; (third edition, Boston:
Little, Brown and Company, 1982). Permission granted by the publisher.
An Application Review is conducted during application development. A Design Review is conducted before
application development begins.
9.14.1 Design Review
A Design Review is a formal review of the specs and design to ensure that the request will not compromise
application or database integrity. A Design Review considers integration processes, process flow, data flow,
efficiency, performance, etc.
A Design Review should be conducted whenever complex processes are significantly modified or new functionality
is introduced.
9.14.2 Review Procedures
When a newly approved application is defined, or significant modifications to an application are planned, the
developer must notify his supervisor to arrange an application review. Developers should not wait until the entire
application is written. Review schedules should be determined in advance (what will be reviewed and when). The
purpose of these reviews is to raise issues--not to resolve them.
Successful reviews are based on the full preparation and participation of all invited. It is mandatory that reviewers
prepare, attend, and participate when chosen for a review team. Managers should expect developers to charge time
to walkthroughs and walkthrough preparation. Project schedules must allow for this quality assurance practice.
The typical subset of the modules which make up an application should be included in the review process described
in these pages. Although all application code does not have to be formally reviewed, a second party who is familiar
with the files should examine all code that updates the database.
An experienced developer or the Technical Manager should serve as the Review Leader. The Review Leader selects
the other team members to serve as the reviewers. The team should include at least one developer with in-depth
application-specific and file-specific knowledge.
9.14.3 Walkthrough Procedures For Developers
The developer whose code is being reviewed has the following responsibilities:
1) Select the code to be reviewed (no more than ten programs for a single review) using the following guidelines:
 For small applications, the entire application or module may be selected for review.
 For large applications avoid selecting menus. Menus are routinely found to be standard.
 Select a subset of the application to be reviewed for a particular walkthrough session.
 Include batch and online processes for review.
2) Schedule the walkthrough.
3) Print out the source code and pages and report samples, and distribute to the Review Team.
Revised Feb. 2008
Enterprise Systems - UHS
Page 70 of 120
PeopleSoft Application Development Standards
4)
5)
6)
7)
8)
Secure the reviewers to the application in development.
Bring a copy of the Application Development Standards manual to all meetings.
Ensure that the meeting room is available and adequately equipped.
Notify all participants should meetings be canceled or rescheduled.
Review with your manager any additional development work required as a result of the application's
walkthrough. YOUR APPLICATION MAY NOT BE MOVED TO TEST OR PRODUCTION
WITHOUT THE CONSENT OF YOUR REVIEWERS. The reviewers may require a follow-up
walkthrough. The reviewers shall limit requests for changes to program "bugs" and to violations of the
Standards. Issues of design or performance trade-offs shall not be dictated by the reviewers when such issues
are otherwise compliant with the Standards, however, the developer should take noted issues into consideration.
Reviewers having strong feelings about such issues should work to get the Standards changed.
9) Discuss any suggested changes to Standards with the Chairman of the Application Development Standards
Committee.
10) Once all suggested changes have been made to the programs, have the reviewers sign and date the modification
form prepared by the Recorder. The form will go to your manager. If reviewers choose to record comments in
the "Reasons" section of the form, they must be very specific. Simple general comments like "as discussed in
the meeting" are not acceptable.
9.14.4 Review Leaders
While the success of the review is the responsibility of each team member, the Review Leader has these additional
responsibilities:
1)
Guide the tone and pace of the review meetings;
2)
Ensure that everyone has an opportunity to contribute;
3)
Poll for consensus;
4)
Terminate a meeting in case of lack of preparation by or absence of reviewer, length of meeting, tone of the
review, etc.
9.14.5 Review Recorder
The Recorder also has obligations beyond being prepared, attending and participating in the review. These include:
1)
Record the findings of the walkthrough committee on the appropriate form;
2)
Ensure that the group has reached a definite conclusion by reviewing the issues as recorded;
3)
Be able to write notes in "real" time as this may influence the pace of the review;
4)
Retain review notes until the application and/or the programs under review have been approved for transfer to
Production.
9.14.6 Review Participants
The following list of rules and guidelines applies to all review participants:
1)
Be prepared (review materials in advance, bring them to the review with a copy of standards);
2)
Be willing to associate;
3)
Watch your language;
4)
Raise issues and make suggestions;
5)
Avoid sidebar discussions;
6)
Stick to standards -- or get the standard changed;
7)
Record all issues in public;
8)
Stick to technical issues;
9)
Remember education (this is the major long-term benefit of reviews);
10) Do not evaluate the developer;
11) Distribute the report as soon as possible;
12) Let the developer determine when the application is ready for review;
13) Failure to attend or lack of preparation for the review is causes for the review leader to cancel the review
meeting.
9.14.7 Walkthrough Procedures For Supervisors
The review process is a review among peers.
From a Supervisory point of view the objective of these reviews is to:
1)
Move quality-control responsibilities to the program developers doing the work;
Revised Feb. 2008
Enterprise Systems - UHS
Page 71 of 120
PeopleSoft Application Development Standards
2)
3)
4)
5)
Cross-educate developers so that development activities and progress are observed and understood by all team
members;
Focus individual creative energies upon the users' unique application needs rather than upon issues common
among users and already addressed by the Standards;
Develop a highly-motivated community of application development professionals supporting one another to
build integrated yet diverse applications within one consistent environment;
Determine whether a newly developed application meets Standards for transfer to production. AN
APPLICATION MAY NOT BE MOVED TO TRAINING OR PRODUCTION WITHOUT THE
CONSENT OF REVIEWERS. A standards compliance certification form must be signed by reviewers and
kept on file with Technical Services.
Revised Feb. 2008
Enterprise Systems - UHS
Page 72 of 120
PeopleSoft Application Development Standards
WALKTHROUGH MODIFICATION FORM
APPLICATION:__________________________________________
DEVELOPER: ___________________________________________
CHECK ONE: ___ Design Review ___ Code Review
PAGE ___ OF ____
DATE: __________
DATE
PROGRAM
MODIFICATION
COMPLETED
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
____________
_________________________________________________________
_______________
___________________ ____________________ ___________________ ___________________
DEVELOPER
Revised Feb. 2008
LEADER
RECORDER
Enterprise Systems - UHS
MEMBER
Page 73 of 120
PeopleSoft Application Development Standards
10. PROJECT STANDARDS
10.1 STATE REQUIREMENTS
As of Nov 11, 2007, TAC 216 requires all Texas institutions of higher education to have a Project Management
policy, a project categorization method, and to have a standard for each of the Project Management Institute’s 9
Knowledge Areas:
1.
Integration Management
2.
Scope Management
3.
Time Management
4.
Cost Management
5.
Quality Management
6.
Human Resource Management
7.
Communications Management
8.
Risk Management
9.
Procurement Management
Project Charter, Change Log, Project Closure
Process
Scope Definition, Work Breakdown Structure,
Milestones
Planned Schedule, Actual Schedule, Planned vs.
Actuals Variances
Cost Estimate, Budget, Estimate vs. Actuals
Variances
Testing Plan, Test Cases, Pilot Plan, Change
Requests
Resource Assignments; Project Team Processes,
such as Project Kickoff Meeting
Project Web Site, Communication Plan, Issue Log,
Change Log
Risk Management Plan: Risks Identified,
Monitored, and Controlled
Procurement Process, Procurement documents,
Contracts
10.2 UH REQUIREMENTS
In compliance with state requirements, the University of Houston requires common project methodology to be used
throughout its Information Technology department. Developing project methodology and policy is underway at the
date of this document update. (Feb. 14, 2008)
Projects are placed into one of the following three categories:
Top Tier, Tier 1
1. Projects identified in the annual Preliminary Plan and Budget Report submitted to Academic Affairs.
2. Top Tier Application Projects; i.e., projects relating to PeopleSoft or WebCT.
3. Projects with budgets of $100,000 or more.
4. Legal Compliance / Mandated high impact, high visibility projects that will affect customers.
5. Other emerging high impact, high visibility, time-vital projects – upon request by the sponsoring AVP or
CIO.
Tier 1 Projects are loaded into Enterprise Project Manager (EPM), a MicroSoft software tool used for managing
projects.
Top Tier, Tier 2
1. Projects with a line item in the IT Budget that do not qualify to be categorized as a Tier 1 project.
Tier 2 Projects are loaded into EPM.
Top Tier, Tier 3
1. All other projects, primarily small operational projects funded by ongoing operations budgets.
Revised Feb. 2008
Enterprise Systems - UHS
Page 74 of 120
PeopleSoft Application Development Standards
10.2 TOP TIER PROJECT PRACTICES
Projects that are being tracked as Tier 1 and Tier 2 should include
1.
A Project Charter to define and obtain approval for the project’s goals and objectives, business case, scope
of work, major milestones, project organization, and budget.
2.
Project Kickoff Meetings to improve resource assignments and translation of high level project charter
plans to detailed schedules that all project team members have committed to. Kickoff meetings should
include all resources named in the project charter.
3.
EPM Project to enable participation in project portfolio management activities, including monthly work
effort and budget status reporting.
4.
Project Web Site to improve team communications and visibility of use of project management best
practices, such as:
5.
Project Status to improve ongoing project communications
6.
Project Schedule or at least a Milestone Table with target dates and resource assignments
7.
Issue Log to improve project communications and faster resolution, and if necessary escalation, of project
timeline, budget, or scope issues
8.
Change Log to document changes that require rebaselining schedule, increasing budget, or changing scope.
9.
Communications Plan if project is customer-facing
10. Document Repository for reference both during the project and after the project has been closed
11. Briefings as scheduled in the monthly Project Briefing forum of project managers, program managers,
AVPs, and the CIO.
10.3 ENTERPRISE PROJECT MANAGER (EPM)
Enterprise Project Manager (EPM) is a MicroSoft product that will be used to store project documentation and
facilitate communication between various functional and technical groups. This is particularly helpful as projects
often cross organizational boundaries within both groups. Consultants and vendors may need to be included in the
project as well.
Each Top Tier 1 and 2 project will have a project web site created by the I. T. Web Project Team who will provide a
url link to the web site. They may also assist in configuring the web site as well.
The EPM web site is divided into 3 sections: left, middle and right as shown in the figure below.
Revised Feb. 2008
Enterprise Systems - UHS
Page 75 of 120
PeopleSoft Application Development Standards
Documents: Two types of Document Libraries can created under Documents:
1. Document Library to contain desktop documents such as Word or Excel
2. HTML Library to contain html documents.
The project manager can dynamically create document libraries as required.
Pictures contain Picture Libraries.
Lists contain primarily Excel lists which can be maintained either an attached Excel file, or by a datasheet editor
within the EPM tool itself.
Discussions are used to create topics and track correspondence pertaining to a particular topic. This allows
correspondence to be grouped together and prevents users from having to dig through email history to find relevant
email.
Surveys can be created to poll users to the web site.
The middle of the web site is simply documents or lists that are most frequently used. This area is can be configured
by the project manager.
The right side can also contain documents or links for quick reference.
Under links, it is possible to add a link to a MicroSoft Project. This requires that the project be created in MicroSoft
Project Professional and then migrated to the EPM project server.
For instructions on how to use the EPM web site, contact the manger of I. T. Web Project team.
Revised Feb. 2008
Enterprise Systems - UHS
Page 76 of 120
PeopleSoft Application Development Standards
10.4 PROJECT DOCUMENTATION
A project outline is provided below. Not all of the elements are required. The outline can be customized to meet the
unique needs of a project.
Projects are composed of the following phases:
1.
2.
3.
Demand Management
Project Delivery
Support
10.4.1 Demand Management
Demand Management consists of
1.
2.
Opportunities and Needs
Project Planning
Creating opportunities and need definitions and assessment
Defining the scope of the project, develop the Project Charter,
Statement of Work, Project Budget, Project Schedule, Approval
of Project, Approval of Project Funding.
10.4.2 Project Delivery
Project Delivery consists of
1.
Analysis
2.
Design
3.
Construction
4.
Testing
5.
Implementation
Developing Requirements Definitions, Communication
Requirements, documentation Requirements, Training
Requirements, and Support Requirements.
Creating Solution Design, Conversion Design, Communications
Design, Training Design, and Support Design
Solution Development, Developing Unit Test Plans, Develop
drafts for Communication, Training, and Support
Includes Pilot Training, Integration Testing, System Testing, User
Acceptance Testing and refining documentation on
Communications, Training, and Support.
Includes Readiness Assessment, Implementation Approval.
Support staff should be trained as well as end users. Post
implementation tasks include project evaluation and lessons
learned.
10.4.3 Support
Support consists of
1.
Issue Identification and
Escalation
Issues are Prioritizes. Solutions are tested and documented.
Includes Change Management and Support Development.
10.5 PROJECT DELIVERABLES
10.5.1. Opportunities and Needs Definitions
Specific opportunities and needs for project are defined. Definitions should identify groups who would benefit or be
impacted.
10.5.2. Opportunities and Needs Assessment
Each opportunities and need is assessed to determine how critical is the opportunity or need, the scope of operational
impact upon the organization and external entities, financial/budget impact upon the organization, estimated
resource requirements, etc.
Revised Feb. 2008
Enterprise Systems - UHS
Page 77 of 120
PeopleSoft Application Development Standards
10.5.3. Project Charter
The Project Charter contains the following information:
Executive Summary
Business Case
Scope of Work
Other Information
Major Milestones
Organization
Business Owners – customers who will be managing project & are most affected by the project.
Project Sponsors – individuals providing financial, material, or staff resources for the project.
Program Manager – individual responsible for functional organization and ultimate accountability for the
project.
Project Manager – person responsible for managing the project’s activities and deliverables.
Team Members – individuals or roles needed on the team.
Stake Holders – individuals or organizations who may be impacted by the project.
Summary Budget
Project Budget
Recurring Costs Budget
Approvals
Business Owner
Project Sponsor(s)
Program Manager
Project Manager
Project templates can be provided by the I.T. Project Team.
10.5.4 Communication Plan
 How will correspondence specific to the project be communicated to team members, project members, user
community, external entities, etc.?\
 What forms of communication need to take place and for which groups? (newsletters, newspapers, emails,
discussion forums, list servs, etc.)
10.5.5. Documentation Plan
 Where will documentation reside?
 What directory structures need to be created and how will they be designed for easy navigation?
 Which documents are required? (Project charter, project issues, major milestones, analysis documentation,
functional specs, technical specs, business process specs, etc.)
 What form will documents be retained (Word, PDF, Excel, PowerPoint, etc.)
 Are standardized form documents required?
 Is a project web site required?
 How will revisions to the project be documented?
 How will approvals be documented?
10.5.6. Training Plan
Separate Training plans may be required for the following groups of people:
 Project team
 Analysis Team
 Development Team
 Testing Team
 Support Team
 End users
Revised Feb. 2008
Enterprise Systems - UHS
Page 78 of 120
PeopleSoft Application Development Standards
The training plan addresses
 What groups need to be trained?
 What type of training will each group required?
 Who will conduct training?
 What training materials are required?
 What training media should be used (computer based training (CBT), instructor led training, webcasts, etc.)
 Is external training required?
 What are the costs associated with training?
10.5.7 Support Plan
The Support Plan addresses issues of providing continual support after the project is implemented.
 How will support issues be reported and to whom?
 How will support issues be documented?
 How will support issues escalate in priority?
 Where should support staff be located?
 What tools or equipment will support staff require?
 What training will support staff need?
10.6 PROJECT TEMPLATES
Templates for project documents and deliverables can be found at
\\uhsa1\it-managers
10.7 PROJECT STANDARDIZATION PROCESS
The following diagram illustrates the proposed Project Standardization Process.
Revised Feb. 2008
Enterprise Systems - UHS
Page 79 of 120
PeopleSoft Application Development Standards
11. SECURITY
11.1 BACKDOOR POLICY FOR PRODUCTION AND REPORTING DATABASES
Backdoor access to production databases is limited to developers, technical managers and DBAs. Backdoor access
may be provided to 3rd party application databases but require approval and continual supervision by the technical
application support managers. No functional person will have backdoor access to the database.
Developers and technical managers will have read-only access to the production databases. Access to a nonproduction database will be determined by the technical managers and access granted through the DBA group. If a
production object needs to be updated via the backend, the developer will request the change via STAT and the
DBA will execute the change. If the expected results of the script do not match the migration form results, the DBA
will inform the developer/technical manager and the DBA will not commit the change to the production database
until the requestor has validated the results.
11.2 ACCESS TO UNIX AND NT ENVIRONMENTS
Access to UNIX environments will be granted to UNIX administrators and DBAs only. Access to NT environments
is limited to NT administrators only.
11.3 DATABASE LINKS
When technically feasible, database links may be created between the PeopleSoft applications (Human Resources,
Student Administration, and Financials), PeopleSoft databases (SA and FS), and external systems (UHCL, UHD,
and UHV). Database links are created by the Lead DBA and require approvals from a director..
NOTE: Remote campus technical staff is responsible for testing their database links when patches or upgrades are
applied to the PeopleSoft environments. This is crucial whenever there are structural changes to PeopleSoft
application data tables.
11.4 USERID
User ID creation and creation of the initial temporary password is an automated process for HR and SA applications.
HR has a custom process which runs nightly to create new userids for new employees. New userids are not created
for returning employees, retirees, or for students or persons of interest who are becoming employees.
The HR create userid process assigns one security role to allow the employee access to employee self-service –
P.A.S.S. An email is sent to the employee notifying them of their new userid and temporary password.
The SA application uses a PeopleSoft delivered process called mass change to create new userids for students. It
does not create a userid if the person already exists in the system. It assigns default roles for self-service access.
The security administrator for the FS application manually creates new userids in FS.
The PeopleSoft Security Administrators are responsible for running the HR and SA nightly processes.
The HR nightly process also resets the description on userprofile to match the person’s primary name in PeopleSoft.
This is done to facilitate searches for a person’s userid.
Revised Feb. 2008
Enterprise Systems - UHS
Page 80 of 120
PeopleSoft Application Development Standards
11.5 PASSWORD SECURITY
11.5.1. Password Controls
The following password controls are in place on the Portal Databases. Password controls have been removed from
the application databases. The Portal Database is used to authenticate the user to the PeopleSoft Applications.
11.5.2. Changing Passwords
After the user receives their new User ID and password, it is their responsibility to change the password.
New users should have read and signed the University of Houston Confidentiality Statement Guidelines. The
PeopleSoft Security Administrator will keep a signed confidentiality statement on file for each user that has been
given access to PeopleSoft applications.
Revised Feb. 2008
Enterprise Systems - UHS
Page 81 of 120
PeopleSoft Application Development Standards
Password changes
are made by
clicking on “My
System Profile”
on the main menu.
Next, click on
“Change
password”
Revised Feb. 2008
Enterprise Systems - UHS
Page 82 of 120
PeopleSoft Application Development Standards
Enter old and new
passwords as
indicated.
Revised Feb. 2008
Enterprise Systems - UHS
Page 83 of 120
PeopleSoft Application Development Standards
11.5.3. Forgotten Password Functionality
Forgotten password functionality has been added to PeopleSoft applications to allow users to request new temporary
passwords at their convenience. The password will be emailed to the address which appears under their security
profile.
11.5.3.1. Password Hints
Password hints are used in forgotten password functionality. Password hint questions and answers may be changed
by the end user as follows:
Password hints
may be changed
by clicking on
“My System
Profile” on the
main menu.
Revised Feb. 2008
Enterprise Systems - UHS
Page 84 of 120
PeopleSoft Application Development Standards
Click on “Change
or set up forgotten
password help.”
Select which
question is to be
asked by clicking
on the down arrow
of the list box.
Then enter the
answer to the
question under
response. The user
will be expected
to enter the
response when
using forgotten
password.
Revised Feb. 2008
Enterprise Systems - UHS
Page 85 of 120
PeopleSoft Application Development Standards
11.5.3.1. Using Forgotten Password
Click on “Request
A New Password”
on the PeopleSoft
logon page.
Enter your userid
and click
“Continue”
Enter the answer
to the password
hint and click on
“Email New
Password”.
Revised Feb. 2008
Enterprise Systems - UHS
Page 86 of 120
PeopleSoft Application Development Standards
An email with the
new password will
be emailed to the
user.
Revised Feb. 2008
The new password is app messaged from the application database to
the portal database. This normally takes one minute, but if the queue is
backed up, it could take several hours.
Enterprise Systems - UHS
Page 87 of 120
PeopleSoft Application Development Standards
11.6 ROLES, PERMISSIONS, AND ROW LEVEL SECURITY
Creation or modification of roles, permission lists, and row level security is the responsibility of the functional
managers. Setting up and assignment of roles and permission lists in the PeopleSoft applications is the
responsibility of the PeopleSoft Security Administrator. Setting up and assignment of row level security is the
responsibility of the campus security administrators.
11.7 QUERY SECURITY
By default, when you give Query users access to a record component, they have access to all the rows of data in the
table built using the associated record definition. In cases where users need to be restricted from seeing some of
those data rows, you want to enforce row-level security. With row-level security, users can have access to a table
without having access to all rows on that table. This type of security is typically applied to tables that hold sensitive
data. PeopleSoft applications implement row-level security by using a SQL view that joins the data table with an
authorization table. You implement row-level security by having Query search for data using a query security
record definition. The query security record definition adds a security check to the search. Query security record
definitions serve the same purpose as search record definitions do for panels. Just as a panel's search record
definition determines what data the user can display in the panel, the query security record definition determines
what data the user can display with Query. To get Query to retrieve data by joining a security record definition to
the base table, you specify the appropriate Query Security Record when you create the base table's record definition.
For additional information and detailed navigation to setup Query Security, please refer to PeopleBooks.
11.8 DEVELOPER AND FUNCTIONAL ACCESS MATRIX
DB
DEV
TST
PRD
RPT
Navigation
Full
Role/User
specific
Role/User
specific
Role/User
specific
Revised Feb. 2008
Developers
Application
Full
PeopleTools
Full
Read-Only
Read-Only
Read-Only
Read-Only
Read-Only
Read-Only
Navigation
Full
Role/User
specific
Role/User
specific
Role/User
specific
Enterprise Systems - UHS
Functional Users
Application
Full
PeopleTools
Read-Only
Role/User specific
Read-Only
Role/User specific
No
Role/User specific
No
Page 88 of 120
PeopleSoft Application Development Standards
12. DOCUMENTATION
Recommended practices for each type of documentation within the PeopleSoft environment are discussed below.
12.1 USER’S GUIDE
The user’s guide is generally written by the functional users or the user department. User's guides are organized like
"how to" manuals. They should include:
1) Purpose and Function - a general, descriptive overview;
2) How to Use - specific instructions on how to use the application, organized according to desired results;
3) Job Processes - a detailed description of the steps required to complete multi-job processes such as grading or
monthly closings, including restart and recovery information;
4) Tips (optional); and
5) Examples (optional).
SA
Student user guides are created by functional analysts. Contact the functional analyst to obtain a copy.
Financial Practices
General Public Departmental User Guides – Originals are developed and maintained by UHS functional staff and
distributed to each campus for review and use. For UH and UH – System Administration, this type of documentation
is published and available via the following web site: www.uh.edu/finance within the References heading. UH –
Clearlake, UH – Downtown and UH – Victoria may take the originals and modify the originals for their purposes
and following their specific campus guidelines for publishing this type of documentation.
Processing Department specific User Guides – Originals are developed and maintained by each campus specific
processing department (i.e. Purchasing, Accounts Payable, General Accounting, etc…) with assistance as needed
from UHS functional staff. Each campus specific processing department will follow their guidelines with regards to
publishing this type of documentation, also known as Processing Department Desk Manuals.
HR Practices
User documention is developed and maintained by Functional users at
P:\Project Team\HRMS\
12.2 TECHNICAL REFERENCE
The technical reference is written by the application developer who developed the software changes. It is written to
provide details and nuances of the process to assist any programmer coming behind. This includes, but is not
limited to, comments associated with every new field, record, panel, etc. added to the application, and comments
added throughout any SQR, COBOL, or PeopleCode change.
Functional and technical user documentation is commonly stored on the “P” drive which is mapped to
\\psuh1\psdev$
Current location of Student Admin documentation:
P:\Project Team\UHCL PS8 Student Admin\Technical Documentation
Current location of HRMS documentation:
P:\Project Team\Hrms\Technical Documentation
Current location of Financials documentation:
P:\Project Team\Finance_R1
Revised Feb. 2008
Enterprise Systems - UHS
Page 89 of 120
PeopleSoft Application Development Standards
12.3 OPERATIONS GUIDE
The Operations Guide is a technical policy and procedures guide for the PeopleSoft technical environment. The
Operations Guide addresses maintenance and operations of the PeopleSoft infrastructure (hardware and software),
application maintenance, change management, customer support, security, and training.
The operations guide can be located at the following url link:
http://www.uh.edu/infotech/php/template.php?nonsvc_id=557
12.4 APPLICATION DEVELOPMENT STANDARDS
The Application Development Standards is described in this document. It is not intended to duplicate, supplement,
or replace policies and procedures contained within the Operations Guide. The purpose of the Applications
Development Standards is to provide a common methodology for application software development across all
PeopleSoft applications.
The Application Development Standards document can be located at the following url link:
http://www.uh.edu/infotech/php/template.php?nonsvc_id=557
12.5 IN-CODE DOCUMENTATION
Reference Chapter 8 for documentation standards for programming objects such as SQR, COBOL, Crystal Reports,
etc.
12.6 UHS FORMS
Detail information on project and migration forms can be found in Chapter 7.
12.7 PEOPLEBOOKS
PeopleBooks are documentation delivered with the PeopleSoft products. They are available online through the Help
menu item. PeopleBooks should not be updated directly, since they are replaced with new releases from PeopleSoft.
Additional documentation should be included in the user’s guide or the technical reference.
The direct link to PeopleBooks is located at
http://www.uh.edu/infotech/php/template.php?nonsvc_id=557
12.8 PEOPLETOOLS OBJECT DEFINITIONS
PeopleTools Objects are the building blocks of the PeopleSoft databases and applications. PeopleTools applications
provide create/maintain/view access to these objects, and thus they can be considered self-documenting. Developers
should fill in the description / comments fields of objects. Reference the section on naming conventions for internal
objects.
12.8.1 Object Inventory
In addition to the PeopleTools Applications, view-only object access is provided by the custom "Object Inventory"
application. This provides an interface better suited to end-users or management and is accessible via the intranet
(PS 8 UHPRD database) at
https://my.uh.edu:7025/psp/uhprd/?cmd=login&languageCd=ENG
Revised Feb. 2008
Enterprise Systems - UHS
Page 90 of 120
PeopleSoft Application Development Standards
12.8.1 Application Designer
All Application Designer objects have properties (File – Object Properties) consisting of Description, Comments,
Owner-id, Last Updated Date/Time, Last Updated User. Enter the Description and Comments on all custom objects
and update the Comments on all modified delivered objects. Comments should describe the purpose/function of the
object.
Note that the Edit – Find Object References feature is a quick way to find relationships between different objects.
The following list includes some of the objects which can be opened by Application Designer.
Activity
App Engine Program
Approval Rule Set
Business InterLink
Business Process
Component
Component Interface
Field – [File - Object Properties] support translate values for character fields of size 4 or less
File Layout
HTML
Image
Menu
Message
Message Channel
Message Node
Page – [View – View Page PeopleCode] supports field level edits
Project
Record – [View - Edits Display] and [View - PeopleCode Display] support field level edits
SQL
Style Sheet
12.8.2 Process Scheduler Manager
The short description field is displayed to the end user when they schedule a process and should contain a title or
description of the process that is being run.
Objects that can be defined in the Process Scheduler are shown below. The Process Scheduler objects marked "*"
have a description field.
Process Type Definitions
Process Definitions *
Job Definitions*
Recurrence Definitions *
Server Definitions *
Report Node Definitions
Job Definitions
Recurrence Definitions *
Server Definitions *
Report Node Definitions
12.8.3 Tree Manager
PeopleSoft provides delivered trees to provide organizational structure and to manage processes. Custom trees may
also be defined.
Access Group nodes have a description that can be populated under [Edit – Data]. Record nodes do not. The record
node description displayed in Tree Manager comes from the record object properties.
Revised Feb. 2008
Enterprise Systems - UHS
Page 91 of 120
PeopleSoft Application Development Standards
Tree – A description field can be populated under [Edit – Tree Definition].
12.8.4 PS Query
UHS Developers should use the description and comments area under File – Properties.
12.8.5 Cube Manager
The Cube Manager is a utility that will allow the creation of three dimensional tables and is used for drill down and
diagnostic techniques.
Cube Manager provides description fields on the following objects:
Dimensions
Definitions
Cube Instances
12.8.6 Message Catalog
The message catalog is a table providing messages which can be used for on-line and batch processes. It can be
found in PeopleTools, Message Catalog. PeopleSoft reserves message sets from 1 to 19,999. UHS message set
numbers should be 20,000 or higher.
The Message Catalog provides a description field within the Message Set.
12.9 OTHER DELIVERED DOCUMENTATION
Entity Relationship Diagrams and Business Process Diagrams can be found in PeopleSoft Customer Connection.
12.10 PROJECT / ASSIGNMENT TRACKING
A project is an encapsulation of PeopleTools objects comprising a logical work set. Application Designer projects
facilitate project assignment tracking. Where practical, each App Designer Project should represent one assignment
(mod or customization). Unrelated assignments should not be mixed together in the same Project. Subsequent
assignment modifications to production objects should be placed in a new project. As noted above for App Designer
objects, the Description and Comments fields should always be filled in (File - Project Properties).
12.11 MODIFIED OBJECTS LIST
This tool helps the user to track objects created by developers at UH and the objects delivered by PeopleSoft. This
tool describes the details about the object and the objects that are referenced by that particular object. From the
SAHR production database, developers and DBAs can search and obtain information for PeopleSoft internal objects
defined on various databases. Currently the objects that are searchable are Projects, Menus, Components, Pages,
Records, and Fields.
Databases
The databases that are included in the tool are
Financial System
1. UHDEV
2. UHTST
3. UHPRD
4. FSDEV
5. FSTST
6. FSPRD
7. FS8DEV
8. FS8TST
9. FS8PRD
Student/HR System
1. SADEV
2. SATST
3. SAPRD
4. SA8DEV
Revised Feb. 2008
Enterprise Systems - UHS
Page 92 of 120
PeopleSoft Application Development Standards
5.
6.
SA8TST
SA8PRD
Search Criteria
Selecting the Object Cross reference in the Object Inventory menu will display the homepage that contains links that
the user can select depending upon which objects he/she wants to search upon. Depending upon the objects the links
are named say,
Search
Projects
Menus
Components
Pages
Records
Fields
Click
Project
Menu
Component
Page
Record
Field
After the user selected the initial search criteria the user will be prompted to limit the search based upon four criteria
1.
2.
3.
4.
Object Name
(partial/full name of the object)
Database
(partial/full name of the database)
System Name
(partial/full name of the system)
Last Update User ID (partial/full name of the User who
last updated the object)
Revised Feb. 2008
Enterprise Systems - UHS
Page 93 of 120
PeopleSoft Application Development Standards
The system name denotes the basic purpose of the database whether it is a Student/HR database or Financial
database so the existing system names
System Name
Student/HR
Financial
Name
Student
Financial
Search Projects
User who wants to search projects should click on Projects in the homepage. Enter the additional search criterion
which restricts the projects which you are searching. A grid box populates with all the projects matching your
criteria. Select the desired project to find its detailed description.
Revised Feb. 2008
Enterprise Systems - UHS
Page 94 of 120
PeopleSoft Application Development Standards
After a particular project has been selected, a page with number of tabs opens up. Each tab signifies
Project
Menu
Component
Page
Record
Field
Details about the project selected
Lists the menus that are included in this project
Lists the Components that are included in this project
Lists the pages that are included in this project
Lists the records that are included in this project
Lists the fields that are included in this project
The Associated External files in the project tab lists all the external objects that are included in this project like
COBOL’s, SQR’s, etc... If you want to go any specific object with in the project (say you want to know the details
about a particular menu/component... within the project). Select the particular Objects tab (say Menu Tab). The grid
provides a GOTO button for each object which takes you to that particular object.
Revised Feb. 2008
Enterprise Systems - UHS
Page 95 of 120
PeopleSoft Application Development Standards
The Home link on each page takes you to the Object Inventory home page.
Revised Feb. 2008
Enterprise Systems - UHS
Page 96 of 120
PeopleSoft Application Development Standards
Search Menus
Users who want to search menus should click on Menu in the homepage. Enter the additional search criterion which
restricts the menus which you are searching. A grid box populates with all the menus matching your criteria. Select
the desired menu to find its detailed description.
After a particular menu has been selected, a page with number of tabs opens up. Each tab signifies
Menu
Component
Project
Describes the selected menu
Lists the components that are included in this menu
Lists the projects that contain this menu
If you want to go to particular component/project within the menu select the Component/Project tab and click the
GOTO button for the desired object.
Search Components
Users who want to search components should click on Component in the homepage. Enter the additional search
criterion which restricts the components which you are searching. A grid box populates with all the components
matching your criteria. Select the desired component to find its detailed description.
Revised Feb. 2008
Enterprise Systems - UHS
Page 97 of 120
PeopleSoft Application Development Standards
After a particular component has been selected, a page with number of tabs opens up. Each tab signifies
Component
Page
Project
Describes the selected component
Lists the pages that are included in this component
Lists the projects that contain this component
If you want to go to particular page/project within the component select the Page/Project tab and click the GOTO
button for the desired object.
Search Pages
Users who want to search pages should click on Page in the homepage. Enter the additional search criterion which
restricts the pages which you are searching. A grid box populates with all the pages matching your criteria. Select
the desired page to find its detailed description.
Revised Feb. 2008
Enterprise Systems - UHS
Page 98 of 120
PeopleSoft Application Development Standards
After a particular page has been selected, a page with number of tabs opens up. Each tab signifies
Page
Record
Field
Project
Describes the selected Page
Lists the records that are accessed in this page
Lists the fields that are accessed in this page
Lists the projects that contain this page
If you want to go to particular record/field/project within the page select the Record/Field/Project tab and click the
GOTO button for the desired object.
Search Records
Users who want to search records should click on Record in the homepage. Enter the additional search criterion
which restricts the records which you are searching. A grid box populates with all the records matching your criteria.
Select the desired record to find its detailed description.
Revised Feb. 2008
Enterprise Systems - UHS
Page 99 of 120
PeopleSoft Application Development Standards
After a particular record has been selected, a page with number of tabs opens up. Each tab signifies
Record
Field
Project
Describes the selected record
Lists the fields that are contained in this record
Lists the projects that contain this record
If you want to go to particular field/project within the record select the Field/Project tab and click the GOTO button
for the desired object.
Search Fields
Users who want to search fields should click on Field in the homepage. Enter the additional search criterion which
restricts the fields which you are searching. A grid box populates with all the fields matching your criteria. Select the
desired field to find its detailed description.
Revised Feb. 2008
Enterprise Systems - UHS
Page 100 of 120
PeopleSoft Application Development Standards
After a particular field has been selected, a page with number of tabs opens up. Each tab signifies
Field Definition
Names
Translate values
Project
Describes the selected field
Lists all the valid names for that field
If exists, lists the translate values for that field
Lists the projects that contain this field
If you want to go to particular project within the field select the Project tab and click the GOTO button for the
desired object.
13. PERIODIC REVIEW
Enterprise Systems shall review and update the Application Development Standards document annually.
Revised Feb. 2008
Enterprise Systems - UHS
Page 101 of 120
PeopleSoft Application Development Standards
14. READER’S COMMENTS
Your feedback is important. Your comments allow us to maintain the standards for supporting administrative
computing for the University of Houston Systems.
Did you find this manual understandable, usable, and well organized? Please make suggestions for improvement.
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
Did you find errors in this manual? If so, specify the error and the page number.
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
Please indicate the type of user/reader that you most nearly represent:
 Systems administrator for Unix or Windows 2000
 Professional developer, systems analysis, project manager
 Student developer
 User with programming experience
 User with little programming experience
 Other (please specify) ______________________________________________________________
Name: __________________________________________________ Date: _______________________
Campus/Department: __________________________________________________________________
Mail Address:
___________________________________________________________________________________
___________________________________________________________________________________
___________________________________________________________________________________
Phone: _____________ Email Address: ___________________________________________________
Forward all comments to
UH Application Development Standards Chair
Enterprise Systems
5000 Gulf Fwy Bldg. 3, Rm 250
Houston, Texas 77204-0933
Phone: 713-743-1420 Fax: 713-743-1424
Revised Feb. 2008
Enterprise Systems - UHS
Page 102 of 120
PeopleSoft Application Development Standards
APPENDIX A: Modification Log
Version
V1 d25
V1 d26
Chapter/
Section
V1 d27
4.3
V2 d1
V3
7.0
All
V9
7.2
Revised Feb. 2008
Description
App Dev Standards Published
Added section 9
Deleted section 5.5 back door policy. Modified under
section .
Numerous corrections throughout document
Added AET as a suffice for app engine state records and
added section 4.5.4 pertaining to same.
Numerous changes to include use of STAT
App Dev Standards review by App Dev Standards
Committee.
Added section for Failed Migrations To Production
Enterprise Systems - UHS
Made By
JML
JML
JML
Date
12/1/03
1/12/04
1/12/04
JML
JML
1/12/04
4/19/04
JML
JML
8/1/06
2/7/08
JML
9/9/08
Page 103 of 120
PeopleSoft Application Development Standards
APPENDIX B - Glossary
API
Application Programming Interface. This is the interface between PeopleSoft batch
processes running on the Process Scheduler and the Process Monitor. The API
updates the process status.
Is a term which refers to functionality, code, or objects which are added to
PeopleSoft delivered functionality, code, or objects.
Customization refers to any “bolt-on” changes to PeopleSoft applications. These
would include new objects created by UHS application developers.
Bolt-On
Customization
Delivered
Enhancement
Modification
Integration Testing
PIA
SOA
SQA
Refers to PeopleSoft delivered internal and external objects.
Refers to any improvement to the delivered product either by modification or
customization.
Modification refers to modifying a PeopleSoft delivered functionality, code, or
object.
Integration testing is testing a process and all upstream and downstream processes
that are affected by or related to that process. These other processes may include
data interfaces with other PeopleSoft applications or 3 rd party applications.
PeopleSoft Internet Architecture. PIAs often refer to the various setup and
configuration required to run PeopleSoft on the web.
Service Oriented Architecture. This refers to the overall application design to be
engineered towards meeting the service needs of the users.
Software Quality Assurance. Refers to the standards and practices to ensure
software quality assurance to the end user.
System testing refers to testing all functionality, both delivered and bolt-on. It
incorporates integration testing as part of the system test.
Unit testing refers to testing an individual process or function.
User acceptance test is the final testing to be conducted by end users who use the
application.
Is a term to reference using PeopleSoft out of the box as delivered without
modification or customization.
System Testing
Unit Testing
User Acceptance
Testing
Vanilla
APPENDIX C - Abbreviations
ABBR
AC
ACAD
ACCT
ACT
ACTN
ADD
ADDR
ADM
AMT
ANNL
APPL
ARC
ASSO
ATTMPT
AUTH
BAC
BAF
ABBREVIATION
ADDRESS CONVERTER
ACADEMIC
ACCOUNT
ACTIVITY
ACTION
ACCIDENTAL DEATH AND DISABILITY
ADDRESS
ADMISSIONS
AMOUNT
ANNUAL
APPLICATION
ARCHIVE
ASSOCIATOR
ATTEMPTED
AUTHORIZATION
BACK
BUSINESS AFFAIRS
Revised Feb. 2008
Enterprise Systems - UHS
Page 104 of 120
PeopleSoft Application Development Standards
BAL
BEN
BIL
BLDG
BOT
BAT
BTH
BUD
BUS
CAL
CAND
CBE
CD
CHG
CHRG
CIT
CLASSIF
CMP
CNT
CTRL
CNTR
CNTY
COL
COLL
CWVR
CORRES
CRD
CRS
CTR
CTRY
CTY
CURR
CY
CYTD
DBT
DD
DECIS
DEL
DELINQ
DELIV
DEMO
DEPT
DEPTID
DESC
DTL
DEV
DISC
DISP
DLY
DOC
DT
DTH
EFFTV
BALANCE
BENEFITS
BILL
BUILDING
BOTTOM
BATCH
BIRTH
BUDGET
BUSINESS
CALCULATE
CANDIDACY
CREDIT BY EXAMINATION
CODE
CHANGE
CHARGE
CITATION
CLASSIFICATION
CAMPUS
COUNT
CONTROL
CENTER
COUNTY
COLLEGE
COLLECTIONS
CONTRACT & WAIVER
CORRESPONDENCE
CREDIT
COURSE
COUNTER
COUNTRY
CITY
CURRENT
CALENDAR YEAR
CALENDAR YEAR TO DATE
DEBIT
DAY
DECISION
DELETE
DELINQUENCY
DELIVERY
DEMOGRAPHICS
DEPARTMENT
DEPARTMENT ID
DESCRIPTION
DETAIL
DEVELOPMENT
DISCARD
DISPLAY
DAILY
DOCUMENTATION
DATE
DEATH
EFFECTIVE
Revised Feb. 2008
Enterprise Systems - UHS
Page 105 of 120
PeopleSoft Application Development Standards
EMPL
EMPLID
ENGL
ENRL-CD
ENRL
ERS
ETHN
ETS
EXEC
FED
FIN
FLD
FLG
FWD
FRMR
FS
FY
FYTD
GEN
GL
GMAT
GPA
GRAD
GRAD
GRD
GRE
GRP
HDR
HH
HIST
HLP
HLTH
HR
HRIS
HRMS
HS
ID
IDX
INFO
INIT
INSTL
INST_ADV
INTL
INV
LEDG
LFT
LIC
LOC
LSAT
LTD
LTR
LVL
MAINT
EMPLOYEE
EMPLOYEE ID
ENGLISH
ENROLLMENT CODE
ENROLLMENT
EMPLOYEE RETIREMENT SYSTEM
ETHNICITY
EDUCATIONAL TESTING
EXECUTIVE
FEDERAL
FINANCIAL
FIELD
FLAG
FORWARD
FORMER
FINANCIAL SYSTEMS
FISCAL YEAR
FISCAL YEAR TO DATE
GENERAL
GENERAL LEDGER
GRADUATE MANAGEMENT
GRADE POINT AVERAGE
GRADUATE
GRADUATION
GRADE
GRADUATE REQUIREMENT
GROUP
HEADER
HOUR
HISTORY
HELP
HEALTH
HUMAN RESOURCES
HUMAN RESOURCE INFORMATION SYSTEM
HUMAN RESOURCES MANAGEMENT SYSTEM
HIGH SCHOOL
IDENTIFIER
INDEX
INFORMATION
INITIALIZE
INSTALLMENT
INSTITUTIONAL ADVANCEMENT
INTERNATIONAL
INVOICE
LEDGER
LEFT
LICENSE
LOCATION
LAW SCHOOL ADMISSION TEST
LONG TERM DISABILITY
LETTER
LEVEL
MAINTENANCE
Revised Feb. 2008
Enterprise Systems - UHS
Page 106 of 120
PeopleSoft Application Development Standards
MAJ
MTH
MAX
MGT
MIN
MINR
MM
MM
MO
MOR
MSG
MTD
MTH
MTHLY
NATL
NBR
NCAA
NME
NXT
OFC
OFCR
OPT
ORD
ORP
PAR
PAY
PD
PER
PGM
PHONE
PIN
PMT
PO
POS
PRCS
PRD
PREV
PRF
PRGE
PRK
PROC
PROD
PRT
PUR
QTD
RAR
REF
REG
REG
REP
REQST
REQT
RESP
MAJOR
MATHEMATICS
MAXIMUM
MANAGEMENT
MINIMUM
MINOR
MINUTES
MONTH
MONTH
MORE
MESSAGE
MONTH-TO-DATE
MONTH
MONTHLY
NATIONAL
NUMBER
NATIONAL COLLEGIATE ATHLETICS ASSOCIATION
NAME
NEXT
OFFICE
OFFICER
OPTIONAL
OFFICIAL REPORTING D
OPTIONAL RETIREMENT PLAN
PERSONNEL ACTION REQUEST
PAYROLL
PAID
PERSONNEL
PROGRAM
TELEPHONE
PERSONAL IDENTIFICATION NUMBER
PAYMENT
PURCHASE ORDER
POSITION
PROCESS
PRODUCTION
PREVIOUS
POSITION REQUEST FORM
PURGE
PARKING
PROCEDURE
PRODUCTION
PRINT
PURCHASING
QUARTER-TO-DATE
REGISTRATION AND ACA
REFERENCE
REGISTRATION
REGULAR
REPLY
REQUEST
REQUIREMENT
RESPONSIBILITY
Revised Feb. 2008
Enterprise Systems - UHS
Page 107 of 120
PeopleSoft Application Development Standards
RET
RGT
ROTC
RPT
RST
RST
RTN
SAA
SAT
SCHED
SCHOL
SECT
SEL
SEM
SESS
SFA
SMRY
SPCL
SPR
SRC
SRCH
SRVC
SS
SSN
ST
STAT
ST
STAT
STD
STD
STP
STU
SUBM
SUBM
SUBS
SUM
SUM2
SUM3
SUM4
SUM1
SUPPL
SUSP
SW
SYS
T
TASP
TBL
TDA
TECH
TEST
TMP
TOEFL
TOT
RETURN
RIGHT
RESERVE OFFICER TRAINING CORP
REPORT
RESET
RESTART
ROUTINE
STUDENT ACADEMIC AND ADMINISTRATION
SCHOLASTIC APTITUDE TEST
SCHEDULE
SCHOLARSHIP
SECTION
SELECT
SEMESTER
SESSION
SCHOLARSHIPS AND FININCIAL AID
SUMMARY
SPECIAL
SPRING
SOURCE
SEARCH
SERVICE
SECONDS
SOCIAL SECURITY NUMBER
STATE
STATUS
STREET
STATISTICS
STANDARD
SHORT TERM DISABILITY
STOP
STUDENT
SUBMISSION
SUBMIT
SUBSIDIARY
SUMMER
SUMMER II
SUMMER III
SUMMER IV
SUMMER I
SUPPLEMENT
SUSPENSE
SWITCH
SYSTEM
TENTHS OF A SECOND
TEXAS ACADEMIC SKILL
TABLE
TAX DEFERRED ANNUITY
TECHNICAL
TESTING
TEMPORARY
TEST OF ENGLISH AS A FOREIGN LANGUAGE
TOTAL
Revised Feb. 2008
Enterprise Systems - UHS
Page 108 of 120
PeopleSoft Application Development Standards
TRACK
TRAIN
TRANCODE
TRN
TRNSCPT
TRS
TUIT
UH
UHC
UHD
UHS
UHV
VA
VCHR
VET
VIOL
WIP
WKLY
WPE
WTHDRW
XFER
XMIT
YRLY
YTD
YY
YYYY
TRACKING
TRAINING
TRANSACTION CODE
TRANSACTION
TRANSCRIPT
TEACHER RETIREMENT SYSTEM
TUITION
UNIVERSITY OF HOUSTON CENTRAL
UNIVERSITY OF HOUSTON CLEAR LAKE
UNIVERSITY OF HOUSTON DOWN TOWN
UNIVERSITY OF HOUSTON SYSTEMS
UNIVERSITY OF HOUSTON VICTORIA
VETERAN'S ADMINISTRATION
VOUCHER
VETERAN
VIOLATION
WORK IN PROCESS
WEEKLY
WRITING PROFICIENCY
WITHDRAWAL
TRANSFER
TRANSMIT
YEARLY
YEAR-TO-DATE
YEAR – 2 DIGIT
YEAR – 4 DIGIT
Revised Feb. 2008
Enterprise Systems - UHS
Page 109 of 120
PeopleSoft Application Development Standards
APPENDIX D – CUSTOMER CONNECTION ROADMAPS AND SCHEDULES
PeopleSoft’s Roadmaps and Schedules provides a project of expected delivery dates for PeopleSoft bundles,
maintenance packs, upgrades, and releases.
Roadmaps and Schedules is located on PeopleSoft’s Customer Connection.
Navigation:
Click on
Support
Click on
Roadmaps
and
Schedules
Revised Feb. 2008
Enterprise Systems - UHS
Page 110 of 120
PeopleSoft Application Development Standards
Scroll down
until you
find the
Maintenance
Schedule
Select the
Product
Line
Revised Feb. 2008
Enterprise Systems - UHS
Page 111 of 120
PeopleSoft Application Development Standards
Bundles,
maintenance
packs, and
releases will
be displayed
for that
product line
by quarter.
You can
click on the
year tab and
retrieve the
combined
list for all
quarters.
Revised Feb. 2008
Enterprise Systems - UHS
Page 112 of 120
PeopleSoft Application Development Standards
APPENDIX E – Customer Connection Updates and Fixes
Customer Connection allows customers to download individual patches, bundles, maintenance packs, and tax
updates through Updates and Fixes.
Navigation:
Click on
Updates &
Fixes
Click on
“Apply to
Release” to
download
patches,
bundles,
maintenance
packs.
Click on
“Tax
Updates” to
download
payroll tax
updates.
Revised Feb. 2008
Enterprise Systems - UHS
Page 113 of 120
PeopleSoft Application Development Standards
Enter the
report id if
known.
Otherwise,
you can
search for
all patches,
bundles,
maintenance
packs, or
tax updates
that have
been
released.
These can
be
downloaded
to the
workstation.
This process
is normally
performed
by a DBA.
Revised Feb. 2008
Enterprise Systems - UHS
Page 114 of 120
PeopleSoft Application Development Standards
APPENDIX F – Customer Connection Filing Cases
Support cases may be filed with PeopleSoft to obtain either technical or functional support. Before cases are filed,
PeopleBooks should be referenced first to determine if an answer for the question is available. (See Appendix G.)
Navigation:
Click on
Support
Click on
“Online
Support”
Revised Feb. 2008
Enterprise Systems - UHS
Page 115 of 120
PeopleSoft Application Development Standards
Select
“Create New
Support
Case” to
open a new
case.
PeopleSoft
will email
you with the
name of the
support
person and
the case
number.
Select
“Manage
Existing
Cases” to
review cases
already filed
with
PeopleSoft.
PeopleSoft
can
communicate
to whoever
opened the
case either
via email or
by adding
notes to the
case itself
within
Customer
Connection.
Revised Feb. 2008
Enterprise Systems - UHS
Page 116 of 120
PeopleSoft Application Development Standards
APPENDIX G -- PeopleBooks
PeopleBooks provides helpful functional and technical documentation for PeopleSoft applications. It addresses
items from application setup, processes, configuration, etc.
To view PeopleBooks click on the following link:
http://fornax.fast.uh.edu:8080/peoplebooks/index.html
Revised Feb. 2008
Enterprise Systems - UHS
Page 117 of 120
PeopleSoft Application Development Standards
This link
will provide
access to a
variety of
PeopleBooks
which are
stored in pdf
format as
shown
below.
Click on the
link of
interest and
the
PeopleBook
will open up.
When
clicking on
one of the
PeopleBook
links,
another set
of links
related to
that area
open up.
In the
example to
the right, the
HRMS
PeopleBook
was opened.
Revised Feb. 2008
Enterprise Systems - UHS
Page 118 of 120
PeopleSoft Application Development Standards
Upon
clicking on
one of the
links above,
the
PeopleBook
pdf opens.
You can
browse the
table of
contents,
refer to the
index, or
search on
key words.
Revised Feb. 2008
Enterprise Systems - UHS
Page 119 of 120
PeopleSoft Application Development Standards
APPENDIX H – Report Format
Example 1 indicates variables to be populated for report. (Reference uhshdg002.sqc & uhshdg003.sqc)
Report Id: $ReportId
University Of Houston System
Run Date: $ReportDate
$ReportTitle
Run Time: hh:mm:s
$ReportTitle2
$ReportTitle3
Page:page-number
Bus. Unit: $Report_Business_Unit $Report_Business_Unit_Name
Dept:
$Report_Dept_Name
Column 1 column 2
xxxxxxxxx mm/dd/yyyy
xxxxxxxxx mm/dd/yyyy
xxxxxxxxx mm/dd/yyyy
Dept Totals:
Bus Unit Totals:
Grand Totals:
column 3
column 4
column 5
column 6
column 7
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 999,999.99 -999,999.99 -999,999.99 -999,999.99
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 999,999.99 -999,999.99 -999,999.99 -999,999.99
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 999,999.99 -999,999.99 -999,999.99 -999,999.99
999,999.99 -999,999.99 -999,999.99 -999,999.99
999,999.99 -999,999.99 -999,999.99 -999,999.99
999,999.99 -999,999.99 -999,999.99 -999,999.99
Example 2 shows report in report form
Report Id: XXXXXXXX
Run Date: mm/dd/yyyy
Run Time: hh:mm:s
University
Report
Report
Report
Of Houston System
Title
Title 2
Title 3
Bus. Unit: XXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Dept:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Column 1 column 2
xxxxxxxxx mm/dd/yyyy
xxxxxxxxx mm/dd/yyyy
xxxxxxxxx mm/dd/yyyy
Dept Totals:
Bus Unit Totals:
Grand Totals:
Revised Feb. 2008
column 3
column 4
column 5
column 6
column 7
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 999,999.99 -999,999.99 -999,999.99 -999,999.99
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 999,999.99 -999,999.99 -999,999.99 -999,999.99
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 999,999.99 -999,999.99 -999,999.99 -999,999.99
9 99,999.99 -999,999.99 -999,999.99 -999,999.99
999,999.99 -999,999.99 -999,999.99 -999,999.99
999,999.99 -999,999.99 -999,999.99 -999,999.99
Enterprise Systems - UHS
Page 120 of 120
Page: nnn