Open

 Overview

Student Administration - PeopleSoft Campus Solutions 9.2

Trademarks

Trademarked names may appear throughout this document. Rather than list the names and entities that own the trademarks or insert a trademark symbol with each mention of the trademarked name, the names are used only for editorial purposes and to the benefit of the trademark owner with no intention of infringing upon that trademark.

Contact Information

To suggest changes or submit corrections, contact:

Document Information

This is a working draft/copy of the technical standards; contents have been imported from the original word document. Additionally, new processes/workflow/tools, etc. have been introduced since the last update to the original document. Therefore, expect quite a few changes over time.

Purpose

The purpose of this document is to describe the PeopleSoft Development standards for the University of Connecticut (UConn) PeopleSoft Student Administration system.  

Objectives

Any organization implementing the PeopleSoft Software must define its own naming and documentation standards for personalizing and adding objects/programs to the delivered system.

Documentation of and adherence to naming conventions and documenting techniques will result in smoother upgrades by providing a clear means of distinguishing customer enhancements from the delivered PeopleSoft application objects and programs.

The following document highlights list of mandatory standards that must be adhered to when making, changing or creating new PeopleSoft objects and programs. PeopleSoft objects include Records, Fields, People Code, Pages, and Menus. Additional Standards are defined for SQR programs, Crystal, and Queries.

 Intended Audience

 Modification Strategy


Making modifications to existing applications can be an involved process.  There are many design considerations to examine since one does not want other existing applications or modules within an application to be adversely affected. 

The following is a list of tips and strategies that should be followed while making any modification to Student Administration. Following this modification strategy will minimize efforts during the upgrade process.

 Development and Naming Standards

Naming conventions are used in naming files, directories, modules, procedures, variables, and PeopleSoft objects (records, fields, etc.).  The naming conventions discussed here make it easier for development and maintenance teams to carry out the implementation work. 

Application Designer Projects

Application Designer projects are used to track a collection of objects (various PeopleSoft definitions) pertaining to various customizations; these projects are then copied from one environment to another (e.g., CSDV to CSQA for functional testing & signoff, and CSQA to CSPR for going live with the project).

Application Designer allows 30 bytes for project names; project names should almost always start with the “standard prefix”, where

• First 2 characters are “UC”, followed by an underscore

• Next part of the project name is the Jira Ticket Number

Example: UC_422, where “UC_” is the standard prefix and “422” refers to Jira ticket #422

• Next 2 characters identify one of the areas/modules listed in the table below, followed by an underscore

If your (planned) project name does not conform to the above convention, reach out to PS Tech Lead for guidance.

Remaining 24 characters:

Project Name                                                              Description

UC_SR_0001                                                             Student Records

UC_SF_0001                                                              Student Financial

UC_FA_0001                                                              Financial Aid

UC_CC_0001                                                             Campus Community

UC_AD_0001                                                             Admissions

UC_TC_0001                                                             Transfer Credit

UC_SC_0001                                                              Security related

UC_TC_0001                                                             Transfer Credit

Before assigning a number, do a search for object references to see if object exists in another project.

If the object is already exists in a project, then use the same project number with version appended to the end (e.g. UC_SR_0450, you would create a UC_SR_0450V1). Version number will be from V1 to Vnnn.

Record and Field standards

New records and fields MUST begin with the UC_ designator to distinguish them from PS delivered fields and records. Must use PeopleSoft defined fields first if available.

PeopleSoft uses the following naming conventions for records and fields.

Suffixes used on record/table names are as follows:

• _VW A record definition that is physically implemented by defining an SQL view, such as, ACAD_DATA_VW.

• _DVW A record definition that is implemented by defining a dynamic SQL view (this kind of view is not a physical table).

• _TMP or _WRK a record definition that is used as a temporary work or derived table.

• R  sqrname A record definition that is used as a temporary work table for a sqr or sqc. For example uc_r_usre036

