Fin Upgrade Tech Architecture Sample

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


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.


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.


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


5/20


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


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/20

Page 8 of 20


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 ServersApplication Servers

PeopleSoft

2-Tier Clients

Campus Network Campus Network

Web

Browsers

Secondary(Fail-over)Firewall

Routers


Database Servers

Crystal, nVision,Workflow Servers

Web Servers

Web ServersWeb Servers

Web Servers


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)


FINODS Report Repository

Add 2GB RAM to and share existing HEPROD/HEODS Report Repository LPARchat.dsc.umich.edu (Regatta 4)


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)


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


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.


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.


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.jsp


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=ldFBqkhR9dUlqAEsGO


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:


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


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


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:


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

Fin Upgrade Tech Architecture Sample

Documents