Implementing KFS Release 2(Let’s Get Cookin’!)

Susan Moore / Jonathon Keller, UC - Davis

Vince Schimizzi / Mike Criswell, MSU

Topics

• Mission• Approaches• Technical environment• Distribution: What do you get ?• Goals• How did it go?• Next steps• Final thoughts (open discussion)

Mission (UC – Davis)

• Stay ahead of a production implementation in identifying issues.

• Review and provide input to installation and configuration documentation.

• How to structure deployment of application.

• Review new implementation functionality of KFS release 2.

Mission (MSU)

• Review, learn, and provide input on installation and configuration documentation.

• Begin to identify and review MSU configuration issues and to conduct modeling scenarios.

• Review new functionality in KFS release 2.

Approach (MSU)

• For bootstrap version (like a go-live installation) much attention was given to data, setup and configuration.

• Prior to release, functional/technical staff reviewed process from KFS release 1 and developed plan for KFS release 2.

• Upon receiving pre-release software, up and running in 3 business days.

• 3 technical staff, 7 functional staff.

Approach (UC-Davis)

• Wanted a “fresh” perspective.

• 1 technical staff part-time.

• 2 functional staff part-time.

Technical Environment

UC - Davis MSUHardware Application Server:

Dell PowerEdge 1850 / Xeon 3.0 GHz

4 GB RAM / 73 GB HDD

Windows Server 2003 SP2

Database Server: (not dedicated)Sun Fire V240 / 2 x 1.5 GHz CPU

12 GB RAM / 2 x 73 GB Internal HDD

550 GB storage on SAN

Application Server: Dell PowerEdge 2950 with 2 Gig RAM, (2) 60 GB Drives, Fedora Linux version 6

Database Server: Dell Dual Processor, 8 GIG RAM, Red Hat Enterprise 4 - Linux (64 bit OS), SAN-based storage

Database Oracle 10g for Solaris Oracle 10g for Linux (64 bit edition)

Download Distribution Source Code Distribution

Dataset KULDEMO KULBOOTSTRAP + MSU Data

Distribution: What do you get?

• Kuali Financial System

• Demo Data Set

• Bootstrap Data Set

• Database Import/Export Tool

• Kuali Rice

• Kuali Enterprise Workflow

• Sample Patch for Extended Attributes

Goals (MSU)

• Load MSU sample data.

• Implement an extended attribute.

• Create a custom business rule.

• Replace CAS Authentication with MSU’s home-grown authentication.

• Build the application from source.

• Test application.

MSU Load Process

Source Data (Multiple Formats)

Staging and Transformation

KULSTG(Disabled

Constraints)

Kuali Application Schema

KULMSUMain Schema

(With Constraints)

Table

Load Order DefinitionsOracle PL/SQL

Procedure

MS XLS CSV Oracle SQL

Loader

Kuali Application Server

uses

Goals (UC - Davis)

• Build the application from source.

• Test application.

How did it go? (UC - Davis)

• Installation

• Functional testing

How did it go? (MSU)

• Installation went well (some expected challenges)

• Functional testing of transaction and maintenance eDocs went smoothly.

• Experience from prior load (table load sequence) was helpful in identifying new tables and fields.

• Referential integrity constraints helped ensure proper data load.

• MSU created Entity Relationship (ER) diagrams on application which was useful in understanding the underlying data.

Next Steps (MSU)

• Install actual Kuali release 2 application.

• Continue testing application once up and running

– Maintenance Edoc

– Transaction Edoc

– Batch processes

– Workflow capabilities

– Etc.

• Create supplemental implementation documents for MSU.

Next Steps (UCD)

• Load institutional data.

• Create additional business objects and extended attributes on existing objects.

• Replace CAS authentication with UC authentication.

Final Thoughts

• Overall smooth process.

• The lack of any substantive “show stoppers” is itself a sign of success.

Questions ?