implementing kfs release 2 (let’s get cookin’!) susan moore / jonathon keller, uc - davis vince...
TRANSCRIPT
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 ?