• _TBL A record definition that contains data that controls the application as opposed to being maintained by the application. A "reference" table or "general" table.

• _SRCH A view that is used as to select specific employee records to be displayed to the user via a page. In addition, _SRCH views can be used to add department level security to SQR reports—if required by UConn.

• _HST A record definition for PeopleSoft Data Archive purposes; is a copy of the online/base table, with PSARCHIVE_SBR subrecord added to it.

• Derived records

Prefixes used on record/table names are as follows:

• UC_SA will be used within the HCM system to define a record that is used by the SA system.

Suffixes used on data elements are as follows:

• AMT Amount; numeric value of currency type.

• CD Code; user defined value from the Translate or other table.

• CNT Count; Numeric value containing a count.

• DT Date; format YYYY-MM-DD.

• DTTM Date Time; format YYYY-MM-DD and HH:MM:SS

• ID Identification; e.g. Operator ID

• PCT Percent; stored as a decimal, i.e. 50% = .5

• RT Rate; a numeric field expressing an amount per some unit

• TM Time; hours, minutes, and seconds.

Translate Values

• Check with PeopleBooks to see if they recommend changes to this PS delivered translate values. Never delete PS delivered translate values. Make them inactive if not needed.

• If adding values and an XLAT edit check to an existing field, determine if the field exists elsewhere and if an XLAT edit check is needed on that record too.

• Document new edits or new translate values in comments under Project Properties in the Application Designer.

• Only use the XLATITEM (Translate Table, a generic valid values table for non-key fields) for non-key fields which meet the following criteria:

  • Character type field whose assigned values need to be validated, and

  • Length is 1 to 4 characters, and

• The field does not require more than a long/short description, code value, and effective date.

• Fields with associated values on the XLATITEM will sometimes appear as radio buttons on a page. Please use radio button sparingly based on ease of usability for data entry.

• Xlatitem values should be of a static nature. They should not be values that will require constant modification.

• If number of translate values are more than 100 consider putting data in a table.

• Any YES/NO or TRUE/FALSE fields should be specified as such in the Application Designer under record field definition and under project properties comments… Do not use the XLATITEM for such fields.

Views

• Try to avoid layering views within a view.

• Limit number of tables in a view to four if possible. 

• Page fields based on views should be display only.

• Any new view should be prefixed with UC_ and should be suffixed with standard PeopleSoft identifiers, _VW or _SRCH or _DVW.

• Associated table and view key fields MUST be consistent.

• If a field on a view is designated as an alternate key, ensure that it is designated as an alternate key on the associated data table as well.

• Understand the response time implications of the view.

Note: Please work with the DBA on the creation of all new views that involve large tables or more than a few table joins.

Records and Fields - Do’s and Don’t

• NEVER delete a PS delivered field from a record.

• NEVER change PS delivered field lengths.

• NEVER rename PS delivered fields on a record. Instead change the label on the page where the field is used or add a label id to the field definition.

• Exercise care when designating fields as LIST BOX items; especially, for high-volume tables such as PS_PERSONAL_DATA. This will affect existing search views and indices. It will result in increased storage space and performance degradation. General key, alt key and sort key is used for list box.

• AVOID where ever possible adding new fields to the end of a PeopleSoft record definition. Approval will be needed by management before making the change. It’s best to add child records if possible. On UC_ records also add new fields to end of record and alter record. It’s a good practice to do ‘Find Object References’ in application designer.

• AVOID use of the LONG EDIT field. Using this type of field increases the difficulty in Table Alter.

• Ensure validation edits against prompt tables.

• Defining a field as “required” to PeopleSoft means that a character field can never be set to a space and a numeric field can never have a value of zero. Therefore, a value must be provided. Make sure that you really need this as a required field.

• Remember that the search record dictates the contents of a given dialog box.

• Do not make Effdt a list box item.

• NEVER add derived fields to the PeopleSoft derived records: DERIVED, DERIVED_XXXX where XXXX is a PeopleSoft functional extension (i.e. SR, SF, FA) Instead use the UC_DERIVED_XX records.

