Kuali Rice at Indiana University From the System Owner Perspective July 29-30, 2008 Eric Westfall

What is Kuali Rice? Kuali Rice is a middleware suite of services and framework components Made up of several, possibly standalone and swappable, components Client applications use the available APIs to integrate with this middleware End-users interact with various web-based components provided by Rice

Kuali Rice Components KEWKuali Enterprise Workflow KSBKuali Service Bus KNSKuali Nervous System KENKuali Enterprise Notification KIM Kuali Identity Management

Components Used at IU KEW −Primary component used at IU −Extensively used to implement both Enterprise applications and eDoc Lite applications KSB −Used implicitly via KEW −Looking to leverage this in other areas KNS −Not used in many places yet −Will be used more in the future

System Owner Responsibilities Installation and Configuration Administration Monitoring Support Working with Clients Testing and Production Migration Upgrades and Patches Identifying Opportunities

Installation and Configuration Rice Standalone application will need to be configured and deployed Application will likely require institutional customization/configuration (more later) At IU - Ant-based deployment framework −Check out from CVS −Execute ant target −rsync to Tomcat servers across cluster −KEW plugin deployment also handled this way

KEW Administration We’ll look at each of these admin screens as we go through them XML Ingester – used to install XML configuration Document Types, Rule Attributes, Rule Templates −Constitutes configuration of a routing process, installation in production typically handled by administrator Rules −Client application owners will typically maintain their own rules −But Rice system owner will typically help with initial bulk rule setup for a new project (via XML)

KEW Administration, cont. Workgroup Types −Define and configure when working with clients Application Constants −Runtime modifiable configuration for KEW Document Operation −Useful to invoke CRUD operations against Documents in the KEW database −Client application gets out of sync with KEW document state −Misbehaving documents because of bugs in routing configuration or plug-in code

KSB Administration Thread Pool −Allows for tweaking of thread pool used for processing async messages −Can be used to change thread pool settings across a cluster Service Registry −Provides a view of the services registered on the bus Message Queue −Shows messages in the queue and those which failed −Provides ability to re-queue, transfer, delete, etc. Quartz −Displays messages scheduled for retry at some point in future

Monitoring Monitor health of system to identify any potential issues Monitor the Message Queue for “stuck” messages At IU we have graphs and metrics for app servers and databases KEW integration can make heavy use of HTTP connections, monitor app servers for thread backup

Support We receive various kinds of support requests Questions from users of the system −Often get these as responses to the Action List s which go out −Might be confused about why they were routed a document Majority of cases we can forward question to appropriate client application owner Questions from other client application owners −new applications to integrate/updates to existing integration −New eDoc Lites/updates to existing eDoc Lites −Bug reports/enhancement requests

Working with Clients Big part of what we do is to work with clients areas to implement integration with KEW Also work with departments to identify and develop eDoc Lites KEW integration at IU is not self-service Requires working with someone on our Enterprise Service Integration team to get project set up and going We recommend best practices for naming of groups, document types, etc. while working with client More on working with eDoc Lite clients later

Working with Clients, Enterprise Applications

Testing and Production Migration As seen previously, we provide various test environments to allow for testing of Rice integrated applications −DEV/SND – place where developers can do initial work and testing −CNV/UNT – initial testing by small groups of users, quite a bit of iterative change occurring −REG/STG – final stop prior to production migration, larger group of users testing (possibly same users that will use in prod) Clients configure their applications to point to desired environment −Must be authenticated via cert if using thin-client integration

Migration between Environments KEW offers the ability to export configuration as XML At each environment, configuration is exported and then imported into the next one when ready If application requires a plug-in, that will also be deployed to all environments Attempt to keep test environments in sync with production for future development

Production Migration Production migration involves: −Packaging XML configuration for prod release −Going through change management procedures −Request our ESA team to deploy any plug-ins required by client application −Using the XML Ingester in prod to import/update XML configuration once required deployments have happened −Client applications must also handle deployment of their client applications and ensure they are configured to point to production environment

Patches and Upgrades Patches −Occasionally, we implement bug fixes/enhancements for our Rice installation which must be patched in −We deploy to our test environments and test the changes −We may request user testing if change is significant −Release to prod using our J2EE release procedure

Patches and Upgrades Upgrades −When doing upgrades to new major Kuali Rice versions there is more work involved −Analysis of changes in version, development of conversion scripts −Upgrade in test environments first −Client applications must update and recompile their applications with the latest binaries (plug-ins too) −Typically allow about a month for QA and testing Load Testing −We do extensive load testing prior to each major release −JMeter + Rice client APIs to simulate client application remote calls to the standalone server −Jmeter + HtmlUnit to simulate client interaction with the web application

Identifying Opportunities System owners should help management keep an eye out for places where Rice can be leveraged within the Institution Once in place, can add tremendous value to the systems and infrastructure at your institution Examples: −Streamline previously paper-based processes −Use Action List to consolidate notifications/work queue −Use EDL to help improve efficiency in areas which don’t have developer resources −Reduce redundancy by identifying systems which have custom-built workflow solutions