Implementing Kuali Rice

1. Implementing Kuali Rice JA-SIG - April 30, 2008 Eric Westfall

2. Welcome! • Welcome to the Implementing Kuali Rice seminar at JA-SIG! • What to Expect • Overview of Kuali Rice • Information on Deployment and Integration • Hands-on exercises and examples looking at various components of Rice from a client developer perspective • Hands-on exercises involving setup and installation of a Kuali Rice Standalone Server • First half will be a high-level discussion, second half will be hands-on and fairly technical

3. Overview • Hands-on Setup • Kuali Rice Overview • Deployment and Integration • Example: IU’s Kuali Rice Implementation • Recipes Sample Application • Standalone Rice Server Installation • Java Thin Client Integration • Embedded KEW Client Integration • Institutional Customization • eDoc Lite

4. Hands-on Setup

5. Hands-on Setup • We will be using VMware Player Setup Instructions: • https://test.kuali.org/confluence/x/dYGQAg

6. Contents of the VMware Image • Ubuntu Linux 7.10 • JDK 1.5 • Maven • Subversion • Eclipse • recipes sample application • Kuali Rice 0.9.2 • Sample Thin client • Sample Embedded client • Sample eDoc Lite project • Sample Institutional Plugin project

7. Contents of the VMware Image, cont. • Oracle XE – contains 3 databases • RICERECIP – for recipe sample application • RICESTAND – for rice standalone • RICEEMBED – for embedded client • SQuirrel SQL – an SQL client • Tomcat – for rice standalone • Various configuration files

8. Kuali Rice Overview

9. What is Kuali Rice? • Kuali Rice is a suite of middleware and framework components • Made up of several, possibly standalone and swappable, components • Applications become a “Rice Client Application” by easily integrating with this middleware

10. Goals of Kuali Rice • The vision for Kuali is a plug and play module by module approach to software • Kuali started as financials, but has evolved into a suite of administrative software (KFS, KRA, KS) • A lot of functionality in Kuali systems • Keeping the Kuali code base as small as possible without impacting quality is key • Highly productive development environment • For Kuali projects • For non-Kuali projects

11. Goals continued • A common and consistent architecture • Allow developers to understand other rice-enabled projects • Infrastructure would not need to be reinvented on each project - focus on functionality! • Rice team can focus on IT standards, like SOA, that will benefit the entire Kuali software suite • Adoption of other Kuali modules feasible • Generic enough for non-Kuali applications

12. Kuali Rice Components • KNS Kuali Nervous System • KEW Kuali Enterprise Workflow • KSB Kuali Service Bus • KEN Kuali Enterprise Notification • KIM Kuali Identity Management • KOM Kuali Organization Management

13. Kuali Nervous System • Web-based Application Framework • Data Model Driven (Data Dictionary) • Provides reusable code, shared services, integration layer, and a development strategy • Provides a common look and feel through a screen drawing framework • A document-centric (business process) model with workflow as a core concept

14. Kuali Nervous System, Cont. • More Core Concepts / Features • Transactional documents • Maintenance documents • Inquiries • Lookups • Business Rules • Data Dictionary

15. Kuali Enterprise Workflow • Facilitates routing and approval of business processes throughout an organization • Provides re-usable routing rule creation which defines how business processes should be routed • Provides hooks for client applications to handle workflow lifecycle events of business processes • Routing processes are configurable when the system is live resulting in high availability • End users interact with central workflow GUIs for all client applications • Document Search • Action List

16. Kuali Service Bus • Service Registry to enable applications and services on the bus to interact with other applications and services • Provides synchronous service invocation • Provides asynchronous messaging • Provides flexible security • Provides Quality of Service (QoS) • Light Weight – keep it simple

17. Kuali Enterprise Notification • Works with the Action List to provide a single place for all institution-related communications • Workflow items come from KEW • Non-workflow items from KEN • Non-workflow example items • Overdue library book • A concert on campus • Graduation checklists for seniors • Provides a secure and controlled environment for notifying the masses

18. Kuali Enterprise Notification, cont. • Eliminate sifting through email • Communication broker which provides any combination of action list, text messages, email, etc... • Audit trail just as in KEW (Route Log) • User preferences for notification types • End user interfaces • Viewing notification details • Maintaining the system (admin) • Sending messages (admin)

19. Kuali Identity Management • Still under development • Once development is complete, will retrofit existing Kuali Rice modules to take advantage of it • Replace current user and workgroup services that are currently implemented as part of KEW • Replace authentication/authorization which is currently part of KEW • Keeping it simple to start • Will maintain information about persons, groups, roles, etc.

20. Kuali Identity Management, cont. • Goals: • Clean and consistent service interfaces used by all Kuali apps; generic enough for non-Kuali apps • Leverage KNS to provide a reference implementation for services; workflow-enabled management application • Flexibility for dynamic attributes associated with IdM entities (persons, groups, roles, etc) • Pluggable integration with other IdM products

21. Kuali Organization Management • Still under development • Provide a common set of service APIS for Organization and Unit Hierarchy Management • Provide an out-of-the-box reference implementation for managing these data structures • Goal of becoming the shared infrastructure application for managing organizations and their hierarchies for all Kuali applications

22. Deployment and Integration

23. Deployment and Integration • There are multiple ways to deploy and integrate applications with Kuali Rice • Bundled – Kuali Rice software is “bundled” into your application • Standalone – a standalone server is deployed • In addition, when deploying a standalone server, the following client integration options are available, most relate to the KEW module • Embedded KEW – workflow engine is embedded into your application • KEW Java Thin Client • Web Services – for KEW and, eventually, KIM • eDoc Lite • We are going to take a detailed look at these

