MMU Upgrade and Enhancements

Project
PeopleSoft Campus Upgrade and
Enhancements Technical Standards
Document

Author: Sreevidya Levaka

Creation Date: 20-Apr-23
Last Updated: 05-May-23
Version: 1.0

Document Control
Change History

Date Author Version Change Details

20-Apr-23 Sreevidya Levaka 0.1 Initial draft
02-May-23 Sreevidya Levaka 0.2 Added ‘New Object Standards’ and ‘Module
Codes’ Sections

Reviewers

Date* Name Position Organisation

05-May-23 Ajay Patel
* Update the date (DD/MM/YYYY) to the date on which the document is finalised to v1.0
 Table of Contents

Purpose............................................................................................................... 3
How to apply Customizations:.............................................................................3
Retrofit Strategy in MMU Upgrade Project:........................................................3
Project Naming Convention:.................................................................................................3
Retrofit work allocation approach:.......................................................................................4
Retrofit Steps:....................................................................................................................... 4
Testing Strategy...................................................................................................4
Unit Testing........................................................................................................................... 5
Detailed Approach for Retrofitting Objects.........................................................5
Fields:.................................................................................................................................... 5
Records:................................................................................................................................ 5
Translate values:................................................................................................................... 6
SQLs:..................................................................................................................................... 6
Pages:.................................................................................................................................... 6
Component:.......................................................................................................................... 6
PeopleCode Retrofitting:.......................................................................................................6
Component Interfaces Retrofitting:......................................................................................7
Application Engine Retrofitting:............................................................................................7
Application Package and their peoplecode Retrofitting:.......................................................8
HTML Retrofitting:................................................................................................................ 8
Objects modified through PIA:..............................................................................................8
XMLP Reports:.......................................................................................................................8
SQR Reports:......................................................................................................................... 8
Impacted Message Catalogue Sets:......................................................................................8
New Object Standards:........................................................................................9
Module Codes:..................................................................................................12
 MMU Upgrade Methodology Document
Purpose:
This document has been created in order to benchmark the approach and methods to be used by
development team in order to perform tasks associated with MMU Upgrade and Enhancements
project.

The document contains methodology to be used for retrofitting along with common approach to
identify and resolve any issues beforehand during retrofitting, testing and review.

How to apply Customizations:

The customizations which are done in production environment should be tracked. Post Initial Pass,
development team needs to retrofit or reapply the customizations:

The two terms which are used in the Upgrade are:

Retrofit and Re-Apply

Retrofitting: Retrofitting means our customizations will be carried forward and we have to bring
back the delivered functionality whenever such functionality is provided by PeopleSoft. Upgrade
options in your project (Change*, Change Copy Yes) mean you are keeping your customizations.

Re Apply: Re applying your customizations i.e., the delivered objects or code will be there, we have
to bring back our customizations. Upgrade options in your project (Change* Change copy No) mean
you are keeping the PeopleSoft delivered Vanilla.

Retrofit Strategy in MMU Upgrade Project:

Based on compare project and keep drop decision, a sheet has been created to retrofit all
components and pages module wise. The same sheet to be followed and used while retrofitting
object and will also serve as a reference for unit testing later. The sheet has been kept under a
SharePoint folder. The link to the same is given below:
<Link to be Updated>

Project Naming Convention:

Each developer will create a project for retrofitting objects based on the following naming
convention:

N_RTRFT_<MODULE>_<DD-MON-YYYY>

MODULE- Refers to three characters of the module name (Module codes)

Every retrofitted project item should be included within the project.

Every retrofitted object should have retrofit comments:
Top Line comment – When writing code from scratch
/**************MMU Upgrade Project (OCS)***************/
Developer Name: <Developer Name>
Date: DD-MON-YYYY
Reason/Description: Retrofit –Added custom fields to the record
/***************************************************/
AND
Short comment, when modifying code in an existing code.
<*Begin - Developer Name- DD-MON-YYYY -Comments*>
<*End*>
Projects will be merged module wise to create a master project for each module later.

Retrofit work allocation approach:

As per the master keep drop decision sheet, work will be allocated module wise to each developer.
The allocation sheet is kept in SharePoint and will be used to track work progress as well.

Retrofit Steps:
Below are the steps to be followed by each developer for retrofitting objects:

1. change/add: - TL to assign the CEMLI (Component/App Engine/ or any object) to developer

