M-Pathways Financial Upgrade Preliminary Architecture

yoinkscreechedInternet και Εφαρμογές Web

13 Νοε 2013 (πριν από 4 χρόνια)

177 εμφανίσεις





Page
1

of
20

M
-
Pathways Financial Upgrade



Preliminary Architecture

May 24
, 2004


BACKGROUND

This document is intended as a summary of the preliminary plans for the M
-
Pathways PeopleSoft Financials

8.8
upgrade. 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 this
doc
ument will be updated accordingly, or replacement documents will be created
and distributed to the project
team to articulate any changes
.

HE AND FIN INTEGRATION

The design of the PeopleSoft infrastructure will isolate the Financial and Higher Education (
HE) environments as
much 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 Compon
ents

Shared Components

Production Web Servers


Non
-
Production Web Servers

Production 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


3
rd

Party 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


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 a
ll of the PeopleSoft 8 database
instances

that will exist during the upgrade, and their
anticipated 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

TIO

Designated CPU

-

Tuning of online and batch programs

FinWork1

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.


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

FinM
ch88


D
B
ase: Mudhen

AppSrv: Catbird

WebSrv:
Catbird


FinWork1

D
B
ase: Thrasher

AppSrv:
Catbird

WebSrv:
Cat
bird

DB
ase



Thrasher

A
ppSrv



Catbird

WebSrv



Separate machine from Catbird
(TBD)
*


FinWork2


D
B
ase:
New Nighthawk

A
pp
S
rv:
Catbird

WebSrv:
Catbird


FinDev88


D
B
ase:
Thrasher
, with CPUs and Ram
from old Kingbird
**

AppSrv:
Catbird

WebSrv:
Catbird

D
B
ase:
Mudhen
**
*

AppSrv:
Catbird

WebSrv:
Catbird

FinStr88


D
B
ase:
Thrasher
, with CPUs and Ram
from old Kingbird
**

AppSrv:
Catbird

WebSrv:
Catbird

D
B
ase:
Mudhen
**
*

AppSrv:
Catbird

WebSrv:
Catbird

FinQA88


D
B
ase:
Chickadee

AppSrv:
Catbird

WebSrv:
Catbird

FinProd(88)


D
B
ase:
New
Nighthawk

AppSrv:
Stilt, Noddy

WebSrv:
Smew, Potoo

FinODS(88)


D
B
ase: Chickadee

AppSrv:
P
enguin

WebSrv:
Drongo



= Exists



= Does Not Exist


*
-

In order to make the FinWork1 environment as much like production as possible for system testing, we are
anticipating the need to move the Webserver for FinWork1 to a separate machine. That machine
is to be
determined
.


Page
4

of
20

**
-

We learned form the HE upgr
ade that thrasher cannot simultaneously run three production
-
sized
instances 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 deter
mined.


***
-

Mudhen does not have spare CPU cycles or memory for extra databases. Mudhen cannot be expanded
any 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



Page
5

of
20

ARCHITECTURE OVERVIEW


NON
-
PRODUCTION

(DURING UPGRADE)

The diagram below depicts the main
infrastructure
c
omponents that will make up the PeopleSoft 8 Financials

non
-
Production systems during the upgrade

(March 2004 through March 2005)
. Once the upgrade is complete
some of these components will move to new servers. (
See “Environment Timeline” earlier

in this

document for
more information on
when these environments will be created and where their various infrastructure components
will be located
.)

FinDem88
WebSvr
FinMch88
WebSvr
FinDem88
FinMch88
FinMch88
AppSrv
Catbird
Mudhen
Web
Browsers
TBD
Report
Repos
Report
Repos
nVision
Crystal
Reports
NT
Dist
Agent
PSNT
Proc
Sched
PSUNX
Proc
Sched
Dist
Agent
PSUNX
Proc
Sched
FinDem88
AppSrv
PSNT
Proc
Sched
FinDev88
WebSvr
FinStr88
WebSvr
FinDev88
FinStr88
FinStr88
AppSrv
Thrasher
Report
Repos
Report
Repos
NT
Dist
Agent
PSNT
Proc
Sched
PSUNX
Proc
Sched
Dist
Agent
PSUNX
Proc
Sched
FinDev88
AppSrv
PSNT
Proc
Sched
Web
Browsers
FinWork1
WebSvr
Finwork2
WebSvr
FinWork1
FinWork2
FinWork2
AppSrv
New Nighthawk
Report
Repos
Report
Repos
PSUNX
Proc
Sched
Dist
Agent
PSUNX
Proc
Sched
FinWork1
AppSrv
Web
Browsers
PSNT
Proc
Sched
Dist
Agent
Dist
Agent
Dist
Agent
NT
Dist
Agent
NT
Dist
Agent
NT
Dist
Agent