Index Prefixes (Informational)

• Do not change PeopleSoft index names.

Key or duplicate order key indexes if at least one field in the table is a key or duplicate order key.  The index contains all key and duplicate order key fields.  If duplicate order keys exist, then list item fields are also added to the index.  The system automatically names this index with the prefix of PS_.

Alternate search key indexes for each alternate search key.  The system automatically names this index with a prefix of PSn, where n is a number between 0 and 9.

List box item-only indexes if no duplicate order keys exist for the table and it contains at least one field that is a list item, but not a key field.  (Alternate search keys are not considered key fields in this type of index.)  The system automatically names this index with a prefix of PS#.

Custom indexes can be defined with the Change, Indexes, Add Index dialog.  The system automatically names this index with a prefix of PSa, where a  is a letter A, B, C and so on. In application designer Tools>Data Administsration>Indexes>Add Index/Edit Index.

Documentation

Maintain detailed documentation of changes within the field/record properties and comments within the project properties. Also maintain the customization request, program inventory, sqr inventory or any other inventory that is maintained. This should include adding fields to tables, and where these fields are being used or any other information that might be helpful. Note any pages where these fields are added to. (This will be important information to have at the time of system upgrades.) A project should be created for new sqrs or changed sqrs. Also any other items that need to be documented as changed/new that normally do not belong in a project.

Changes within the Record/field field definition, project properties comments or in PeopleCode should contain project number (UC_), author, date, and brief description.

Application Packages Standards

No existing PeopleSoft application packages, including methods, classes, or functions should be changed without prior authorization from management. First choice should be to create or use an UConn application packages if possible. Second option if you need to use a PeopleSoft application packages because of private fields or functions then created a new object using the UC_ prefix and call this object from your PeopleCode. If the new object is very similar to an existing PeopleSoft object, then use the PeopleSoft name after the UC_ prefix and place this object right after the original PeopleSoft object. 

Component Standards

A component is a set of pages that should be processed as if it were one page. Pages in a component share the same basic key structure and the same search record. The search record is defined at the component level. What you name the page definition when you add the page definition of each page to the component is unimportant, however you may want to give them similar names to make them easily recognizable as a “group” of pages. UConn custom components should begin with an UC_. Do not use the project number as part of the page name. 

Page Standards

• When beginning any modifications to an existing Page, a backup of the original Page should be made. You can accomplish this by opening the original Page and using the “save as” feature. The backup copy’s name should be the original Page name with a suffix, but never overwriting existing versions. For example, if you were to make a change to Personal_Data1 Page first save it as Personal_Data1_BK (if it doesn’t already exist) before making changes to the Personal_Data1 Page. Avoid renaming a PS delivered Page because People Code could reference that Page. Add backup page to project.

• Do not break up delivered PeopleSoft Page groups.

• New Pages should be prefixed with UC_. Do not use the project number as part of the page name.

• Major redesigns of delivered PS Pages should be cloned and named appropriately.

• Naming standard for a page will be UC_ XXXXXX. If this page is used as a control page for only one sqr than XXXXXX will be the sqr name. If the page is used for multiple sqrs than use a descript name for XXXXXX.

• NEVER delete a field from a Page. Instead, make the field INVISIBLE.

• Key fields displayed on a Page should ALWAYS be display only.

• Use check boxes for YES/NO fields.

• Use edit boxes for character fields, number fields, and date fields.

• Use radio buttons only for character fields with XLATITEM values that are static; that is, for fields whose possible values will NEVER change once established. If translate values are changed for a field which are represented by radio buttons on Pages, these Pages will require modification to account for the added, changed, or deleted XLATITEM values.

• Up to 3 scroll levels can be specified on a Page. (memory)

• Each scroll level should be associated with a specific record within a given parent-child hierarchy.

• Field order as defined under "View...Order" determines the flow of the cursor from field to field on the screen. Use this facility to set the order in which you would like the cursor to move.