preferable module wise, however there could be exceptions based on other priorities as per
project.
2. Developer to create the project definition as per naming convention.
3. Include all objects into project (Very Important – Object migration sheet). The same details
should be updated in the master work allocation sheet, object wise. Excel sheet should have
checks to include all peoplecode, records, objects such as HTML etc. embedded on page.
4. For Custom Modify: Tally the customizations with compare report and do necessary retrofit.
5. For Bolt-On: Look for all peoplecode/ SQL retrofits as required.
6. Remove unwanted objects from project.
7. Fill the checklist as placed in SharePoint folder for each project.
8. Unit test all the transactions for the retrofitted module, Master keep drop decision sheet should
be used as reference to create test scenarios for each transaction. The expectation is that:
there should be no error on the page while performing transaction (should perform as in
CAMPUS 9.2 COP instance).
9. The UI for the transaction should match closely to CAMPUS 9.2 COP (there should be no
alignment related issues due to retrofitting).
10. Screenshots should be captured in the UT script.
11. Create a folder in the SharePoint with UT script, object migration sheet.
12. Notify the TL, once the testing is completed.
13. TL should assign the module for peer review. RCL should be updated by reviewer for review
defects/comments.
14. Developer should fix issues reported in RCL. The RCL should also be placed in the project folder.
15. The above created folder will be used to create a release pack for QA purpose.

Testing Strategy
 The developer needs to ensure that a given module retrieves and updates desired data without
jeopardizing the integrity of the database.
 The Keep drop master decision sheet will serve as a reference point for Unit Testing.
 As soon as retrofitting for one module is complete, it can be tested page by page based on
navigations provided for each page within the module in the underlying sheet.
 The expectation from Unit Testing will be that apart from standard functionality, all
customizations should function in the same way as in existing 9.0 environment.

The following points should be tested to make sure that each component works well:
1. Look and feel of the custom fields on the page should match to that of the page in source
application (PeopleSoft 9.0 CAMPUS instance for MMU).
2. The transaction on the page should happen without any error, except in the case if transaction
has an error due to customization in the source application as well.
3. For application engines, SQRs and XMLP reports, the output format should match to the format
as generated in source application (PeopleSoft 9.0 CAMPUS instance for MMU).
4. Links or secondary pages, associated to the primary page should also confirm functionality and
look feel for customizations brought forward.
5. Unit Test script should be created for each component/page which should capture screenshot as
well as status of the test case. Standard Unit test template can be used for that purpose.

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.

Unit Testing
The developer should take the following steps:
1. Capture each component /page transaction associated with the module in the test cases
2. Set up test data. Always try to use existing data unless impossible.
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).

Detailed Approach for Retrofitting Objects:

As per the standard approach, all bolt on objects for MMU will be brought forward during upgrade.
Once all the bolts on objects are in place, the following sequence needs to be followed in terms of
retrofitting objects:

Fields:

Identify fields impacted by upgrade using compare report and retrofit all the fields. Developer to
take approval from Tech Lead before retrofitting the field.

Records:

Identify records impacted by upgrade using compare report and retrofit all the impacted records.
Developer to take approval from Tech Lead before retrofitting the field.
As per MMU upgrade decision, all the fields, records and translate values will be moved in and none
will be dropped.
While building the records, make sure that alter option is chosen. Create /Recreate option should
not be selected.

Translate values:

All the translate values will be moved in from CS 9.0 Version to the upgraded environment.

SQLs:

All the SQL Objects will be moved in from CS 9.0 Version to the upgraded environment.

Pages:

1. To retrofit the custom modified pages, use compare reports to identify the changes. Based on
report, modify page as required. Once modified, Order tab of the page should be referred and
custom page controls should be in sync with that of the original page. Existing COP environment
should be used in order to verify the page controls.
2. Approach for Bolt On Pages - For bolt on pages, following check need to be performed: Verify
the page controls on order tab with respect to COP environment. Compare look and feel of the
page with respect to COP page using PIA. Make sure that all the objects related to the page
should be included within the project.

Component:
To retrofit Components, changes should be made based on compare reports. The following things
should also be verified while retrofitting components:

All the associated component peoplecode, page peoplecode and record peoplecode should also be
retrofitted and verified based on compare reports. Not only this will simplify the testing process but
will also help to track the work and completion status based on master sheet, component/
navigation wise.

Note: Once we mark Component Retrofitting status as complete, we need t o make sure that every
associated object/item with that component has been retrofitted.

PeopleCode Retrofitting:
There are compare projects placed for each component in the central repository. The path is as
given below:
<Path to be updated>

Retrofit all the peoplecode using the project compare report. Following points should be considered
while retrofitting peoplecode:

Top Line comment – When writing code from scratch

/**************MMU Upgrade Project (OCS)***************/
Developer Name: <Developer Name>
Date: DD-MON-YYYY
Reason/Description: Retrofit –Added custom fields to the record
/***************************************************/
AND

Short comment, when modifying an existing code.

<*Begin - Developer Name- DD-MON-YYYY -Comments*>
<*End - Developer Name- DD-MON-YYYY -Comments*>

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.

Component Interfaces Retrofitting:

 All custom CIs should be identified and listed in a sheet which are based on delivered
components.
 A separate project should be created for these CIs and each of them should be validated to
ensure consistency.
 Comments should be placed on each CI is corrected and revalidated as per the standards
identified above.
 Any CI peoplecode should also be retrofitted as identified from compare reports. Header and
footer comments should be placed for all peoplecode retrofitting.

Application Engine Retrofitting:

Application Engine allows comments to be added to the step using a right click. Comments should
be used to indicate changes made, date, and developer as described above.

PeopleCode and SQL coding conventions should be followed when placed within an App Engine
program
Ensure to include retrofitted objects within the retrofit project.
Application Package and their peoplecode Retrofitting:

 A separate project should be created for App Package retrofitting. Identify changes based on
compare report and retrofit Application Package and their corresponding peoplecode.
 Retrofit comments should be placed within Application package properties as well as header
and footer comments should be included for peoplecode retrofitting.
 All retrofitted service operation handler code should also be placed in the same project.

HTML Retrofitting:
Custom modified HTML objects should be retrofitted based on compare reports and placed in a
separate project.

Objects modified through PIA:

All process definitions, services, Service Operations, portal registry structures and permissions which
are to be retrofitted via PIA should be placed in a separate project.

XMLP Reports:
Identify all XMLP reports to be retrofitted from the Keep Drop decision sheet.
The source environment (COP) should be referred to retrofit changes if any.
SQR Reports:
SQR reports to be retrofitted should be compared with 9.0 COP version using compare tool and
retrofitted based on identified customizations:

The change history section of the sqr should be updated as mentioned below:
! *******************MMU: CS Upgrade Project (OCS)*************************
! Developer Name: <Developer Name>
! Date: DD-MON-YYYY
! Reason/Description: Retrofitted
!***********************************************************************

Header and footer comments should be placed to enclose the changes made within the sqr:
! Begin Changes: MMU Upgrade Project <programmer name > - DD-MON-YYYY - <Description>
<retrofit changes>
! End Changes: MMU Upgrade Project <programmer initials> - DD-MON-YYYY

Impacted Message Catalogue Sets:

Query and compare message sets with respect to source and target database.
Identify if any delivered series has been used, Update that using Message catalogue tables
Use Find in under entire peoplecode to search that series and correct it before upgrade.
SQL to find a specific message set (e.g., 26000) within existing peoplecode:
select * FROM PSPCMTXT where PCTEXT like '%26000,%'

Peoplecode identified in this manner can be listed down and retrofitted with the updated series as
required.
Any custom series to be used should start with message set > 20000
New Object Standards:
Please be noted that the name length of the object cannot exceed the below limit:

Object Name Length

Field 18
Record 15
Page 18
Component 18
Component Interface 30
Menu 30
SQL Object 30
File Layout 30
Application Engine 12
Application Package 30
Project 30

Module Code below refers to three characters of the module name (Module codes)

Project Properties:
Name- N_ENH_<Module Code>_<Meaningful Name>
Description- <Purpose of this Project creation>
Comments-
/********MMU Upgrade and Enhancement Project (OCS)*******/
Developer Name: <Developer Name>
Date: DD-MON-YYYY
Description: <Description of the enhancement stating purpose of this Project creation>
/*****************************************************/

Field Properties:
Name- N_<Meaningful Name>
Field Definition-
/********MMU Upgrade and Enhancement Project (OCS)*******/
Developer Name: <Developer Name>
Date: DD-MON-YYYY
Description: <Description of the enhancement stating purpose of this Field creation>
/*****************************************************/

Record Properties:
Name- N_<Module Code>_<Meaningful Name>_<Record Type>
Description- <Purpose of this Record creation>
Record Definition-
/********MMU Upgrade and Enhancement Project (OCS)*******/
Developer Name: <Developer Name>
Date: DD-MON-YYYY
Description: <Description of the enhancement stating purpose of this Record creation>
/*****************************************************/

If the development requires multiple level of views with build dependencies,