Page
6

of
20

ARCHITECTURE OVERVIEW
-

PRODUCTION

The diagram below depicts the main components that

will make up the PeopleSoft 8 Financials Production
system
s 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 be
developed.

FinProd
WebSvr
Potoo
Smew
FinProd
WebSvr
Penguin
Noddy
Stilt
FinProd
New Nighthawk
Web
Browsers
New Wintel 1
nVision
Crystal
Reports
PSNT
Proc
Sched
PSUNX
Proc
Sched
Dist
Agent
FinProd/
ODS RR
WebSvr
Chat
FinODS
WebSvr
Drongo
Dist
Agent
FinODS
New Chickadee
PSUNX
Proc
Sched
Dist
Agent
nVision
Crystal
Reports
PSNT
Proc
Sched
Dist
Agent
FinProd
AppSvr
FinProd
AppSvr
FinProd/
ODS RR
FinODS
AppServer


Page
7

of
20

SOFTWARE VER
S
IONS

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 ex
pected 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

(
ITS
LINC)

2.3

2.3

David
Sweetman


Business Objects

5.1.8

6x

Terry Houser

Upgrade is not currently
scheduled, but anticipated

after the upgrade.

CheckPoint Firewall



Paul Howell


Crystal Reports

6.0

9.0

Hai Hoang

Two versions of Crystal
Reports 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 FTP
transfer method

Adobe Output Central Pro

5.3

5.5

Brian McRae

Formerly Jetform

COBOL

Object
COBOL
Developer
Suite

4.1

Server
Express

2.0.11
service 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 Van
Kirk


PeopleTools

7.6x

8.44

Terry Houser

May change, depending on
release
s 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 Lee


Tuxedo

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

Service
Pack
1

Betty Simonis

HE currently uses WebLogic
5.1 Service Pack 12

JRE

n/a

1.4.1

Betty Simonis

HE currently uses JRE 1.3.1







Page
8

of
20



Page
9

of
20

NETWORK



LOGICAL DESIGN

The following diagram depicts the logical design of the network which will support the M
-
Pathways Financial
systems.

This diagram is

intended to give a perspective

of where each system resides in the network without the
underlying technical details of net
work configuration.


PRODUCTION
HARDWARE

The preliminary hardware proposal for the Financial 8.8 PeopleSoft infrastructure is below.


FINPROD Database Server

nighthawk.dsc.umich.edu (Regatta 5


New)

Database Servers
Database Servers
Database Servers
Secondary
(Fail-over)
Load Balancer
Web
Browsers
Secondary
(Fail-over)
Firewall
Primary Firewall
Secure Zone
Network Switch
DMZ
Network Switch
Load Balancers &
SSL Acceleration
Interface Server
(Flamingo)
Database Servers
Database Servers
Database Servers
Database Servers
Application Servers
PeopleSoft
2-Tier Clients
Campus Network
Campus Network
Web
Browsers
Secondary
(Fail-over)
Firewall
Routers
Database Servers
Database Servers
Database Servers
Crystal, nVision,
Workflow Servers
Web Servers
Web Servers
Web Servers
Web Servers

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 RAM

stilt.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 LPAR

chat.dsc.umich.edu (Regatta 4)

Hardware: IBM p690 LPAR with 3 1.1Ghz CPUs, 6 GB RAM


FINODS Database
Server

chickadee.dsc.umich.edu

Hardware: 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.edu

Hardware: 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 LPAR

chat.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 / 10
GB 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)



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 night
hawk (FINPROD database server)


Penguin:

Add 3GB RAM.


. Support addition of FINODS Application Server processes


Page
12

of
20

