Cheri Polenske Application Development Coordinator Central

Administration for University of Nebraska and Nebraska State Colleges

20+ years supporting Student Information Systems, 6 years supporting PeopleSoft

Denise Goin PeopleSoft Security Central Administration for

University of Nebraska and Nebraska State Colleges

17+ years of experience with the PeopleSoft software in Higher Ed, City Government, K-12 and Public/Private Commercial sector.

UNL

UNCA

UNO

Lincoln

Wayne

WSC

UNK Kearney

CSC

Chadron

PSC

NCTA Curtis

UNMC

Peru

Omaha

NeSIS consists of 4 Universities, 1 Technical College and 3 State Colleges

2 separate environments Universities

State Colleges

Campus Solutions

Enterprise Portal (with 7 unique portals in the 2 environments)

Single Shared EPM

Our Security Team 2.5 Central Security Staff and each

campus has their own Security Coordinator

Our Technical Application Support Team 6.5 Central Application Staff with

additional campus developers 2 student interns

Our PS Admin Team 4 Central Administrators

Applying Application Bundles, Security Patches and PeopleTools Upgrades are always challenging, University of Nebraska has established a method of analyzing and retrofitting mods (gasp) for objects and security that works well for us, and at the same time creating a “minimum testing” guide.

Security Analysis

Application Development Analysis

Create the Security Project (DEMO)

Get all Project names that were applied for this maintenance period

Combine them into 1 project, or create a copy of each one for “security use”

Always create your OWN projects, do not compare the delivered projects

Analyze the Compare Reports

Permission Lists

Menus

Components and Pages

CREFS

Create “Deleted” project in DEV

Starting with the Permission List Compare Report Look for new items (Source) and removed items (Target)

I use Highlighters and make notes!

Create a bundle specific permission list (CS_NBA_BUNDLE28) Make a display only version of the bundle permission list

(CS_NBA_BUNDLE28_DISP)

Add the new permission list to the ALL Pages (custom) role CS_NBA_ALLPAGES and the display only one to the all pages display only role

Once I am done with the Permission list, I take notes and look at component changes, cref changes just to double and triple check!

When we do a bundle we must copy all impacted folders from

the Employee portal to the Schools specific portal

We must insert all of the new crefs into a project to copy

to the enterprise portal from each of our schools portals

We also must create a “delete” project for any crefs that

are being deleted from the Employee portal so that we

can remove them from the schools portals

COMPARE REPORTS

DO NOT ALWAYS

MATCH THE REAL

COMPONENT

NAME!! How do I

determine which is

correct? By side by

side analysis of

permission lists and

looking at the

menu item in app

designer.

Run queries in development looking for permission lists with

that component or a similar component

FA- %ISIR%, %INAS%

We are pretty much down to a couple of permission lists, one

update and one display only for each of these functional areas

and we simply add the next years to the same permission list with

the current years, same thing with history pages

Some of the “components” do not match between compare

reports and the PSAUTHITEM table

Use PeopleTools > Portal > Structure and Content

Security tab lists all permission lists with any access to the

component

In development most people have clones of PS (minus a

couple of roles)

In Test most “power testers” have our custom “All Pages” role

so they can test the new functionality as soon as the bundle

moves into test. Each Bundle permission list gets added to

the “all Pages” role.

In QA we have retained close to Production security, this is

where they should be testing that they can get to the pages

that they need with their campus security. We tell them if

they don’t see it in QA they will not see it in PRD!

Our PS Admins also run compare

reports from our DMO/vanilla

instances to our DEV instances.

The App Dev team analyzes those

compare reports for any tools objects

that may overwrite/impact local

customizations/modifications.

With app designer, in the source (DMO)

instance, open each maintenance project,

go to the Upgrade tab and click on each

object type.

Review the list at the right looking for any

object with ‘*Changed’ in the Target column.

This indicates a local modification.

Open each *Changed object with app

designer in the target instance to

review the object properties/code.

• Take note of the modification number and developer

from the object properties. Also take note of the object

detail changes from the compare report. This

spreadsheet will serve as the master list of mods to be

reapplied, retrofitted or decommissioned as well as

thoroughly tested.

For file objects, we look in the technical

documentation released from Oracle. (CS

BNDL 28 – RESOLUTION_888834)

For any delivered file object that we have

modified, we have created a custom folder

on our file system for the various categories

of file objects.

Add the affected file objects to the bundle analysis spreadsheet.

Prepare a spreadsheet with a list of all custom

component interfaces from your target instance.

Lesson learned (and learned again) is to double

check all custom CIs.

Once the bundle has been

successfully applied to the DEV

instances, the developers begin

analyzing each object entered on the

spreadsheet to determine if each

modification is still needed.

If needed, the developers reapply or

retrofit the code in the DEV instances.

Remember to modify the code as well

as the properties of each object.

LET THE

TESTING

BEGIN!!!

Denise Goin

PeopleSoft Security Specialist Central Administration for University of Nebraska and Nebraska State Colleges

E-mail: dgoin@nebraska.edu

Cheri Polenske

Application Development Coordinator Central Administration for University of Nebraska and Nebraska State Colleges

E-mail: cpolenske@nebraska.edu