8/21/2019 Fin Upgrade Tech Architecture Sample
1/20
Page 1 of 20
M-Pathways Financial Upgrade
Preliminary ArchitectureMay 24, 2004
BACKGROUND
This document is intended as a summary of the preliminary plans for the M-Pathways PeopleSoft Financials 8.8upgrade. The hope is that this document will allow members of the project team to understand the technical
environment better.
It is almost certain that changes to the infrastructure design will occur over the course of this project. Either thisdocument will be updated accordingly, or replacement documents will be created and distributed to the projectteam to articulate any changes.
HE AND FIN INTEGRATION
The design of the PeopleSoft infrastructure will isolate the Financial and Higher Education (HE) environments asmuch as is practically possible. For efficiency, many of the central non-PeopleSoft specific components are
shared.
The table below indicates which components will be shared, and which will be isolated:
Separate Financial and HE Components Shared Components
Production Web Servers Non-Production Web ServersProduction Report Repository Web Servers
All Database Servers Non-Production Application Servers
Crystal, nVision, Workflow Servers Production Application Servers
Production Data Warehouse Server
Non-Production Data Warehouse Server
3rdParty Software Servers including:
- Dazel- EDI- Adobe Output Central Pro- Unicenter
Interface (FTP, SSH) Server
Web Load Balancer & SSL Accelerator
Backup & Recovery Servers
Storage Area Network
Network
ITCS CoSign Servers
8/21/2019 Fin Upgrade Tech Architecture Sample
2/20
Page 2 of 20
ACE Server
Firewall Hardware
Fileserver (J: drive)
ITS LINC Infrastructure
Wolverine Access Gateway JSP Pages
DATABASE INSTANCES (DURING THE UPGRADE)
The table below lists all of the PeopleSoft 8 database instances that will exist during the upgrade, and theiranticipated uses:
Database Size Users Description of Usage
FinDem88 Demo CPU - Validation of delivered functionality- Staging of patches and fixes- Fit/Gap Analysis- Full Compare Reports
FinPTUp8 Demo TIO-
PeopleTools Upgrades- Custom Compare Reports
FinMch88 Demo CPU - Experimentation with development tools- Research on development approaches- Preliminary design of customizations
FinDev88 Production CPU - Development of customizations- Unit testing
FinStr88 Production TIODesignated CPU
- Tuning of online and batch programsFinWork1 Production TIO
CPU
- Target for first test move- QA environment after first move is complete- System testing- Definitive source for all upgrade objects
FinWork2 Production TIO
CPU (PRT only)
- Target for all test moves (after test move #1)- Production Readiness Test
After the upgrade is complete, databases will revert back to the same configurations and usage patterns as usual,except the FinQA88 and FinDev88 databases will be production-sized.
8/21/2019 Fin Upgrade Tech Architecture Sample
3/20
Page 3 of 20
ENVIRONMENT TIMELINE
The following table illustrates when each PeopleSoft 8 environment will exist, and on what server the database,
application and web servers will be located.
Database
Instance
Name
2004 2005
Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May
FinDem88 DBase: Mudhen
AppSrv: Catbird
WebSrv: Catbird
FinMch88 DBase: Mudhen
AppSrv: Catbird
WebSrv: Catbird
FinWork1 DBase: Thrasher
AppSrv: Catbird
WebSrv: Catbird
DBaseThrasher
AppSrvCatbird
WebSrvSeparate machine from Catbird(TBD)*
FinWork2 DBase: New Nighthawk
AppSrv: Catbird
WebSrv: Catbird
FinDev88 DBase: Thrasher, with CPUs and Ram
from old Kingbird**
AppSrv: Catbird
WebSrv: Catbird
DBase: Mudhen***
AppSrv: Catbird
WebSrv: Catbird
FinStr88 DBase: Thrasher, with CPUs and Ram
from old Kingbird**
AppSrv: CatbirdWebSrv: Catbird
DBase: Mudhen***
AppSrv: Catbird
WebSrv: Catbird
FinQA88 DBase: Chickadee
AppSrv: Catbird
WebSrv: Catbird
FinProd(88) DBase: New
Nighthawk
AppSrv: Stilt, Noddy
WebSrv: Smew, Potoo
FinODS(88) DBase: Chickadee
AppSrv: Penguin
WebSrv: Drongo
= Exists = Does Not Exist
* - In order to make the FinWork1 environment as much like production as possible for system testing, we areanticipating the need to move the Webserver for FinWork1 to a separate machine. That machine is to be
determined.
8/21/2019 Fin Upgrade Tech Architecture Sample
4/20
Page 4 of 20
** - We learned form the HE upgrade that thrasher cannot simultaneously run three production-sizedinstances without significant performance degradation. In order to mitigate this risk, we are proposing to add
memory and processors to thrasher from old-kingbird. Amounts are to be determined.
*** - Mudhen does not have spare CPU cycles or memory for extra databases. Mudhen cannot be expandedany further so an alternative solution for this problem will be determined.
ENVIRONMENT DECOMMISSIONS
Version 7.5 database instances and all accompanying infrastructure components such as application server,process schedulers, workflow servers, directory structures and configuration files will be decommissioned on
approximately the following schedule:
Decommission Date Database Instance Name(s)
March 2004 FinMch75
March 2005 (the week following go-live) FinDev75, FinQA75, FinStr75, FinODS(75)
May 2005 FinProd(75), renamed to FinOld75
8/21/2019 Fin Upgrade Tech Architecture Sample
5/20
8/21/2019 Fin Upgrade Tech Architecture Sample
6/20
Page 6 of 20
ARCHITECTURE OVERVIEW - PRODUCTION
The diagram below depicts the main components that will make up the PeopleSoft 8 Financials Productionsystems once the upgrade is complete in March 2005. Preparation of many of the production infrastructure
components will occur well before golive according to a detailed infrastructure rollout plan that has yet to bedeveloped.
FinProd
WebSvr
Potoo
Smew FinProd
WebSvr
Penguin
Noddy
Stilt
FinProd
NewNigh
thawk
WebBrowsers
NewWin
tel1
nVisionCrystal
Reports
PSNT
Proc
Sched
PSUNX
Proc
Sched
Dist
Agent
FinProd/
ODS RR
WebSvr
Chat FinODS
WebSvr
Drongo
Dist
Agent
FinODS
NewChic
kadee
PSUNX
Proc
Sched
Dist
Agent
nVisionCrystal
Reports
PSNT
Proc
Sched
Dist
Agent
FinProd
AppSvr
FinProd
AppSvr
FinProd/
ODS RR
FinODS
AppServer
8/21/2019 Fin Upgrade Tech Architecture Sample
7/20
Page 7 of 20
SOFTWARE VERSIONS
The following table lists all of the software that is (or will be) used by the M-Pathways systems. Where known,upgrades are indicated. Minor upgrades (patches, fixes) should be expected through out the year of the upgrade.Major upgrades will be scheduled in advance, and for the most part should be indicated below.
Software Current
Version
Anticipated
Version
TIO
Contact
Person
Notes
AIX 5.1 5.2 Chris Wood
Aspen (ITSLINC) 2.3 2.3 DavidSweetman
Business Objects 5.1.8 6x Terry Houser Upgrade is not currentlyscheduled, but anticipated
after the upgrade.
CheckPoint Firewall Paul Howell
Crystal Reports 6.0 9.0 Hai Hoang Two versions of CrystalReports cannot reside on the
same server concurrently.
Dazel Nancy Medd
ESS StorWarch Expert Nancy Medd
Inovis EDI 6.1 6.1 David Nowell May change to direct FTPtransfer method
Adobe Output Central Pro 5.3 5.5 Brian McRae Formerly Jetform
COBOL ObjectCOBOLDeveloper
Suite 4.1
ServerExpress 2.0.11service pack 1
Terry Houser
nVision n/a n/a Hai Hoang Currently only used by Fin
Oracle 9.2.0.5 9.2.0.5 Cheryl VanKirk
PeopleTools 7.6x 8.44 Terry Houser May change, depending onreleases from PeopleSoft
SQLLab (Quest Central) Various 4.0 Judy Smutek
SSH Paul Howell
STAT 4.1.8 5.0.1 Judy Smutek
SyncSort
Tivoli Storage Manager 5.1 5.2 Lisa LeeTuxedo 6.5 8.1 Brian McRae
Unicenter 2.4 2.4 Bob Hannah
Vista Plus 5.1 5.1 Rob Robertson
WebLogic n/a 8.1 ServicePack 1
Betty Simonis HE currently uses WebLogic5.1 Service Pack 12
JRE n/a 1.4.1 Betty Simonis HE currently uses JRE 1.3.1
8/21/2019 Fin Upgrade Tech Architecture Sample
8/20
Page 8 of 20
8/21/2019 Fin Upgrade Tech Architecture Sample
9/20
Page 9 of 20
NETWORKLOGICAL DESIGN
The following diagram depicts the logical design of the network which will support the M-Pathways Financialsystems. This diagram is intended to give a perspective of where each system resides in the network without theunderlying technical details of network configuration.
PRODUCTION HARDWARE
The preliminary hardware proposal for the Financial 8.8 PeopleSoft infrastructure is below.
FINPROD Database Server
nighthawk.dsc.umich.edu (Regatta 5New)
Database ServersDatabase Servers
Database ServersSecondary(Fail-over)
Load Balancer
Web
Browsers
Secondary(Fail-over)Firewall
Primary Firewall
Secure ZoneNetwork Switch
DMZNetwork Switch
Load Balancers &SSL Acceleration
Interface Server(Flamingo)
Database Servers
Database ServersDatabase Servers
Database ServersApplication Servers
PeopleSoft
2-Tier Clients
Campus Network Campus Network
Web
Browsers
Secondary(Fail-over)Firewall
Routers
Database ServersDatabase Servers
Database Servers
Crystal, nVision,Workflow Servers
Web Servers
Web ServersWeb Servers
Web Servers
8/21/2019 Fin Upgrade Tech Architecture Sample
10/20
Page 10 of 20
Hardware: IBM p690 LPAR with 8 1.5Ghz CPUs, 8 GB RAM, based on new Power5 architecture
FINPROD Application Servers
Add 10GB RAM to and share existing HEPROD Application Server LPARs
noddy.dsc.umich.edu (Regatta 4)Hardware: IBM p690 LPAR with 16 1.1Ghz CPUs, 26 GB RAMstilt.dsc.umich.edu (Regatta 3)
Hardware: IBM p690 LPAR with 16 1.1Ghz CPUs, 26 GB RAM
FINPROD Web Servers
smew.dsc.umich.edu (Regatta 4)Hardware: IBM p690 LPAR with 1 1.1Ghz CPUs, 5.5 GB RAM
potoo.dsc.umich.edu (Regatta 4)Hardware: IBM p690 LPAR with 1 1.1Ghz CPUs, 5.5 GB RAM
FINPROD Report Repository
Add 2GB RAM to and share existing HEPROD/HEODS Report Repository LPARchat.dsc.umich.edu (Regatta 4)Hardware: IBM p690 LPAR with 3 1.1Ghz CPUs, 6 GB RAM
FINODS Database Server
chickadee.dsc.umich.eduHardware: IBM S7A with 8 251Mhz CPUs, 10 GB RAM
FINODS Application Server
Add 3GB RAM to and share existing HEODS Application Server
penguin.dsc.umich.eduHardware: IBM S80 with 12 451Mhz CPUs, 15 GB RAM
FINODS Web Server
drongo.dsc.umich.edu (Regatta 4)
Hardware: IBM p690 LPAR with 1 1.1Ghz CPUs, 2 GB RAM
FINODS Report Repository
Add 2GB RAM to and share existing HEPROD/HEODS Report Repository LPARchat.dsc.umich.edu (Regatta 4)
Hardware: IBM p690 LPAR with 3 1.1Ghz CPUs, 6 GB RAM
Net Production Hardware Changes
Regatta 3:
Add 10GB RAM.
. Add 10GB RAM to existing stilt LPAR (FINPROD Application Server #1)
Regatta 4:
Add 8 1.1Ghz CPUs and 32GB RAM. Add 0 CPU / 10GB RAM to noddy LPAR (FINPROD Application Server #2)
. Add 0 CPU / 2 GB RAM to chat LPAR (FINPROD&FINODS Report Repos.)
. New 1 CPU / 5.5GB RAM LPAR for smew (FINPROD Web Server #1)
. New 1 CPU / 5.5GB RAM LPAR for potoo (FINPROD Web Server #2)
. New 1 CPU / 4.5GB RAM LPAR for drongo (FINODS Web Server)
8/21/2019 Fin Upgrade Tech Architecture Sample
11/20
Page 11 of 20
Regatta5:
New Regatta with 8 ???Ghz CPUs* and 8GB RAM
* - Would like to delay purchase until Power5 chips are available).. Add 8 CPU / 8GB RAM LPAR for nighthawk (FINPROD database server)
Penguin:Add 3GB RAM.
. Support addition of FINODS Application Server processes
8/21/2019 Fin Upgrade Tech Architecture Sample
12/20
Page 12 of 20
FIREWALL POLICY SUMMARY
Security and Network Services will evaluate the network traffic associated with each application, and determinethe appropriate firewall policies to implement to help secure the system properly. Most of the policies that are
implemented are easily identifiable, and have no direct effect on end-users or developers.
There are several policies that have generated discussions in the past. These include:
Direct database access outside of the ITS Data Center is generally blocked. The main exceptions to thispolicy are the M-Pathways Data Warehouse, and the Operational Data Store, both of which areaccessible on the U-M campus network (but not on the Internet).
Non-Production web systems are only available on the U-M campus network. File transfers to any of the servers in the Secure Zone is strictly limited. File transfers must occur to the
Interface Server, and then files are moved from the Interface Server to the appropriate servers in the
Secure Zone.
FILE TRANSFER (INTERFACE) ARCHITECTURE
Whenever possible we will be use Flamingo, the dedicated ITS file transfer interface server, as our sole point of
contact with non-ITS servers for file transfers. This will be accomplished via remote calls/command processingand transfers of files between Nighthawk and Flamingo. When files need to be sent or retrieved from another
server, the FTP interface script residing on Flamingo (in the DMZ) will be executed by a remote call onNighthawk (in the Secure Zone). The Interface Architecture scripts are already in place for Financials 7.5 andmore processes are beginning to use this architecture. Major changes to this architecture are not expected with the
move to Financials 8.8
This architecture only pertains to files and file transfer interfaces. If direct database links are required, Nighthawkwill be accessed via tightly controlled remote database access links as they are today.
INTEGRATION (BATCH) ARCHITECTURE
The Integration Architecture will be substantially changed to allow batch jobs to integrate more fully withPeoplesoft. In the new version, very non-override process will be initiated by the PeopleSoft Process Scheduler.
This allows users to see batch reports in PeopleSoft Report Manager.
The Integration Architecture uses Unix shell scripts to call a custom-written Java program. This programconnects to a Peoplesoft Component Interface that makes requests to the Process Scheduler. Once the ProcessScheduler indicates that the job has finished, the Integration Architecture then handles Output Management of the
generated reports & files.
Output Management will remain essentially the same. A new option will allow Roles to be granted to reports viaoutput management. Most user reports will no longer go to Vista, but will be available in the PeopleSoft Report
Repository instead. There will be exceptions to this where PeopleSoft functionality does not meet the needs ofour customers. In such cases, reports will be sent to both the PeopleSoft Report Repository and Vista. Complete
analysis of reports currently being generated so these decisions can be made is yet to be done.
LOAD BALANCING
Load Balancing will be accomplished in a very similar manner to the Wolverine Access system implemented withthe upgrade of HE to version 8. We plan to employ the same Cisco 11503 Content Services Switches that
currently balances load across all 18 HEProd Java Virtual Machines (JVMs). This load is balanced using a roundrobin approach. This means that each server is sent requests in a sequential fashion, regardless of its current load
or health status. This approach has worked well for HE and we expect nothing different for Financials.
8/21/2019 Fin Upgrade Tech Architecture Sample
13/20
Page 13 of 20
The load balancers are installed as a redundant pair. If one switch fails, the other will take over in its place andmaintain the state of the web sessions connected through it.
Finally, the load balancers employ hardware-based SSL encryption and decryption routines that greatly improve
performance of the web systems theyre used with. Instead of the webservers executing the instructions toencrypt and decrypt web traffic, the load balancers do this much more quickly and efficiently.
The following is a greatly simplified diagram of traffic flow through a load balancer:
Webserver 1
Webserver 2
Webserver 3
PeopleSoft
Application Server
Nighthawk
Database Server
Client Load Balancerw/ SSL Acellerator
Firewall
SQL
HTTPS HTTP
DMZ Secure Zone
1. Request for https://wolverineaccess.umich.edu
2. Load Balancer responds, terminating the HTTPS or SSL session
3. Checks content rules for a server list4. Finds 3 servers in its list, uses Round Robin to chose first
(Webserver 1)5. Load Balancer opens connection to Webserver 1 and retrieves
request
6. Request is encrypted and returned to client HTTPS
HTTPS (SSL)
HTTP
Firewall
1 2 3 4
5
6
AUTHENTICATION
Authentication to all PeopleSoft Financial 8.8 web systems will be accomplished through CoSign. CoSign is theUniversity of Michigans collaborative effort to design a single-signon web authentication system. This system is
already in use with the ITS implementation of PeopleSoft HE. From a high-level, the Cosign authenticationmechanism is comprised of 2 parts. They include:
1) The Cosign Authentication Filter The CoSign authentication filter currently in use for HE PeopleSoft systems was custom-developed in
Java by ITS staff. The filter resides as code on the WebLogic webserver and is invoked each time a
user attempts to login to protected systems behind the Wolverine Access gateway.
8/21/2019 Fin Upgrade Tech Architecture Sample
14/20
Page 14 of 20
The Cosign filter currently in place for HE systems was developed specifically for the WebLogic 5.1webserver platform running version 1.3.1 of the Java Runtime Environment (JRE). Work isunderway to redesign the filter for use with the anticipated platform for Financials 8.8 WebLogic
8.1.
The cosign filter now in place for HE systems is machine dependent. All webserver JVMs on themachine must use the same filter. The redesign of the filter will make it possible to have filters formultiple versions of webserver JVMs on the same physical machine. For instance, it will be possible
to run a Cosign filter for a WebLogic 5.1 JVM and a WebLogic 8.1 JVM concurrently on catbird.This is not possible with the current implementation of the filter.
2) Signon PeopleCode Signon PeopleCode was custom written by ITS staff within the PeopleTools framework. The code is
invoked each time a user attempts to login to the PeopleSoft system.
In the section below you will find a series of screenshots describing the flow of information with the current
implementation of the CoSign filter. Although the filter for WebLogic 8.1 has not been developed yet, we expectgeneral behavior to be very similar.
1) The user initially connects the Wolverine Access Gateway main page at web address (URL)http://wolverineaccess.umich.edu/index.jsp
2) The user then clicks on University Business link in the Faculty & Staff section.
http://wolverineaccess.umich.edu/index.jsphttp://wolverineaccess.umich.edu/index.jsphttp://wolverineaccess.umich.edu/index.jsp8/21/2019 Fin Upgrade Tech Architecture Sample
15/20
Page 15 of 20
3) The user then gets automatically redirected to weblogin.umich.edu with a web address (URL) similar to theone below:
https://weblogin.umich.edu/?cosignwolverineaccess=ldFBqkhR9dUlqAEsGO ;&https://wolverineaccess.umich.edu/servlets/iclientservlet/heprodop/?cmd=start&authType=1.
At this point, the cosign filter generated a COSIGN CLIENT COOKIE(i.e cosign-wolverineaccess=ldFBqkhR9dUlqAEsGOHwGOfNnAo8ah). In addition, a COSIGN SERVERCOOKIE was assigned by the CoSign (weblogin.umich.edu) server.
4) User enters his/her uniqname and password and clicks Login.
The Login action will trigger a POST to the CoSign server with the COSIGN CLIENT COOKIE, the COSIGNSERVER COOKIE, uniqname and password. Kerberos authentication will occur against the uniqname and
password.
5) If the Kerberos authentication was successful, the user will then be redirected automatically tohttps://wolverineaccess.umich.edu/servlets/iclientservlet/heprodop/?cmd=start&authType=1 .
6) The authentication filter will then create a PeopleSoft cookie and redirect to the same URL again.
https://weblogin.umich.edu/?cosignwolverineaccess=ldFBqkhR9dUlqAEsGOhttps://weblogin.umich.edu/?cosignwolverineaccess=ldFBqkhR9dUlqAEsGOhttps://wolverineaccess.umich.edu/servlets/iclientservlet/heprodop/?cmd=start&authType=1https://wolverineaccess.umich.edu/servlets/iclientservlet/heprodop/?cmd=start&authType=1https://wolverineaccess.umich.edu/servlets/iclientservlet/heprodop/?cmd=start&authType=1https://weblogin.umich.edu/?cosignwolverineaccess=ldFBqkhR9dUlqAEsGO8/21/2019 Fin Upgrade Tech Architecture Sample
16/20
Page 16 of 20
This is necessary to make the cookie available to the PeopleSoft Application Server. The PeopleSoft ApplicationServer subsequently executes the signon PeopleCode which enables authorization routines to determine what
portions of the system as user has access to.
7) At this point, the user has successfully authenticated and is allowed to enter the PeopleSoft system.
REPORT REPOSITORY
The Financials 8.8 PeopleSoft Report Repository for FinProd will reside on an AIX server named Chat. Themajor components of the Report Repository include the directory structures where reports are kept as well as theWebLogic 8.1 webserver that enables users to view their reports and logs over the web. Chat is also the currentlocation for the HEProd Report Repository. Each Report Repository instance is distinct in that they have their
own webserver Java Virtual Machine (JVM) complete with CoSign Authentication that serves the report to theusers. These webserver instances are completely separate and have no dependencies between them. There are
however, some resources these two Report Repositories will share. These include physical disk (on the SAN),
memory (RAM) and CPUs on the Chat server.
CRYSTAL, NVISION AND WORKFLOW
With the implementation of Financials 8.8, Crystal Reports, nVision reports and Workflow processes are allexecuted on a separate, single Windows 2003 server. This Windows server has a Process Scheduler installed(PSNT) and Microsoft Excel (for nVision reports) installed. This is significant change from the current
(Financials 7.5) architecture whereby Crystal Reports are executed on Citrix servers and are distributed directlyfrom that location either through printing or shown in windows within the Citrix session.
When a job is submitted for execution on the PSNT server, it sits in a job queue until the PSNT Process Scheduler
wakes up to kick initiate the job. Initially, this interval will be set to 15 seconds but will be adjusted to improveperformance if necessary. The queue of jobs can be viewed via the Process Monitor within PeopleSoft. When thejob finishes, the output and logfile (if applicable) is sent from the PSNT server to the Financials 8.8 ReportRepository webserver by the PeopleSoft Distribution Agent. The sole purpose of the Distribution Agent is totransfer log and output files, via FTP, to the Report Repository webserver. This process is known as posting.
Once posted, users can then use the Process Monitor or Report Manager to view the log or report output.
The following diagram is a simplified view of a transaction to view a report in the PeopleSoft Report Repository:
8/21/2019 Fin Upgrade Tech Architecture Sample
17/20
Page 17 of 20
1Webserver 1
Webserver 2
Chat
Report
Repository
PeopleSoft
Application Server
Nighthawk
Database Server
Client Load Balancerw/ SSL Acellerator
Firewall
SQL
HTTPS HTTP
DMZ Secure Zone
1. User logs into FinProd using his/her kerberos credentials viaCosign.2. The user enters the Process Monitor of Report Manager pageswithin the FinProd system.3. The FinProd database on nighthawk contains information on thelinks to the reports the user has access to.4. The user clicks on the view log/trace link and is automaticallyredirected and logged into the FinProd report repository webserverusing the same kerberos credentials.5. A new window is generated with the users requested report
information. This window is served up by the Char ReportRepository webserver.
HTTPS (SSL)
HTTP
Firewall
1 2
3
4 5
GATEWAY
The Wolverine Access Gateway is actually comprised of a great number of Java Server Pages (JSPs). These JSPsare the front door to the Wolverine Access system. They are designed to present link options to PeopleSoft and
other systems in the most straightforward way possible while maintaining a consistent look and feel throughout
the website. The function of each of these JSPs are described below:
Page Name (jsp) Description
alumni_secondary.jsp Links to other alumni related pages
data_warehouse.jsp UM Data Warehouse -- No links yet
finODS.jsp FINODS -- No Links yet
finprod.jsp FINPROD -- No links yet
8/21/2019 Fin Upgrade Tech Architecture Sample
18/20
Page 18 of 20
footer.jsp Common footer info on all pages, links to umich.edu,
mais,M-pathways
frequently_asked_secondary.jsp Questions asked about WA
header.jsp Common header info and authentication of user for
displaying the logout button
hours_of_op_secondary_alumni.jsp Hours of operation link to display timings for MyStudent Records, My Alumni Information
hours_of_op_secondary_faculty_staff.jsp Hours of operation link to display timings for faulty
& staff business
hours_of_op_secondary_public.jsp Hours of operation link to display timings for UMCourse Catalog
hours_of_op_secondary_students.jsp Hours of operation link to display timings for StudentBusiness, Undergraduate Orientation
index.jsp Homepage for Gateway Wolverine Access
logout.jsp For logging out of WA --redirects to cosign logoutpage
onsp_secondary.jsp Links to Under Graduate Orientation pages
onsp_secondary_brochures.jsp Information about View Brochures
onsp_secondary_getUniqname.jsp Link to getuniquename, pwd and computing servicesfor orientation
reporting_secondary.jsp Link to all reporting pages
signout.jsp Used to signout from a peoplesoft link
university_biz_secondary.jsp Link to all University Business related pages
vista_plus.jsp Used but no links yet
STAT/MIGRATIONS
Stat will be used for migrations between all Financial 8.8 environments. Initial migration paths will be
established between FinMch88 and FinWork1 as well as FinDev88 (once created in July) to FinWork1.
ORACLE
Oracle v9.2.0.5 running on AIX 5.1 will be the database platform of choice during the Financials 8.8 Upgrade.
Each database server used in the upgrade, development and production architectures will have this version ofOracle installed as well as Pro*C, Pro*COBOL, and Pro*Fortran. In addition, the Oracle v9.2.0.5 client softwarewill be installed on all Application Servers for communication with databases.
DATA WAREHOUSE
The production Financial Data Warehouse database instance will continue to reside on the Parrot server.
The Data Delivery (DD) Team is responsible for the Extract, Transform and Load (ETL) Process from the On-lineTransaction Processing (OLTP) Source Servers (FinProd - Nighthawk and HEProd - Kingbird) to the Data
Warehouse (DW) Destination Server (DWProd - Parrot).
The DD Team uses the SQR tool to write programs that extract and transform the data contained in the OLTPserver datbases. These programs select data from the Oracle tables on the OLTP and write out fixed length data
files.
Extract and load jobsets are created for each DW dataset based and executed according to their refresh schedule(below). The extract jobsets contain all of the extract SQRs for a particular DW dataset and are executed on theOLTP server. The extract jobsets are set up to run on a particular schedule and normally have predecessor jobset
8/21/2019 Fin Upgrade Tech Architecture Sample
19/20
Page 19 of 20
dependencies related to their corresponding OLTP modules or processes. The corresponding load jobsets containboth Unix FTP and load scripts that run on the DW server.
Once an extract jobset has successfully completed, the load jobset will start. In the load jobset, a Unix FTPscript is invoked from the DW server to transfer the data files from the OLTP server to the DW server. Once theUnix FTP script has successfully completed, a Unix load script is invoked that uses SQL*Loader to load the
data into the DW Oracle tables. Users can access the data in the DW using any SQL-based tool or can access thedata through the centrally supported Business Objects tool suite via Citrix.
In version PS version 7.5, DD was able to run their extract SQRs without invoking the process scheduler. Due to
changes in the PS version 8 batch architecture, DD will need to run all of their SQRs through the processscheduler. This will entail obtaining a generic DW batch ID and creating process definitions for every SQR.
Currently the Financial DW tables are refreshed according to the following schedule:
General Ledger, Budget and ProcurementEvery Sunday, the 6thworking day of the month for month end
processing and most nights during the 2ndand 3rdweek in July for year end processing
Asset and Space ManagementEvery Sunday
Utilities and PlantThe last day of the month
Significant changes will be made to the extract and load programs, but these changes have not beendesigned/developed yet.
Below is a graphical representation of the Data Warehouse Extract Process:
8/21/2019 Fin Upgrade Tech Architecture Sample
20/20
FTP using unix shell script & '1' id
FINPROD
Extract usingSQR (PSOFT id)
$datatemp/*.dat files
pa02
OLTP Source Server Data Warehouse Server
Load usingSQL*Loader *.ctlfiles, unix shelllscript, and '9' id
$datatemp/*.dat files
mdwxx.dat
mdwxx.dat
mdwxx.dat
mdw xx .da t md wxx .d at
mdwxx.dat
mdwxx.dat
mdwxx.dat
mdwxx.dat
mdw xx .da t md wxx .d at
mdwxx.dat
Predefined Reports
BusinessObjects
Universes
The centrally supported tool
suite via CitrixHEPROD
1
2
3
Users can access the DW serverusing any SQL-based tool
-OR-
Ad Hoc Queries
Future? -OLAP -Data Mining
Business Objects