FIREWALL POLICY SUMMARY

Security and Network Services will evaluate the network traffic associated with each application, and determine
the
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 discussi
ons in the past. These include:



Direct database access outside of the
ITS

Data Center is generally blocked. The main exceptions to this
policy are the M
-
Pathways Data Warehouse, and the Operational Data Store, both of which are
accessible on the U
-
M camp
us 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 a
re moved from the Interface Server to the appropriate servers in the
Secure Zone.

FILE TRANSFER
(
INTERFACE
)

ARCHITECTURE

Wheneve
r 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 processing

and transfer
s

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

b
e executed by a remote call on
Nighthawk

(in the Secure Zone)
. Th
e

Interface Architecture
scripts are already in place for
Financials 7
.5

and
more
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, Nighthawk
will 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 integrat
e more fully with
Peoplesoft. In the new version,
ver
y non
-
override process will
be initiated by the
PeopleSoft Process Scheduler.
This
allow
s

users to see batch reports in
PeopleSoft
Report Manager.

The Integration Architecture uses Unix shell scripts to call a custom
-
written

Java program. This program
connects to a Peoplesoft Component Interface that makes requests to the Process S
cheduler. Once the Process
Scheduler 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 via
output management.
Most u
ser 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 of
our 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 decisi
ons 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 with
the 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 round
robin approach. This means that each server is sent requests in a sequential fashion, regardless of its current load
or health status. T
his approach has worked well for HE and we expect nothing different for Financials.


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 and
maintain the state of the web sessions connected throu
gh it.

Finally, the load balancers employ hardware
-
based SSL encryption and decryption routines that greatly improve
performance of the web systems they’re used with. Instead of the webservers executing the instructions to
encrypt 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 Balancer
w/ 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 list
4. 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 the
University of Michigan’s 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 hig
h
-
level, the Cosign authentication
mechanism 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 resid
es as cod
e on the WebLogic webserver and

is
invoked

each time a
user attempts to login to protected systems behind the Wolverine Access gateway.


Page
14

of
20



The Cosign filter currently in place for HE systems was developed specifically for the WebLogic 5.1
webserver p
latform running version 1.3.1 of the Java Runtime Environment (JRE). Work is
underway 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 the
machine must use the same filter. The redesign of the filter will make it possible to have filters for
multiple 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 c
oncurrently 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
invoke
d 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 no
t been developed yet, we expect
general 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 u
ser
then
clicks on University Business

link in

the Faculty & Staff section.


Page
15

of
20




3)

The u
ser
then
gets
automatically
redirected to weblogin.umich.edu with a web address (URL) similar to
the
one below:


https://weblogin.umich.edu/?cosignwolverineaccess=ldFBqkhR9dUlqAEsGO
;&https://wolverineaccess.umich.ed
u/servlets/iclientservlet/heprodop/?cmd=start&authTyp
e=1.


At this point, the cosign filter generated a COSIGN CLIENT COOKIE

(i.e cosign
-
wolverineaccess=ldFBqkhR9dUlqAEsGOHwGOfNnAo8ah). In addition
, a COSIGN SERVER
COOKIE was assigned by the CoS
ign
(weblogin.umich.edu)
server.




4) User enters his/her

uniqname and password and clicks Login.


The Login act
ion will trigger a POST to the CoS
ign server with the COSIGN CLIENT COOKIE, the COSIGN
SERVER 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 to
https://wolverineaccess.umich.edu/servlets/iclient
servlet/heprodop/?cmd=start&authType=1
.


6) The authentication filter will then create a PeopleSoft cookie and redirect to the same URL again.



Page
16

of
20

This is necessary to make the cookie available to the PeopleSoft Application Server.

The PeopleSoft Applicat
ion
Server 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 s
ystem.




REPORT REPOSITORY

The Financials 8.8

PeopleSoft Report Repositor
y

for FinProd will reside

on
an AIX server named Chat. The
major components of the Report Repository include the directory structures where reports are kept as well as the
WebLogic

8.1 webserver that enables users to view their reports and logs over the web. Chat is also the current
location 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 the
users. 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 all
executed on a
separate,
single Windows 2003 serv
er. This
W
indows 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 directly
from 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 improve
performance if necessary. The queue
of jobs
can be viewed via the Process Monitor within PeopleSoft.
W
hen the
job finishes, the output