• Ensure that all fields associated with a specific scroll bar are under that scroll bar in the Order.

Folder Structure and Content Standards

• All folders created off the main menu shall begin with UC_Module_Name_Bolt_on. An example would be UC_Student_Records_Bolt_On.

• All folders created off the Bolt on menu shall have a name that is unique. The name will be  UC_XX_HighLevelName, where XX is module and High_Level_Name describes the function. An example would be UC_SR_ESTABLISH_COURSE.

• All folders created off the HighLevelName will be UC_XX_HighLevelName_YYYYY where YYYYY(ect) will be defined as process, reports, use and similar names. An example would be UC_SR_TRANSFER_CREDIT_PROCESS

Component Interface Standards (Requires further review)

Component Interfaces are the focal points for externalizing access to existing PeopleSoft components. They provide real-time synchronous access to the PeopleSoft business rules and data associated with a component outside the PeopleSoft online system.

The naming of component interfaces should be consistent and systematic. Also, the name should not be changed once the component interface is part of a production system—other applications depend on a consistent name with which to reference the component interface.

If you are changing the structure of a component interface such that an existing program can no longer access it correctly, create a new component interface rather than updating the existing one. There is no version property on a component interface, so if you must create a new version of a delivered component interface, adhere to a standard naming guideline to avoid confusion. A suggested naming guideline is:

• LOCATION (original component interface).

• UC_LOCATION (modified)

• Document all custom Component interfaces in the customization request form and save it under the module subdirectory located in the following directory structure p:/Documentation/Customization Request/.

Component Interface - Do’s and Don’ts

• Typically, you do not want to expose Get keys or Create keys as properties, because these are set before a Get or Create operation and might be inadvertently changed.

• Make sure that you do not delete all the properties within the collection; that would result in an empty collection. If such empty collections exist, remove them; otherwise, they appear with X in the component interface view.

• If your page does not support Add mode, then you should not expose the level-zero record of the component, because it contains data that is not specific to the component interface that you are creating.

• Do not expose fields that are not visible in the component view. The component optimization code might eliminate unused fields from its buffers, which results in an error when that field is accessed by the component interface.

• Do request security for the CI when the project is moved to the QA database. The request should go to the PeopleSoft security person.

PeopleCode Standards

On-line processing of data within PeopleSoft is controlled and managed by the Application Processor. PeopleCode programs are used to interact with this Application Processor to enhance and better control processing within a given Page or component. PeopleCode allows you to do such things as set default values on a Page upon Page entry, execute SQL statements to update the database, or conditionally change a Page based upon your own criteria.

UConn may require unique records/Pages for which additional PeopleCode programs will need to be written. In order to differentiate changed and new programs from the delivered programs, a comment standard (see below) must be used when any existing PeopleCode programs are changed or new programs are written. For future upgrades, this will facilitate differentiating Flight PeopleCode from the vanilla PeopleCode that was delivered with the new release. Each time a developer changes PeopleCode or creates new PeopleCode programs; this comment standard MUST be used. Reference the bold type in the following example.

At the top of the PeopleCode object include header comment block containing the following 5 attributes:

1. Author

2. “UConn”

3. Jira ticket / Phire CR

4. Project name

5. Date

6. Overall summary / description of change

Example:

In-line code comments are also required. Example:

Additional PeopleCode Standards include:

• Do not change vanilla code; rather, comment out the original and add new lines with the change(s). This allows for a developer to see exactly what was changed from the original.

• Check the value of the %page or %component global variables to control execution of PeopleCode programs on various Pages.

• Any messages required through PeopleCode should not reference existing PeopleSoft Message Set numbers. Use Message Set number 20000 to add custom messages to the Message Set Catalog under the Utilities Menu for SR, use 21000 for SF, use 22000 for FA, use 23000 for AD. In HCM HR, use 20000, 21000 for PY, 22000 for TL, 23000 for AM and 24000 for RS.

