400 likes | 510 Views
Architecting and Building KRA using Kuali Rice. Terry Durkin, KRA DM/Lead Developer (Indiana University) Bryan Hutchinson, KRA DM/Lead Developer (Cornell). Introduction. KRA Background Rice Background How KRA uses Rice. About KRA. Kuali Research Administration
E N D
Architecting and Building KRA using Kuali Rice Terry Durkin, KRA DM/Lead Developer (Indiana University) Bryan Hutchinson, KRA DM/Lead Developer (Cornell)
Introduction • KRA Background • Rice Background • How KRA uses Rice
About KRA • Kuali Research Administration • Enterprise level Research Administration • Any proposal submitting institution • Based on MIT’s Coeus • 12 years of development/functionality • Used by 44 schools • Release 1.0 - July 2008 • Proposal Development/Budget incl. Grants.gov S2S
Functional Roots - Coeus • Cradle to Grave Research Administration • Proposals/Budgets • Awards • Links to Financial System • Subcontracts • Negotiations • Compliance (human subjects)
About Kuali Rice • Software Development Simplified • Unified development platform • Diverse functional requirements • Service Oriented Architecture (SOA) • Integration of Kuali Applications • Integration of existing Enterprise Applications • Version 0.9.2 focuses on KRA requirements
Nervous System (KNS) • Data Dictionary • Document lifecycle • Lookups • UI Components • Maintenance Documents • Persistence
Workflow (KEW) • Workflow as a Service • Rules • Approvals • Actions • Workgroups • Integrated into KNS Documents • Accessible from existing applications • Embedded/External
Notifications (KEN) • Notifications (not Actions) • Multiple notification schemes • Email • Mobile Phone • Priority • Extensible
Service Bus (KSB) • Service Integration • Ease of Integration • Provides opportunities for synergies between Kuali applications • Framework for communicating with existing applications • Multiple Connectors • Java • SOAP • Spring Integration • Etc…
Identity Management (KIM) • New to the Rice party • Application integration via KSB • Institution and Application Extensible • Can provide fine grained User/Role based AuthZ • Integrate with existing AuthN infrastructure
Technical Roots • KFS pioneered the KNS • KEW based on IU Workflow
Moving Rice Functionality Forward • Identifying KRA Requirements • Integration Meetings • Technical representatives from Rice enabled applications • Review of Enhancement Proposals based on Functional Requirements • Project Planning • Managing multiple release schedules
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 • More on this tomorrow!
Tool Differences from KFS • 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, not Anthill • Allows execution of Bamboo native plugins and Maven plugins
KRA In Depth • This is nice… but… How does KRA use Rice?
KRA Building Blocks • Kuali Toolbox • Open Source Tools • Struts - UI • OJB - Persistence • Spring - Services • Rice builds upon and extends functionality • Struts - Mitigates common issues (POJO forms, Formatting,…) • OJB - DAO w/ Object Hierarchy; No custom code for POJO persistence
Documents - Size • KRA: 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 <headerNavigation> <headerNavigationTab> <navigateTo>proposal</navigateTo> <displayName>Proposal</displayName> </headerNavigationTab> <headerNavigationTab> <navigateTo>keyPersonnel</navigateTo> <displayName>Key Personnel</displayName> </headerNavigationTab> …snip… <headerNavigationTab> <navigateTo>actions</navigateTo> <displayName>Actions</displayName> </headerNavigationTab> <headerNavigationTab> <navigateTo>auditMode</navigateTo> <displayName>Audit Mode</displayName> </headerNavigationTab> </headerNavigation>
Documents - Web Scope • KRA: 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)
<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="keyPersonnel" path="/WEB-INF/jsp/ProposalDevelopmentKeyPersonnel.jsp" /> <forward name="proposal" path="/WEB-INF/jsp/ProposalDevelopmentProposal.jsp" /> <forward name="template" path="/WEB-INF/jsp/ProposalDevelopmentTemplate.jsp" /> </action> publicclass ProposalDevelopmentDocument extends ResearchDocumentBase implements Copyable, SessionDocument { ... } Documents - Web Scope
Documents - Locking • KRA: Pessimistic Locking, Long lasting docs, Session Based, Functional Areas • KFS: Optimistic Locking, short lived docs • KNS (enhancement pending) • Centralized locking mechanism • Document Authorizer classes • Provide two layers of locking if desired
Documents - Versioning • KRA: Many documents require versioning • KFS: Versioning not required in general (PurAp docs do version) • KNS (enhancement pending) • Support optional versioning of documents • Configuration option • Little additional code required • New Version created by user request or programmatically
Custom Attributes • KRA: Transactional Documents, table based, runtime • KFS: Reference Data, code based • KNS (KRA model enhancement pending) • Support both models • UI: Integrated custom tag • Accessible for Lookups, Routing, Reporting • Strongly typed for validation
User Roles; AuthZ • KRA: User/Role based; Integrated into Unit Hierarchy; Code checks Rights • KFS: Workgroup based • KIM • Manage people/workgroups • Qualified Roles allow integration with Unit Hierarchy • KNS • Document Authorizer Class
People • KRA: Research System required data • KFS: Financial System required data • KIM • Define a ‘Person’ generically • Institution specific attributes • Application specific attributes
KIM https://test.kuali.org/confluence/x/Kqg
Workflow • KRA: Based on Coeus’ routing, Units define custom rules and responsibilities • KFS: Account, Unit based; Rules defined for the entire document • KEW • Flexible routing allows document/node based workflow (and more)
More… • KSB • Units/Organizations • People • Validation • KRA - Grants.gov • Kuali Lookupable Interface for cohesive interface • Web Service
Synergies and Moving Forward • KRA • Relies on Rice to provide functionality • Rice • Greater richness of functionality as KRA requirements are integrated • Future Rice Enabled Applications • More choices, more functionality, more features
Future of KRA • Release 1.0 - July 2008 • Proposal Development • Budget • Grants.gov S2S • Release 2.0 - 2009 • IRB • Awards • Release 3.0, 4.0 • Full functionality of Coeus
Wrap-up • Final Thoughts • Questions
Other Kuali Days Sessions of Interest • Rice Sessions • KRA/Coeus Joint Session
Contact • http://www.kuali.org/communities/kra/ • https://test.kuali.org/mocks/kra-coeus-dev/proposal.html • Terry Durkin - tdurkin@indiana.edu • Bryan Hutchinson - bh79@cornell.edu • Andrew Slusar - as833@cornell.edu