and logfile (if applicable)
is

sent from the PSNT server to the
Financials 8.8
Report
Repository

webserver by the

PeopleSoft
Distribution Agent
. The sole purpose of the Distribution Agent is to
transfer log and output files, via FTP, to the Report Repository webserver.

This process i
s known as “posting”.

Once posted, u
ser
s can then
use the Process Monitor or Report Mana
ger 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:


Page
17

of
20

1
Webserver 1
Webserver 2
Chat
Report
Repository
PeopleSoft
Application Server
Nighthawk
Database Server
Client
Load Balancer
w/ SSL Acellerator
Firewall
SQL
HTTPS
HTTP
DMZ
Secure Zone
1. User logs into FinProd using his/her kerberos credentials via
Cosign.
2. The user enters the Process Monitor of Report Manager pages
within the FinProd system.
3. The FinProd database on nighthawk contains information on the
links to the reports the user has access to.
4. The user clicks on the view log/trace link and is automatically
redirected and logged into the FinProd report repository webserver
using the same kerberos credentials.
5. A new window is generated with the user’s requested report
information. This window is served up by the Char Report
Repository 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)
.

T
hese
JSPs
are
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 e
ach 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


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 My
Student Records, My Alu
mni 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 UM
Course Catalog

hours_of_op_secondary_students.jsp

Hours of operation link to display timings for Student
Business, Undergraduate Orientation

index.jsp

Homepage for Gateway Wolverine Access

logout.jsp

For logging out of WA
--
redirects to cosign logout
page

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 services
for orientation

reporting_secondary.jsp

Link to a
ll 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 Fin
ancials 8.8 Upgrade.
Each database server used in the upgrade, development and production architectures will have this version of
Oracle installed as well as Pro*C, Pro*COBOL, and Pro*Fortran. In addition, the Oracle v9.2.0.5 client software
will be inst
alled 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, Transfor
m and Load (ETL) Process from the On
-
line
Transaction 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 OLTP
server 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 t
o their refresh schedule
(below). The extract jobsets contain all of the extract SQRs for a particular DW dataset and are executed on the
OLTP server. The extract jobsets are set up to run on a particular schedule and normally have predecessor jobset

Page
19

of
20

de
pendencies related to their corresponding OLTP modules or processes. The corresponding load jobsets contain
both 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 ‘FTP’
script is invoked from the DW server to transfer the data files from the OLTP server to the DW server. Once the
Unix ‘FTP’ script has successfully completed, a Unix ‘load’ script is invoked that uses SQL*Load
er 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 the
data through the centrally supported Business Objects tool suite via Citrix.


In version PS version 7.5, DD was able to run thei
r 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 process
scheduler. This will entail obtaining a generic DW batch ID and creating process defin
itions for every SQR.


Currently the Financial DW tables are refreshed according to the following schedule:

General Ledger, Budget and Procurement


Every Sunday, the 6
th

working day of the month for month end
processing and most nights during the 2
nd

and
3
rd

week in July for year end processing

Asset and Space Management


Every Sunday

Utilities and Plant


The last day of the month

Significant changes will be made to the extract and load programs, but these
changes have not been
designed/developed
yet.

Be
low is a graphical representation of the Data Warehouse Extract Process:



Page
20

of
20

FTP using unix shell script & '1' id
FINPROD
Extract using
SQR (PSOFT id)
$datatemp/
*.dat files
pa02
OLTP Source Server
Data Warehouse Server
Load using
SQL*Loader *.ctl
files, unix shelll
script, and '9' id
$datatemp/
*.dat files
mdwxx.dat
mdwxx.dat
mdwxx.dat
mdwxx.dat
mdwxx.dat
mdwxx.dat
mdwxx.dat
mdwxx.dat
mdwxx.dat
mdwxx.dat
mdwxx.dat
mdwxx.dat
Predefined Reports
Business
Objects
Universes
The centrally supported tool
suite via Citrix
HEPROD
1
2
3
Users can access the DW server
using any SQL-based tool
-OR-
Ad Hoc Queries
Future?
-OLAP
-Data Mining
Business Objects