App Dev Standards

PeopleSoft Application Development Standards
Version 9 Enterprise Systems UHS
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...................................................................................................................................................61 8.13 CUSTOM QUERY TREES...................................................................................................................................62 8.14 TREES...............................................................................................................................................................65
Version 7.1
Enterprise Systems - UHS
Page 2 of 121
PeopleSoft Application Development Standards 9. APPLICATION TESTING....................................................................................................................................66 9.1 TESTING PHILOSOPHY............................................................................................................................................66 9.2 UNIT TEST..........................................................................................................................................................66 9.3 PROGRESSIVE TESTING ..........................................................................................................................................67 9.4 REGRESSION TESTING............................................................................................................................................67 9.5 INTEGRATION TEST...............................................................................................................................................67 9.6 SYSTEM TEST.......................................................................................................................................................67 9.7 END TO END TESTING...........................................................................................................................................68 9.8 USER ACCEPTANCE TEST.......................................................................................................................................68 9.9 SECURITY TESTING...............................................................................................................................................68 9.10 LOCALITY TESTING.............................................................................................................................................68 9.11 LOAD TESTING...........................................................................................................................................68 9.12 TESTING GUIDELINES .............................................................................................................................69 9.14 APPLICATION REVIEW.........................................................................................................................................71 10. PROJECT STANDARDS....................................................................................................................................75 10.1 STATE REQUIREMENTS...........................................................................................................................75 10.2 UH REQUIREMENTS....................................................................................................................................75 10.2 TOP TIER PROJECT PRACTICES.............................................................................................................................76 10.3 ENTERPRISE PROJECT MANAGER (EPM)...............................................................................................................76 10.4 PROJECT DOCUMENTATION...................................................................................................................................78 10.5 PROJECT DELIVERABLES.............................................................................................................................78 10.6 PROJECT TEMPLATES...........................................................................................................................................80 10.7 PROJECT STANDARDIZATION PROCESS..............................................................................................80 11. SECURITY..........................................................................................................................................................81 11.1 BACKDOOR POLICY FOR PRODUCTION AND REPORTING DATABASES..............................................................................81 11.2 ACCESS TO UNIX AND NT ENVIRONMENTS..........................................................................................................81 11.3 DATABASE LINKS................................................................................................................................................81 11.4 USERID............................................................................................................................................................81 11.5 PASSWORD SECURITY..........................................................................................................................................82 11.6 ROLES, PERMISSIONS, AND ROW LEVEL SECURITY.....................................................................................................89 11.7 QUERY SECURITY................................................................................................................................................89 11.8 DEVELOPER AND FUNCTIONAL ACCESS MATRIX......................................................................................................89 12. DOCUMENTATION...........................................................................................................................................90 12.1 USERS GUIDE.............................................................................................................................................90 12.2 TECHNICAL REFERENCE.........................................................................................................................90 12.3 OPERATIONS GUIDE ..............................................................................................................................91 12.4 APPLICATION DEVELOPMENT STANDARDS......................................................................................91 12.5 IN-CODE DOCUMENTATION...................................................................................................................91 12.6 UHS FORMS.................................................................................................................................................91 12.7 PEOPLEBOOKS............................................................................................................................................91 12.8 PEOPLETOOLS OBJECT DEFINITIONS...................................................................................................91 12.9 OTHER DELIVERED DOCUMENTATION ..............................................................................................93 12.10 PROJECT / ASSIGNMENT TRACKING..................................................................................................93 12.11 MODIFIED OBJECTS LIST................................................................................................................................93 13. PERIODIC REVIEW.........................................................................................................................................102 14. READERS COMMENTS.................................................................................................................................103 APPENDIX A: Modification Log............................................................................................................................104 APPENDIX B - Glossary.........................................................................................................................................105 APPENDIX C - Abbreviations................................................................................................................................105 APPENDIX D Customer Connection Roadmaps and Schedules.........................................................................111
Version 7.1
Page 3 of 121
PeopleSoft Application Development Standards APPENDIX E Customer Connection Updates and Fixes.....................................................................................114 APPENDIX F Customer Connection Filing Cases...............................................................................................116 APPENDIX G -- PeopleBooks................................................................................................................................118 APPENDIX H Report Format...............................................................................................................................121
Version 7.1
Page 4 of 121
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
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
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 3/13/08 2/14/08 1/24/08 3/6/08
Y Y Y Y Y
2/7/08 2/14/08
Y Y
Version 7.1
Page 5 of 121
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
Version 7.1
Page 6 of 121
PeopleSoft Application Development Standards barrier to meeting user needs -- "We can't do that. It doesn't fit the Standards." Invoking the standards as an 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
Page 7 of 121
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
Page 8 of 121
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
Page 9 of 121
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 Phase II Phase III Final Phase
Download of MPx to P: drive
SAPRD (Pre-MPx)
SAPRD (Pre-MPx)
SAPRD (Pre-MPx)
Application of MPx
Refresh
Refresh
Application of MPx
SA89DMOP (MPx)
SA89SBX2
SA89DEV
SA89TST
SAPRD (MPx)
Emergency Fixes Applied to SASBX2
Application of MPx
Application of MPx
Refresh
Developer Retrofits SA89SBX2 (Pre-MPx) SA89DEV(MPx) SA89TST(MPx)
Emergency Fixes to be applied to SAPRD and SA89DEV(MPx)
Developer Retrofits
- SASBX - SA89DEV -SA89DC1 - SA89SBX2 - etc.
SAPRD (Pre-MPx)
Version 7.1 121
Page 10 of
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) Finance P:\xxxx\sqr P:\xxxx\user\sqr P:\xxxx\src\cbl\base P:\xxxx\user\src\cbl\base P:\xxxx\user\crw P:\xxxx\winword HRMS / SAA P:\xxxx\sqr P:\xxxx\user\sqr P:\xxxx\src\cbl\base P:\xxxx\user\src\cbl\base P:\xxxx\user\crw P:\xxxx\winword
Version 7.1 121
Page 11 of
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 Description Asset Management Accounts Payable Account Receivable Billing Budget Contracts Administration Enterprise Systems - UHS Page 12 of
Version 7.1 121
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 121 Enterprise Systems - UHS Page 13 of
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 121 Enterprise Systems - UHS Page 14 of
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 121
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. File type Excel (*.xls) Word (*.doc) Acrobat (*.pdf) (Must have Acrobat Reader installed to read these files.) HP Format (*.lis) Line Printer (*.lis) Rich Text Files (*.rtf) SQR Portable Format (*.spf) Text Files (*.txt) Post Script Files (*.lis) Adobe Acrobat (*.pdf) Comma Delimited (*.csv) HTML (*.htm) X X X X X X X X X X X X X X X X Crystal X X SQR X nVision X Application Engine 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. Version 7.1 121 Enterprise Systems - UHS Page 16 of
The format for report files created or maintained by batch programs 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 121
Page 17 of
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 121 Enterprise Systems - UHS Page 18 of
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 121 Enterprise Systems - UHS Page 19 of
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 PeopleSofts 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.
Version 7.1 121
Page 20 of
PeopleSoft Application Development Standards The process flow for applying patches to PeopleSoft is: 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 121 Enterprise Systems - UHS Page 21 of
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 121
Page 22 of
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
Functional lead submits request for enhancement or modification to tech appl mgr.
Analysis & Design
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
Developer initiates request to migrate to production
Production Verification
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 121
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 121
Page 24 of
Version 7.1 121
Page 25 of
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 121
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 121
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 121
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 121 Enterprise Systems - UHS Page 29 of
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 121
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. 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. n/a Emergency Migration Type I External Objects can migrate at any time. Extra approval not 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. 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 121
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 121
Page 32 of
PeopleSoft Application Development Standards STAT Console
Version 7.1 121
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 121
Page 34 of
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 ids and operator classes.
Version 7.1 121
Page 35 of
PeopleSoft delivered menus should not be modified. UHS custom menus should be used. 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 Version 7.1 121 Enterprise Systems - UHS Page 36 of
PeopleSoft Application Development Standards /* 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; 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 121
Page 37 of
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 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
Crystal Reports
Version 7.1 121
Microsoft Excel
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.
PeopleSoft nVision
SQR (Structured Query Report Writer)
Reporting Tools General Criteria SQR Unlimited or requires multiple selects Unlimited Rows returned Server Complexity of reporting * Speed of process ** Drilldown Excel Format Charts & Graphs Extension Unix Server or NT Server 4 2 No Yes Yes Defined by program. Report output defined by Process scheduler. Crystal nVision PS Query 9 (6 is the UHS recommended limit) App server time limit App Server (Unix) 1 1 No Yes No N/a
Max Number of Tables
9 Process scheduler time limit NT Server 2 4 Yes No Yes .LIS, RPT, PDF Report output defined by Process scheduler.
9 Process Scheduler time limit Excel Limit NT Server 3 4 Yes Yes Yes .XLS, PDF Report output defined by Process scheduler.
* Complexity: 1 (Easy) - 4 (Complex) ** Speed: 1 (Fast) - 4 (Slow)
Version 7.1 121
Page 39 of
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 121 Enterprise Systems - UHS Page 40 of
The UHS standard headings and standard trailers should be used within UHS custom SQR programs. The following SQCs should be used for standard report titles and headings. 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 121
Page 41 of
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.
Version 7.1 121
Page 42 of
PeopleSoft Application Development Standards EXAMPLE 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 121
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 programs 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 121
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 #variable; only move those that are required by the logic of your program. 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 121
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 121
Page 46 of
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. Querys aggregate function returns only a calculated row of data where as Crystals 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. Its 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 121
Page 47 of
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 121 Enterprise Systems - UHS Page 48 of
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 121
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 121 Enterprise Systems - UHS Page 50 of
,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:
Version 7.1 121
Page 51 of
PeopleSoft Application Development Standards 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 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. 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. A batch process may be used to provide a report that is complex enough that a PeopleSoft Query will not suffice. In some cases, batch process is a way to avoid locking a work station while the transaction process is completed.
2. 3. 4.
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.
Version 7.1 121
Page 52 of
PeopleSoft Application Development Standards NOTE: Once the COMMIT command has been executed, the rollback command cannot restore records updated prior to the commit. 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.
Version 7.1 121
Page 53 of
PeopleSoft Application Development Standards 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. 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 Version 7.1 121 Enterprise Systems - UHS Page 54 of
PeopleSoft Application Development Standards 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 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.
Version 7.1 121
Page 55 of
PeopleSoft Application Development Standards 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. 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:
Version 7.1 121
Page 56 of
8.10.10 Log Files Log files are created whenever a batch process runs. 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 Version 7.1 121 Enterprise Systems - UHS Page 57 of
PeopleSoft Application Development Standards 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 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. Oracles 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 3rd 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. Version 7.1 121 Enterprise Systems - UHS Page 58 of
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. 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 Records Inserted Records Updated Records Not Updated Total Reasons Not Updated: Invalid Job Code Invalid Position Invalid Emplid Total Version 7.1 121 2000 1000 1000 500 4500 1000 3000 500 4500 200 400 300 900 Enterprise Systems - UHS Page 59 of
Version 7.1 121
Page 60 of
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 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.
Revised Feb. 2008
Page 61 of 121
NEWVALUE KEY# 1-15
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.
8.12.6 Record Level Audit Table Audit Field Name AUDIT_OPRID AUDIT_STAMP AUDIT_ACTN RECNAME Fields of table being audited, for example: EMPLID NAME ADDRESS1 ADDRESS2 Etc. 8.12.7 Audit Action Values Action A C D K N Description Add Change Delete Key change Old record 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. 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.
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 managers 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.
Revised Feb. 2008
Page 62 of 121
PeopleSoft Application Development Standards Maintenance of Query Trees is located in PeopleTools, Security, Query Security, Query Access Manager.
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
Page 63 of 121
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
Page 64 of 121
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 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.
Revised Feb. 2008
Page 65 of 121
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
Page 66 of 121
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
Page 67 of 121
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
Page 68 of 121
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
Page 69 of 121
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 Setup Expected Results Tested By Test Date Test Results Status
Revised Feb. 2008
Page 70 of 121
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.
Revised Feb. 2008
Page 71 of 121
PeopleSoft Application Development Standards 3) 4) 5) 6) 7) 8) Print out the source code and pages and report samples, and distribute to the Review Team. 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
Page 72 of 121
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
Page 73 of 121
WALKTHROUGH MODIFICATION FORM APPLICATION:__________________________________________ DEVELOPER: ___________________________________________ CHECK ONE: ___ Design Review ___ Code Review PROGRAM
____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________ ____________
PAGE ___ OF ____ DATE: __________ DATE
MODIFICATION
_________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________
COMPLETED
_______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________ _______________
___________________ ____________________ ___________________ ___________________ DEVELOPER

Revised Feb. 2008
LEADER
RECORDER
MEMBER
Page 74 of 121
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 Institutes 9 Knowledge Areas: 1. 2. 3. 4. 5. 6. 7. 8. 9. Integration Management Scope Management Time Management Cost Management Quality Management Human Resource Management Communications Management Risk Management 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
Page 75 of 121
10.2 TOP TIER PROJECT PRACTICES

Projects that are being tracked as Tier 1 and Tier 2 should include 1. 2. A Project Charter to define and obtain approval for the projects goals and objectives, business case, scope of work, major milestones, project organization, and budget. 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. EPM Project to enable participation in project portfolio management activities, including monthly work effort and budget status reporting. Project Web Site to improve team communications and visibility of use of project management best practices, such as: Project Status to improve ongoing project communications Project Schedule or at least a Milestone Table with target dates and resource assignments Issue Log to improve project communications and faster resolution, and if necessary escalation, of project timeline, budget, or scope issues Change Log to document changes that require rebaselining schedule, increasing budget, or changing scope. Communications Plan if project is customer-facing
3. 4. 5. 6. 7. 8. 9.
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
Page 76 of 121
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
Page 77 of 121
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. 2. 3. 4. 5. Analysis Design Construction Testing 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
Page 78 of 121
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 projects 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
Revised Feb. 2008
Page 79 of 121
End users
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
Page 80 of 121
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 persons primary name in PeopleSoft. This is done to facilitate searches for a persons userid.
Revised Feb. 2008
Page 81 of 121
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
Page 82 of 121
Password changes are made by clicking on My System Profile on the main menu.
Next, click on Change password
Revised Feb. 2008
Page 83 of 121
Enter old and new passwords as indicated.
Revised Feb. 2008
Page 84 of 121
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
Page 85 of 121
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
Page 86 of 121
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
Page 87 of 121
An email with the new password will be emailed to the user.
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.
Revised Feb. 2008
Page 88 of 121
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 Developers Application Full Read-Only Read-Only Read-Only PeopleTools Full Read-Only Read-Only Read-Only Navigation Full Role/User specific Role/User specific Role/User specific Functional Users Application Full Role/User specific Role/User specific Role/User specific PeopleTools Read-Only Read-Only No No
Revised Feb. 2008
Page 89 of 121
12. DOCUMENTATION
Recommended practices for each type of documentation within the PeopleSoft environment are discussed below.
12.1 USERS GUIDE

The users 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
Page 90 of 121
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 users 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
Page 91 of 121
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
Page 92 of 121
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
Revised Feb. 2008
Page 93 of 121
PeopleSoft Application Development Standards 4. 5. 6. SA8DEV 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
Page 94 of 121
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
Page 95 of 121
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 COBOLs, SQRs, 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
Page 96 of 121
The Home link on each page takes you to the Object Inventory home page.
Revised Feb. 2008
Page 97 of 121
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
Page 98 of 121
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
Page 99 of 121
After a particular page has been selected, a page with number of tabs opens up. Each tab signifies Page Recor d Field Projec t 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
Page 100 of 121
After a particular record has been selected, a page with number of tabs opens up. Each tab signifies Recor d Field Projec t 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
Page 101 of 121
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
Page 102 of 121
14. READERS 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
Page 103 of 121
APPENDIX A: Modification Log

Version V1 d25 V1 d26 Chapter/ Section 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 Made By JML JML JML JML JML JML JML JML Date 12/1/03 1/12/04 1/12/04 1/12/04 4/19/04 8/1/06 2/7/08 9/9/08
V1 d27 V2 d1 V3 V9
4.3 7.0 All 7.2
Revised Feb. 2008
Page 104 of 121
APPENDIX B - Glossary
API Bolt-On Customization Delivered Enhancement Modification Integration Testing PIA SOA SQA System Testing Unit Testing User Acceptance Testing Vanilla 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. 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 3rd 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.
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
Page 105 of 121
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
Page 106 of 121
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
Page 107 of 121
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
Page 108 of 121
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
Page 109 of 121
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
Page 110 of 121
APPENDIX D CUSTOMER CONNECTION ROADMAPS AND SCHEDULES

PeopleSofts Roadmaps and Schedules provides a project of expected delivery dates for PeopleSoft bundles, maintenance packs, upgrades, and releases. Roadmaps and Schedules is located on PeopleSofts Customer Connection. Navigation: Click on Support
Click on Roadmaps and Schedules
Revised Feb. 2008
Page 111 of 121
Scroll down until you find the Maintenanc e Schedule
Select the Product Line
Revised Feb. 2008
Page 112 of 121
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
Page 113 of 121
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
Page 114 of 121
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
Page 115 of 121
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
Page 116 of 121
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
Page 117 of 121
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
Page 118 of 121
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
Page 119 of 121
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
Page 120 of 121
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 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 University Report Report Report Of Houston System Title Title 2 Title 3 Page: nnn Page:page-number
Example 2 shows report in report form Report Id: XXXXXXXX Run Date: mm/dd/yyyy Run Time: hh:mm:s
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: column 3 column 4 column 5 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 999,999.99 -999,999.99 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 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 column 6 column 7 -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
Revised Feb. 2008
Page 121 of 121

App Dev Standards

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

App Dev Standards

Încărcat de

Drepturi de autor:

Formate disponibile

PeopleSoft Application Development Standards

Version 9 Enterprise Systems UHS

PeopleSoft Application Development Standards

Enterprise Systems - UHS

Enterprise Systems - UHS

Enterprise Systems - UHS

PeopleSoft Application Development Standards

Complete 11/15/07 11/15/07 3/13/08 2/14/08 8/16/07 11/29/07 3/13/08

1/24/08 3/13/08 2/14/08 1/24/08 3/6/08

Enterprise Systems - UHS

PeopleSoft Application Development Standards

Enterprise Systems - UHS

Enterprise Systems - UHS

PeopleSoft Application Development Standards

Enterprise Systems - UHS

Enterprise Systems - UHS

PeopleSoft Application Development Standards

3.3 MIGRATION PATHS

Overview of SAHR databases MP process

Download of MPx to P: drive

Emergency Fixes Applied to SASBX2

Developer Retrofits SA89SBX2 (Pre-MPx) SA89DEV(MPx) SA89TST(MPx)

Emergency Fixes to be applied to SAPRD and SA89DEV(MPx)

- SASBX - SA89DEV -SA89DC1 - SA89SBX2 - etc.

Version 7.1 121

Enterprise Systems - UHS

PeopleSoft Application Development Standards

3.4 SOURCE CODE TREES

Code Tree Standards: (ex: xxxx = SAnnDEV, FSnnDMO, etc)

Version 7.1 121

Enterprise Systems - UHS

PeopleSoft Application Development Standards

4.4 APPLICATION MODULES

Version 7.1 121

PeopleSoft Application Development Standards

4.5 INTERNAL OBJECTS

PeopleSoft Application Development Standards

PeopleSoft Application Development Standards

4.6 EXTERNAL OBJECTS

u mmm nnn.ext u mmm desc.ext or u mm s nnn.ext

Version 7.1 121

Enterprise Systems - UHS

4.7 OUTPUT FILES

PeopleSoft Application Development Standards

Version 7.1 121

Enterprise Systems - UHS

PeopleSoft Application Development Standards

5.1 INSTALLATIONS, UPGRADES, PATCHES, AND MAINTENANCE PACKS

5.2 BACKUP AND RECOVERY

5.3 PERFORMANCE TUNING

5.4 MAINTENANCE AND MANAGEMENT

PeopleSoft Application Development Standards

6. PATCHES, UPGRADES, AND CUSTOMIZATION

6.1 LOCATION AND NAMING CONVENTION

PeopleSoft Application Development Standards

6.3 PATCHES AND FIXES

Version 7.1 121

Enterprise Systems - UHS

PeopleSoft Application Development Standards

Version 7.1 121

Enterprise Systems - UHS

PeopleSoft Application Development Standards

7. SOFTWARE QUALITY ASSURANCE

Request for Enhancement/ Modificatiion