Architecting and Building KRA using Kuali Rice Terry

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 S 2 S

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

Rice Components

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 Auth. Z • Integrate with existing Auth. N 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

KRA Architecture

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

Documents - Size <header. Navigation> <header. Navigation. Tab> <navigate. To>proposal</navigate. To> <display. Name>Proposal</display. Name> </header. Navigation. Tab> <navigate. To>key. Personnel</navigate. To> <display. Name>Key Personnel</display. Name> </header. Navigation. Tab> …snip… <header. Navigation. Tab> <navigate. To>actions</navigate. To> <display. Name>Actions</display. Name> </header. Navigation. Tab> <navigate. To>audit. Mode</navigate. To> <display. Name>Audit Mode</display. Name> </header. Navigation. Tab> </header. Navigation>

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)

Documents - Web Scope <action path="/proposal. Development*" name="Proposal. Development. Form" validate="true” attribute="Kuali. Form" input="/WEB-INF/jsp/Proposal. Development{1}. jsp" scope="request" parameter="method. To. Call" type="org. kuali. kra. proposaldevelopment. web. struts. action. Proposal. Development{1}Action"> <forward name="basic" path="/WEB-INF/jsp/Proposal. Development{1}. jsp" /> <forward name="key. Personnel" path="/WEB-INF/jsp/Proposal. Development. Key. Personnel. jsp" /> <forward name="proposal" path="/WEB-INF/jsp/Proposal. Development. Proposal. jsp" /> <forward name="template" path="/WEB-INF/jsp/Proposal. Development. Template. jsp" /> </action> public class Proposal. Development. Document extends Research. Document. Base implements Copyable, Session. Document {. . . }

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 (Pur. Ap 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

Custom Attributes

User Roles; Auth. Z • 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 S 2 S • 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 - bh 79@cornell. edu • Andrew Slusar - as 833@cornell. edu