Embed Size (px)
Citation preview
Kuali Bootcampfor Interested Technologists
Bryan Hutchinson - Cornell University
(Development Manager)
Jack Frosch – Kuali Foundation
(Lead Developer)
Agenda
• Day 4– Kuali Coeus Research Administration (KCRA) / Coeus
topics– How KCRA uses Rice– Look at some Code– Exercises
KCRA/Coeus Technical Topics
• Background
• Coeus and KCRA compared/contrasted
• How we identified gaps
• How we are filling gaps
• Convergence / Divergence
• Q & A
Background
The vision statement from the KCRA project’s successful proposal to the Andrew W. Mellon Foundation asks: “What if any and every college and university could use, without fee, an outstanding research administration system that embodies the ‘best of’ techniques and processes for research administration, while maintaining the flexibility to fit disparate institutional structures and needs?
“This is entirely possible via a community source partnership to pool resources, requirements, and execution of an efficient development process. The software and community developed through this process could meet college and university needs while providing an economically sustainable path for the future.” The KCRA project is the instrument to develop this software and its community.
- Kuali Foundation web site (http://www.kuali.org/communities/kcra/)
Background
A significant part of this model is the wholesale adoption of the functionality in a proven system, thereby avoiding the inertia of a “clean sheet” design. The KCRA partner institutions have therefore agreed, from the outset, on the functional components that the project will deliver. The project has chosen MIT’s existing Coeus system as its baseline design. KCRA will then fill in functionality missing from Coeus, update its technical architecture for easier integration with other administrative systems, and release open source software backed by the Kuali Foundation.
- Kuali Foundation web site (http://www.kuali.org/communities/kcra/)
Coeus Participation on KCRA• KCRA Board
– Steve Dowdy MIT Voting Member– Terri-Lynn Thayer Coeus/Brown Voting Member– Tim Schleicher Johns Hopkins Ex-Officio Member– Jen Flach Coeus Ex-Officio Member
• KCRA Functional Council– Steve Dowdy MIT Voting Member– Tim Schleicher Johns Hopkins Member– Jen Flach Coeus Member
• KCRA Technical Council– Sabari Nair Coeus Voting Member
• KCRA Development Team– Rajeev Mancheril Former Coeus Developer– Geo Thomas Former Coeus Developer
• KCRA Subject Matter Expert Teams
Functionality and Features
• The KCRA mandate is to provide all of the Functionality of Coeus in KCRA.
• When providing COEUS functionality we are seeking Functional Equivalence not an exact copy of COEUS functionality. For example KCRA screens are functionally equivalent though their appearance and flow is different.
• The focus has been how to bring the Features of a rich-client system to the Web.
Coeus and KCRA Compared/Contrasted
• History
• Architecture
• Look & Feel
Coeus and KCRA - History
• Coeus– 13+ years of development– 46 members in the Coeus Consortium
• KCRA– Part of the Kuali Foundation– New Development (Startup Q1/2007 Development started July
2007)– Release 1.0 - July 2008– 8 Partner Schools Currently
Coeus and KCRA - Architecture
• Coeus– Java on top of Oracle Stored Procedures– Not Service Oriented Architecture (SOA)
• KCRA– Kuali Architecture and Rice– Database Agnostic (R2 and beyond)– SOA
Coeus and KCRA - Look & Feel
• Coeus– Coeus Premium: Swing desktop application– Coeus Lite: Web Application with functionality
subset
• KCRA– One Web Application– Standard Kuali Look & Feel
Coeus Premium Look & Feel
Coeus Lite - Look & Feel
Coeus Lite - Look & Feel
Kuali - Look & Feel
Kuali - Look & Feel
Approach to Incorporating Coeus Functionality in KCRA
• Functional/Technical analysis of Coeus (lite and premium) in light of KCRA/Kuali
• KCRA Functional and technical team trips to MIT• Regular involvement of Steve Dowdy, Sabari
Nair, Jen Flach, Tim Schleicher, Rob Yetter and other Coeus Subject Matter Experts (SMEs).
Gap Analysis - Technical
• Technical Gaps: things that Coeus does that Kuali (Rice) cannot currently do technically
• Technical Gap Proposals in Confluence
• Examples:– Workflow– Custom Attributes
Gap Analysis - Functional
• Functional Gaps: Functionality that Kuali won't support regardless of technology
• Functionality vs. Features• Rollup of Functional Decisions in Confluence• Examples:
– Lookup Framework– Custom Attributes– Complex UI
How we are filling gaps
• Process
• Documentation
• Development
Filling Gaps - Process
• Technical Gaps– Proposals are documented in Confluence and JIRA; the
Enhancement Proposal pages in Confluence include:• Technical Guide (how the enhancement will be implemented in Rice)• Client Developer Guide (how a developer of an application built on Rice would
make use of the enhancement).• User Guide (how and end user would use the enhancement if applicable).
– Presented at weekly Kuali Technical Integration meetings– Approved Proposals are scheduled for a Rice release
Filling Gaps - Process
• Functional Gaps– Regular review with Lead SME's– Decisions/Recommendations are presented to
the Functional Council– Decisions that require technical implementation
are taken back to the KCRA development team
Filling Gaps - Development
• Technical Gaps– Upon Approval are assigned– Work is being done by both the Rice team and
the KCRA Team
• Functional Gaps– Any Functional Gap decisions that require
development work are assigned to a KCRA developer
Example - Workflow
• Workflow was discussed in depth at the KCRA-Coeus Technical Task Team meeting in Boston 2/28 - 3/2/07
• Following this meeting, a Gap Analysis document was developed• Both Coeus and KCRA (through KEW) support workflow functionality.
However they do it in different ways.• As a result of the Gap Analysis, several Technical Gaps were identified,
and several Functional Questions were raised.
Example - Workflow
• Rice Enhancement Proposals were written for the technical gaps and presented at the Rice Integration Team meeting where they were approved.
• JIRA Tasks to implement the proposals were assigned. Some have been completed and some are still in progress.
• Functional Questions were presented to the Lead SMEs who provided answers and shared information back with the larger Functional team.
Example - Workflow
• Technical Gap: 'Meta-Rules', 'Rules', and 'Conditions'• Context: Coeus Rules can have multiple conditions
combined with boolean logic, and each condition can be based on a database column, YNQ answer or a database function. Coeus has the concept of Meta Rules where individual rules are combined with ordering and if/then logic.
• Proposal: We can model Coeus conditions and routing rules as KEW rules if we make some modifications to the framework.
Example - Workflow
• Technical Gap: 'Multiple Approvals' • Context: Coeus prompts the user, when they get their first
approval request, if they are going to get future approval requests and allows them to choose to receive these requests or bypass them (opposite of ignorePrevious KEW configuration where system determines if user gets future requests based on static configuration.)
• Proposal: We could do routing report and look for user in those, then prompt if necessary & pass flag to KEW if this action should stand in for future action requests (the flag to KEW is the enhancement).
Example - Workflow
• Technical Gap: 'Inbox - View Resolved Gap'
• Context: Coeus shows users both pending and resolved items in their Inbox (Action List equivalent)
• Proposal: Enhancement Show Resolved items in action list, perhaps as a separate tab (this is the same thing as the My Outbox enhancement request described in Workflow Document Search Enhancement Request.)
Example - Workflow
• Functional Questions
• Context:Coeus contains a nice UI to maintain Routing and Notification Rules and Meta Rules, while most of the workflow configuration for KEW is done in XML. Rules can be maintained via a web UI in KEW, but it is not as nice or full-featured as Coeus.
• Question: How much of the existing Routing Maintenance UI In Coeus Premium should be kept?
Example - Workflow
• Question: Can we deliver version 1 of KCRA without the fancy UI and depend on the XML configuration in KEW, and then include the Rule Maintenance UI improvements in a later release?
• Proposal: Stick with the existing KEW XML configuration for Release 1 of KCRA, and then deliver a more full-featured UI that is similar to Coeus Premium (allowing for differences between desktop and web clients) in Release 2. This will allow us to concentrate on functionality first and features later.
Example - Workflow
• Implications:– If we stick with existing KEW XML configuration for Release 1 of
KCRA, there will be more technical expertise and possibly more training/documentation required for implementing schools, however, it reduces the demand on the development team and allows them to concentrate on replicating Coeus Functionality.
– If we need to implement a more complex UI in Release 1, this will take developer resources away from replicating other Coeus functionality (Reality Triangle).
• Decision: We will move ahead using the KEW XML based configuration for Release 1. A more advanced Workflow configuration UI (similar to Coeus) will be deferred until Release 2.
Filling Gaps
• Rice Enhancements for KCRA Release 1.0– 19 Enhancements Proposed– 17 Approved, 1 Deferred for KIM, 1 Not needed based on
existing KEW functionality– 15 Development Complete, 2 In Process
• Functional Questions– 18 Decisions based on initial gap analysis, some of which
led directly to Rice Enhancements– Continuing dialog via Lead SME/LBA/DM meetings
Convergence / Divergence
• Long-term proposal: Coeus and KCRA products merge into one.
• What is our upgrade path?
• Until the product merge, how do we keep KCRA and Coeus from diverging?
• How can we pro-actively help these two products converge?
Managing Divergence
• Coeus has regular releases, and these aren't slowing down, nor should they at least for now
• KCRA needs to have a complete functional release that can be implemented to show we're legitimate
• We need to keep track of new Coeus releases and manage which features get put into KCRA
• Future– Joint design– KCRA team members actively monitor Coeus enhancement
requests
Proactive Convergence
• Proposal: KCRA as a replacement for Coeus Lite• Maintain shared db to make sure both KCRA and
Coeus can run on top of any database changes KCRA makes
• Develop future Coeus modules using Kuali architecture / Rice framework
• Coeus’ offshore team helping port grants.gov to KCRA / Kuali architecture / database agnostic code
Upgrade Path Strategy
• Keep the Coeus database structure largely intact– Minimize table changes– Create views to help maintain backwards
compatibility
• Develop scripts to enable a seamless upgrade for Coeus Institutions to KCRA
Questions?
How KCRA Uses Rice
• How KCRA uses Rice
• Moving Rice Functionality Forward
• KCRA Development Process
How KCRA Uses Rice
• Kuali Rice is the basic development framework used by KCRA, but…– KCRA is Functionally different from other Kuali
Applications– KCRA is Technically different from other Kuali
Applications
Functionally different from other Kuali Applications
• Analysis of Functional Differences
• Differences provide basis for Rice enhancements– Extend and customize functionality where
possible– Focus on Extension, not Disruption– Add new tools to the Rice toolbox
Technically different from other Kuali Applications
• Same basic building blocks (Kuali stack)• Rice allows us to make our own choices
about development– Maven, not Ant– Jetty, not Tomcat (Development)– HTMLUnit Tests– Bamboo, then Continuum, not Anthill for CI
Documents - Size
• KCRA: Few, large, complex• KFS: Many, small, still complex
• KNS– Data Dictionary - Specify multiple pages– Web Flow - Allow consistent behavior while navigating
between multiple pages in arbitrary order– Document interaction - Document is saved/loaded– Rules - Events/Rules can be specified in code and
extended
Documents - Size
Documents - Size
Documents - Size
<headerNavigation> <headerNavigationTab> <navigateTo>proposal</navigateTo> <displayName>Proposal</displayName> </headerNavigationTab> <headerNavigationTab> <navigateTo>budgetVersions</navigateTo> <displayName>Budget Versions</displayName> </headerNavigationTab>…snip… <headerNavigationTab> <navigateTo>grantsGov</navigateTo> <displayName>Grants.gov</displayName> </headerNavigationTab> <headerNavigationTab> <navigateTo>actions</navigateTo> <displayName>Proposal Actions</displayName> </headerNavigationTab> </headerNavigation>
Documents - Web Scope
• KCRA: Large Documents, Session based
• KFS: Currently Request based
• KNS– Mitigate issues with Session based persistence
(multiple browsers, etc…)– Eases development/maintenance (hiddens, load-
save-load anti-pattern)
Documents - Web Scope
<action path="/proposalDevelopment*" name="ProposalDevelopmentForm" validate="true” attribute="KualiForm"input="/WEB-INF/jsp/ProposalDevelopment{1}.jsp" scope="request" parameter="methodToCall"
type="org.kuali.kra.proposaldevelopment.web.struts.action.ProposalDevelopment{1}Action"> <forward name="basic" path="/WEB-INF/jsp/ProposalDevelopment{1}.jsp" /> <forward name=”budgetVersions" path="/WEB-INF/jsp/ProposalDevelopmentBudgetVersions.jsp" /> <forward name="keyPersonnel" path="/WEB-INF/jsp/ProposalDevelopmentKeyPersonnel.jsp" /> <forward name="proposal" path="/WEB-INF/jsp/ProposalDevelopmentProposal.jsp" />
... </action>
public class ProposalDevelopmentDocument extends ResearchDocumentBase implements Copyable, SessionDocument {
...
}
Documents - Locking
• KCRA: Pessimistic Locking, Long lasting docs, Session Based, Functional Areas
• KFS: Optimistic Locking, short lived docs
• KNS (Rice Enhancement)– Centralized locking mechanism– Document Authorizer classes– Provide two layers of locking if desired
Documents - Versioning
• KCRA: Many documents require versioning• KFS: Versioning not required in general (PurAp
docs do version)
• KNS (enhancement pending - KCRA Release 2.0)– Support optional versioning of documents– Configuration option– Little additional code required– New Version created by user request or
programmatically
Custom Attributes
• KCRA: Transactional Documents, table based, runtime
• KFS: Reference Data, code based
• Implemented in KCRA for Release 1.0 (Future enhancement to move from KCRA to KNS)– Support both models– UI: Integrated custom tag– Accessible for Lookups, Routing, Reporting– Strongly typed for validation
Custom Attributes
User Roles; AuthZ
• KCRA: User/Role based; Integrated into Unit Hierarchy; Code checks Permissions
• KFS: Workgroup based
• KIM– Manage people/groups– Role Qualifiers allow integration with Unit Hierarchy
• KNS– Document Authorizer Class
People
• KCRA: Research System required data
• KFS: Financial System required data
• KIM– Define a ‘Person’ generically– Institution specific attributes– Application specific attributes
Workflow
• KCRA: Can support Coeus routing: Units define custom rules and responsibilities; Initial configuration based on analysis done by Kenton Hensley and Dan Dwyer
• KFS: Account, Unit based; Rules defined for the entire document
• KEW– Flexible routing allows document/node based workflow (and more)– Multiple KCRA-related enhancements
Moving Rice Functionality Forward
• Identifying KCRA Requirements– Gap Analysis between Coeus and KCRA
• Kuali Technical Integration Meetings– Technical representatives from Rice enabled
applications– Review of Enhancement Proposals based on
Functional Requirements
• Project Planning– Managing multiple release schedules
Moving Rice Functionality Forward
• Development Work on approved Rice enhancements split between KCRA and Rice teams
• Rice Enhancements for KCRA Release 1.0– 19 Enhancements Proposed– 17 Approved and completed, 1 Deferred for KIM,
1 Not needed based on existing KEW functionality
Synergies and Moving Forward
• KCRA– Relies on Rice to provide functionality
• Rice– Greater richness of functionality as KCRA
requirements are integrated
• Future Rice Enabled Applications– More choices, more functionality, more features
KCRA Development Process
• Distributed Development Team
• Module Teams led by a Development Manager
• Common Tools
• Clear Expectations
• Defined Standards and Processes
KCRA Development Process
• Development Toolbox– Eclipse– Junit / Httpunit– Jetty– Subversion (svn)– Maven
• Shared Tools– Continuum (CI)– Fisheye
KCRA Development Process
• Shared collaboration tools– Confluence wiki– JIRA bug tracking– KCRA Developer mailing list– PolyCom video-conferencing– Breeze / Adobe Connect - online collaboration– Skype - text / voice / video chat
KCRA Development Process
• Clear expectations for KCRA Developers documented in Confluence– Code Reviews
• Peer Reviews of all code, periodic larger group code reviews of interesting/complex/etc code
– Coding Standards– Documentation Standards– Tool usage– Unit/Integration Tests– Etc
• Regular meetings– Weekly 1-on-1– Weekly Code Reviews– Monthly all team and module team meetings– Periodic Face-to-Face meetings
KCRA Development Process
1. Functional Specification completed2. DM reviews spec3. DM assigns JIRA to developer4. Developer works in Eclipse against local database with Jetty5. Developer commits to svn6. Continuum gets latest updates and builds KCRA app and runs unit
tests7. CNV environment built daily8. REG environment built weekly
Questions?
For Further Information
• http://www.kuali.org/communities/kcra/
– General KCRA Information• https://test.kuali.org/confluence/display/KRADOC/Home
– KCRA Documentation
• Bryan Hutchinson - [email protected]
Code Review
Let’s take a look under the hood!
Exercises