24. Bundled Mode • All Kuali Rice modules are embedded into the client application, including the Web Application • The Recipe sample application (which we will look at later) runs in this mode. • Does not require the deployment of a standalone Rice server • Ideal for development or “quickstart” applications • This is not desirable for Enterprise deployments of Kuali Rice

25. Bundled Mode Diagram

26. Standalone Rice Server • The Standalone Rice Server allows you to run a central Kuali Rice application that can be integrated with multiple clients • Facilitates a single KEW Action List, Document Search, etc. • Allows for a shared KSB Service Registry • Supports multiple integration options for clients: • KEW Java Thin Client • Embedded KEW • Web Services

27. KEW Java Thin Client • Allows for a Java client application to integrate with the KEW module of Rice • Uses Java Serialization over HTTP • All workflow processing happens on the standalone server • If the workflow processing requires custom code (i.e. Post Processors), then plug-ins need to be developed and deployed to the server

28. KEW Java Thin Client Diagram

29. Embedded KEW • Embedded KEW allows you to configure a workflow engine embedded in your application but still use a standalone rice server • This allows for the following: • Integration of database transactions between client application and embedded KEW (via JTA) • Fast - Embedded client talks directly to database • No need for application plug-ins on the server • Still a single KEW web app but scalability is increased because of multiple Workflow Engines

30. Embedded KEW Diagram

31. KEW Web Services • There are a few web service endpoints that are exposed from Kuali Rice • KEW has a subset of it’s API available using this integration method • The KSB allows for exporting of services onto the bus using SOAP Web Services • In the future, we hope to add more web service endpoints to Kuali Rice • For example, KIM is being designed with web service remoting in mind

32. eDoc Lite • Simple, form-based system which uses XML and XSLT • In the absence of a separate client application, eDoc Lite can be used to create fairly sophisticated form-based applications • Deployed and hosted entirely inside of the Standalone Rice server

33. Bringing it all Together • Leveraging the KSB and the previous examples, it’s possible to utilize multiple strategies for KEW integration and deployment • Examples: • Some clients running as Thin Clients • Some clients leveraging code deployed in plug-ins on the standalone server • Multiple servers deployed in a cluster for scalability • Some clients integrating directly with web service endpoints • Some clients running in Embedded Mode • Numerous eDoc Lite applications

34. The Whole Picture

35. Example: IU’s Kuali Rice Implementation

36. Example: Indiana University’s Kuali Rice Implementation • Thin Clients • HR • ERA • EPIC • TK • SIS • Embedded Clients • IUF • Travel (coming soon) • KFS (coming soon)

37. Example: Indiana University’s Kuali Rice Implementation • eDocLite clients • Office of Affirmative Action • University Graduate School • Safeword Card Requests • OVPR Internal Funding • OVRPA Conflict of Interests • Purchasing Conflict of Interests • SIS Special Credit • IU Health Center • UITS Unit Change Request • …and more on the way!

38. Example: Indiana University’s Kuali Rice Implementation • Institutional Customizations • Integration with our LDAP-based User Repository (EDS) • Integration with Active Directory for reading group and role information • Integration with our CAS installation for authentication • Custom component for authenticating with our Email servers (requires SSL) • Various shared routing components deployed in a plug-in

40. Hands-on Setup Checkpoint

41. Hands-on Setup Checkpoint • For those wishing to follow along, let’s take some time to verify your setup is ready and working.

42. Recipes Sample Application

43. Recipes Sample Application • We will be using the Recipes Sample Application to look at different pieces of KNS and KEW • A simple system for maintaining recipes and categories that they fit into • Two Entities (Business Objects) • Recipe • Recipe Category • Two Tables (DB Tables) • RECIPES_T • RECIPES_CATEGORIES_T

44. Recipes Sample Application Setup • Project is already checked out at /java/projects/recipes and available in Eclipse • This application runs with Kuali Rice bundled inside of it (no standalone server) • We need to do the following: • Prepare the database (both Recipes and Rice) • Start the web application • Connect to the web application • Import workflow configuration • https://test.kuali.org/confluence/x/RgCgAg

45. Review the Business Objects • The recipes app is not completely hooked together yet so let’s do it! First we’ll review the Business Objects used by the recipes app. • Open the Java files in package edu.sampleu.recipe.bo.* • Should include: • Recipe • Recipe Category

46. How These Link Together • We use an ORM (Object Relational Mapper) called Apache OJB • XML files combined with a set of Apache Java libraries that automatically persist data in our business objects to our DB • Working on replacing with JPA in 0.9.3 - a Java standard • No more XML, use annotations in Java code instead

47. Recipe OJB Mapping • Open repository.xml in the recipes project in Eclipse • Notice that the mapping for Recipe is missing, let’s add it • Open repository.xml in the recipes_reference project in Eclipse • Find and copy the mapping for Recipe • Now both of our Business Objects are mapped to the database

48. Leveraging the KNS • We’ll use the KNS to provide search and detail information on categories and recipes • Search = Lookup • Detail Info = Inquiry • We’ll use the KNS to provide maintenance CRUD operations with workflow backing them • CRUD = Maintenance Documents

49. Review RecipeCategory DD • We use something called the Data Dictionary (DD) to construct our lookups, inquiries, and maintenance documents • Open RecipeCategory.xml - this is the business object DD file • Lookups • Inquiries • Open RecipeCategoryMaintenanceDocument.xml - this is the maintenance document XML • CRUD, Workflow, Authz • Run the web app to correlate DD to functionality

50. Create Recipe DD Files • The Recipe BO does not currently have any Data Dictionary files. • Copy Recipe.xml from recipes_reference into recipes • Copy RecipeMaintenanceDocument.xml from recipes_reference into recipes • Let’s take a look at both of these Data Dictionary files.