• Individual messages are sequentially assigned.

• Determine whether anyone is making a change to the record you will be working on. If so coordinate efforts. The programmers are responsible for coordinating efforts.

• When making PeopleCode changes, if PeopleCode does not work, don’t leave for the day with an error. Temporarily remark out code until you can start working on it again.

• NEVER add new functions to the PeopleSoft function libraries: FUNCLIB, FUNCLIB_XXXX where XXXX is a PeopleSoft functional extension (i.e. SR, FA, SF) instead use UC_FUNCLIB_WS.

• Use functions--whenever possible—for code that is performed in more than one place to ensure consistent processing and ease of maintenance.

• Create new derived records for new function libraries and NEW derived fields and functions, e.g. UC_DERIVED, UC_FUNCLIB

·         Wherever possible, use existing field names to attach functions to, instead of creating new fields.  All functions written will use the PeopleCode type of “FieldFormula”.  The function name should be descriptive of the processing taking place.  The declaration statement in the calling program specifies which function library to execute the function from.

Application Engine Standards

PeopleSoft Application Engine is a People Tool designed to help you develop background SQL processing programs. Application Engine is designed for batch processing where you have data that must be processed without user intervention. Use peoplecode standards in these programs. Program properties comment what the job is doing.

PeopleSoft Application Engine objects can have 8 bytes for their names, and each name must be unique within Application Engine and not be the same as SQR or COBOL programs.

The following naming conventions apply to all UConn added Application Engine objects:

UC_XX_YYYYYY

Where UC is the company name, XX is the product line, and YYY is the product code.

Examples are UC_FA_ATHL and UC_FA_AWARDS.

Strict adherence to these standards will prevent naming Application Engine objects that cannot be identified back to a system or that overlay an existing object. Program properties comments will be used to describe what the app engine program is doing.

All Application Engines programs must have a run control page and navigation. The run control page should also have a description of what the process does.

Process Definition Standards

The PeopleSoft Process Scheduler allows 8 bytes for process definition names.  The limited size for definition names may require the use of abbreviations for some names. Put the sqr/app engine name in the process definition and enter description and long descriptions. Description should not be process definition name. All custom process definitions should start with UC and should be the sqr name if a sqr in run. Use process type of SQR REPORT instead of SQR PROCESS.

PS Job Standards

Multiple process definitions can be logically linked into a job request to process each request serially or parallel, and optionally initiate subsequent processes from each prior request. The PeopleSoft Process Scheduler allows 8 bytes for process job definition names.  The limited size for job definition names may require the use of abbreviations for some names. All custom PS Jobs should start with UC_. 

PeopleSoft Menu Standards

NEVER delete menu items from the delivered PeopleSoft menus. UConn custom menus should start with an UC_. Menu names should be simple and intuitive, so developers do not have to second-guess the contents or purpose of a menu. Please note: when you properly register a component, the menu is automatically placed in your project.

PeopleSoft SQR Standards

SQR is usually the reporting tool of choice for most of our batch reports, data modification and one time programs.

The naming convention for the output file is as follows:

<SQR name>.LIS - for Reports

<SQR name>.DAT - for file extracts

To enhance vanilla reports, it is necessary to change the SQR programs delivered with the PeopleSoft product. PeopleSoft programmers will usually use the SQR utility to build additional reports, interface programs, and other batch programs. When making modifications to vanilla reports you should add comments to the top of the report, along with comments on the lines that you change, delete (use ! in the 1^st column) or add. This will provide clues to users and developers that it is not pure vanilla, if they were unfamiliar with the report and are comparing it against the PeopleSoft documentation. Include a space between your suffix (lowercase “uconn” is recommended) and the report id.

When using temp records (UC_R_sqrname) the sqr should delete the contents of the table before it begins and prior to finishing. This standard will ensure that the table is clear of any other data.