make use of the build sequence property and give the correct sequence number so that you won’t
face any issue while project migration.
Page Properties:
Name- N_<Module Code>_<Meaningful Name>_PG
Description- <Purpose of this Page creation>
Comments-
/********MMU Upgrade and Enhancement Project (OCS)*******/
Developer Name: <Developer Name>
Date: DD-MON-YYYY
Description: <Description of the enhancement stating purpose of this page creation>
/*****************************************************/

Component Properties:
Name- N_<Module Code>_<Meaningful Name>_CMP
Description- <Purpose of this Component creation>
Comments-
/********MMU Upgrade and Enhancement Project (OCS)*******/
Developer Name: <Developer Name>
Date: DD-MON-YYYY
Description: <Description of the enhancement stating purpose of this Component creation>
/*****************************************************/

Component Interface Properties:

Name- N_<Module Code>_<Meaningful Name>_CI
Description- <Purpose of this Component Interface creation>
Comments-
/********MMU Upgrade and Enhancement Project (OCS)*******/
Developer Name: <Developer Name>
Date: DD-MON-YYYY
Description: <Description of the enhancement stating purpose of this Component Interface
creation>
/*****************************************************/

File Layout Properties:

Name- N_<Module Code>_<Meaningful Name>_FL
Description- <Purpose of this File Layout creation>
Comments-
/********MMU Upgrade and Enhancement Project (OCS)*******/
Developer Name: <Developer Name>
Date: DD-MON-YYYY
Description: <Description of the enhancement stating purpose of this File Layout creation>
/*****************************************************/

Application Engine Properties:

Name- N_<Module Code>_<Meaningful Name>
Description- <Purpose of this Application Engine creation>
Comments-
/********MMU Upgrade and Enhancement Project (OCS)*******/
Developer Name: <Developer Name>
Date: DD-MON-YYYY
Description: <Description of the enhancement stating purpose of this Application Engine creation>
/*****************************************************/
Enter the comments at Section/Step/Action level accordingly.

Application Package Properties:

Name- N_<Module Code>_<Meaningful Name>
Description- <Purpose of this Application Package creation>
Comments-
/********MMU Upgrade and Enhancement Project (OCS)*******/
Developer Name: <Developer Name>
Date: DD-MON-YYYY
Description: <Description of the enhancement stating purpose of this Application Package creation>
/*****************************************************/

HTML object Properties:

Name- N_<Module Code>_<Meaningful Name>_HTML
Description- <Purpose of this HTML creation>
Comments-
/********MMU Upgrade and Enhancement Project (OCS)*******/
Developer Name: <Developer Name>
Date: DD-MON-YYYY
Description: <Description of the enhancement stating purpose of this HTML creation>
/*****************************************************/
Comments inside HTML-
<! – Created/Modified by Developer Name on DD-MON-YYYY for MMU Upgrade and Enhancement
Project-->
<! -- Description of the enhancement stating purpose of this HTML creation -->

SQL object Properties:

Name- N_<Module Code>_<Meaningful Name>
Description- <Purpose of this SQL creation>
Comments-
/********MMU Upgrade and Enhancement Project (OCS)*******/
Developer Name: <Developer Name>
Date: DD-MON-YYYY
Description: <Description of the enhancement stating purpose of this SQL creation>
/*****************************************************/

PeopleCode Comments:
Top Line comment
/*******MMU Upgrade and Enhancement Project (OCS)*******/
Developer Name: <Developer Name>
Date: DD-MON-YYYY
Description: <Description of the enhancement stating purpose of this PeopleCode>
/****************************************************/
AND

Short comment, when modifying an existing code.

<*Begin - Developer Name- DD-MON-YYYY -Comments*>
<*End - Developer Name- DD-MON-YYYY -Comments*>
Module Codes:
Module Description Module Code
Admission - Application, Recruitment & Agent ADM
Finance - Credit Mgmt, Billing, Collection FIN
Student Activities Management SAM
Programme Management PGM
Credit Transfer Data Bank & Online Application of CT for External Students CTD
Eligibility Check and Offer ECO
Student Pass STP
APEL.C Application and Assessment APA
Learning and Assessment LAS
Attendance Roster and Barring ARB
Registration and External access REA
Final Year Project (FYP) FYP
Student Self Service Fluid SSS
Academic Ancillary Services AAS
Further Study FST
Candidature Management and Thesis management CTM
Graduation GRD
Industrial Training ITR
Attendance ATT
Exams and OBE EXO
Exam EXM
Academic Advisory AAV
Remedial Programme RMP