Architecting and Building KRA using Kuali Rice

1. Architecting and Building KRA using Kuali Rice Terry Durkin, KRA DM/Lead Developer (Indiana University) Bryan Hutchinson, KRA DM/Lead Developer (Cornell)

2. Introduction • KRA Background • Rice Background • How KRA uses Rice

3. 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

4. Functional Roots - Coeus • Cradle to Grave Research Administration • Proposals/Budgets • Awards • Links to Financial System • Subcontracts • Negotiations • Compliance (human subjects)

5. 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

6. Rice Components

7. Nervous System (KNS) • Data Dictionary • Document lifecycle • Lookups • UI Components • Maintenance Documents • Persistence

8. Workflow (KEW) • Workflow as a Service • Rules • Approvals • Actions • Workgroups • Integrated into KNS Documents • Accessible from existing applications • Embedded/External

9. Notifications (KEN) • Notifications (not Actions) • Multiple notification schemes • Email • Mobile Phone • Priority • Extensible

10. 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…

11. 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

12. Technical Roots • KFS pioneered the KNS • KEW based on IU Workflow

13. 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

14. 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!

15. 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

16. KRA In Depth • This is nice… but… How does KRA use Rice?

17. 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

18. KRA Architecture

19. KRA Architecture

20. 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

21. Documents - Size

22. Documents - Size

23. 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>

24. 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)

25. <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

26. 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

27. 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

28. 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

29. Custom Attributes

30. Custom Attributes

31. 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

32. People • KRA: Research System required data • KFS: Financial System required data • KIM • Define a ‘Person’ generically • Institution specific attributes • Application specific attributes

33. KIM https://test.kuali.org/confluence/x/Kqg

34. 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)

35. More… • KSB • Units/Organizations • People • Validation • KRA - Grants.gov • Kuali Lookupable Interface for cohesive interface • Web Service

36. 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

37. 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

38. Wrap-up • Final Thoughts • Questions

39. Other Kuali Days Sessions of Interest • Rice Sessions • KRA/Coeus Joint Session

40. 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