A script has been written that ensures the programmer checks out the sqr from the production environment and saves a backup copy of the sqr. The backup copy will be name with your netid attached. It also ensures that two programmers are not working on the same object at the same time.  All commands are case sensitive.

• Log into the test unix box.

• Move into the ucpsoft directory for the sqr or scripts that you want to checkout.

• Execute the following command to set environmental variable:

                               export UC_HOME=$PR_HOME

• The scripts name to get the script or sqr is: ftp_get_saprod.csh which is followed by the script name or the sqr name.

Examples:    ftp_get_saprod.csh myscript.csh

                     ../scripts/ftp_get_saprod.csh mysqr.sqr

The SQR naming convention standards are:

PeopleSoft delivered SQRs:

SRnnn - Student records related programs

SFnnn – Student Financial related programs

FAnnn – Financial Aid related programs

CCnnn – Campus Community

UConn created SQRs:

USR?xxxn - Student records related programs

USF?nnnn – Student Financial related programs

UFA?nnnn – Financial Aid related programs

UCC?nnnn – Campus Community related programs

UCTSKnnn -Task Tracking programs.

Some modules also use the following standard:

USRnnnnn – Student records related programs

UCSFxxxx – Student Financials related programs 

UFAnnnnn - Financial Aid related programs

The 4^th position of these sqr standards are as follows:  E – extract, I – insert, U – update, R – Report, T – Table.

The 5^th position of these sqr standards are as follows:  E – extract, I – insert, U – update, R – Report, T – Table when using UCSF

Menu items for custom interfaces should be placed under a new “UC Process” or “UC Reports” menu whenever practical.

However, there may be times when it is practical to add a new SQR to an existing menu item.

SQR Comment Standard

The following are excerpts from an SQR program. Please note the comments are expected when any changes are made to an SQR program.

#include 'setenv.sqc' ! Set Environment Procedure

#include 'glbegin.sqc' ! Begin Report Procedure

#include 'setup02.sqc' ! Printer and page-size initialization

!-----------------------------------------------------------------------------------------!

! Procedure: Main-Process

!-----------------------------------------------------------------------------------------!

begin-procedure Main-Process

let #Beginning_Balance = #Ending_Balance - #Total_Activity

if $Activity = 'Y'

print ‘ ‘ (+1,1)

print &A.Account (+1,#Account_Col,7)                                ! kaa 5-16-2006 ServiceRequest#

print &B.KP_Descr55 (0,+#Descr_Col,55)

print &A.Currency_Cd (0,+#Ledger_Curr_Col,3)                ! S. Doe 1-19-2006 ServiceRequest#

end-if

UConn SQR Additional Standards:

• All SQR reports must be tested very well before it is allowed to be run in production.

• Never change a program that exists in the directory PS delivered \sqr directory. This directory should stay untouched and vanilla.

• If modifying a PeopleSoft delivered SQR, move a copy of the SQR from the PS delivered \sqr directory to a development\ucpsoft \sqr directory.

• If the user is to enter an input and/or output file, do not hard code the path. Have the user enter drive and path as part of the input/output file name on the run control page.

• Separate procedures and sections with a commented line of asterisks.

• SQR programs must always be API aware in order to properly update the Process Scheduler if sqr is run online, if it is a batch sqr/mainframe job, it doesn’t have to be API aware.

• All batch sqr/mainframe jobs must create a .lis file even if the report creates nothing. Add End of Report onto the file, so that the ftp will have a .lis file to ftp to the mainframe.

• Test thru script if batch sqr otherwise test thru the menu. Don’t only use SQRW for testing.

• These same procedures apply to SQC modifications.

• P670 is where all test databases and sqr programs are located. P690 is where the production databases and sqr programs are located. i.g. /apps/home/prgmteam/ucpsoft/sqr

  • All SQR’s programs must have a run control page and navigation if it is run on the web. The run control page should also have a description of what the process does.

  • Ensure control totals exist in program. Count everywhere an add, delete or change takes place, as well as records read. Make control totals available on report or in log file.