Kuali Rice and Enterprise Workflow May 22, 2008 David Elyea.

Slides:



Advertisements
Similar presentations
Unveiling ProjectWise V8 XM Edition. ProjectWise V8 XM Edition An integrated system of collaboration servers that enable your AEC project teams, your.
Advertisements

Apache Struts Technology
Kuali Technology Mark Norton – Nolaria Consulting Zachary Naiman – Member Liaison, Kuali Foundation.
Introduction to Kuali Rice ITANA Screen2Screen: Kuali on Campus May 2009 Eric Westfall – Kuali Rice Project Manager.
Open source administration software for education software development simplified RAD, Rules, and Compatibility: What's Coming in Kuali Rice 2.0 Eric Westfall.
Kuali Enterprise Workflow Damon Dorsey, Indiana University Kymber Horn, University of Arizona Vince Schimizzi, Michigan State University.
KUALI ENTERPRISE WORKFLOW OVERVIEW Eric Westfall.
Edoclite and Managing Client Engagements What is Edoclite? How is it used at IU? Development Process?
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Kuali Rice at Indiana University Important Workflow Concepts Leveraged in Production Environments July 29-30, 2008 Eric Westfall.
University of California, Irvine All Rights Reserved UCI Kuali Day Access and Workflow August 21, 2012 U niversity of C alifornia, I rvine Accounting.
© 2004, The Trustees of Indiana University 1 OneStart Workflow Basics Brian McGough, Manager, Systems Integration, UITS Ryan Kirkendall, Lead Developer.
1 Classification: Genpact Internal.  Tool From Oracle  Works with Oracle Database  PL/SQL Based  Widely Used with Oracle Applications  Can be Used.
© 2004, The Trustees of Indiana University 1 Kuali Enterprise Workflow (KEW) Basics Brian McGough, Manager, Systems Integration, UITS.
Rapid Development of Workflow-enabled Forms using eDocLite
Open source administration software for education software development simplified KRAD Kuali Application Development Framework.
Kuali Enterprise Workflow Eric Westfall (Indiana University) Andrew Hollamon (University of Arizona)
Introduction to Kuali Rice Presented at Internet2 April 2009 Eric Westfall – Kuali Rice Project Manager Bill Yock – Vice Chair, Kuali Rice Board of Directors.
Technical Overview of Kuali Rice UC Davis, Information & Educational Technology January 2009.
James Smith, University of Arizona Barbara Sutton, Cornell University
Architecting and Building KRA using Kuali Rice Terry Durkin, KRA DM/Lead Developer (Indiana University) Bryan Hutchinson, KRA DM/Lead Developer (Cornell)
Kuali Rice Technical Overview February Components of Rice  KEWKuali Enterprise Workflow  KNSKuali Nervous System  KRADKuali Rapid Application.
1 Kuali Identity Management Advanced CAMP: Identity Services Summit for Higher Ed Open / Community-Source Projects.
Christopher Jeffers August 2012
Kuali Enterprise Workflow Kuali Days – May 2008 Eric Westfall - Indiana University.
Kuali Rice Overview January 2008 Aaron Godert - Cornell University.
Kuali Rice at Indiana University Rice Setup Options July 29-30, 2008 Eric Westfall.
Technical Overview for “Functionals” (Kuali-eze…It’s a Foreign Language!) Ailish Byrne, Indiana University Barbara Sutton, Cornell University.
Kuali Enterprise Notification Tell Me What I Want And Need To Know Aaron Godert (Sr. Software Architect, Cornell University) John Fereira (Programmer/Analyst,
Eric Westfall – Indiana University Jeremy Hanson – Iowa State University Building Applications with the KNS.
Rice Status Update University of California July 20, 2009 Eric Westfall – Kuali Rice Project Manager.
Eric Westfall – Indiana University James Bennett – Indiana University ADMINISTERING A PRODUCTION KUALI RICE INFRASTRUCTURE.
Kuali Nervous System Aaron Godert, Cornell University Jonathan Keller, University of California, Davis.
RECALL THE MAIN COMPONENTS OF KIM Functional User Interfaces We just looked at these Reference Implementation We will talk about these later Service Interface.
Kuali Enterprise Notification Aaron Godert (Sr. Software Architect, Cornell University) John Fereira (Programmer/Analyst, Cornell University)
Kuali Enterprise Workflow Eric Westfall (Indiana University) Aaron Hamid (Cornell University)
Kuali Rice: Cross Project Middleware May 21, 2007 Aaron Godert - Cornell University Nate Johnson - Indiana University.
Kuali Nervous System Aaron Godert, Cornell University Jonathan Keller, University of California, Davis.
Implementing Kuali Rice JA-SIG - April 30, 2008 Eric Westfall.
Kuali Enterprise Workflow Presented at ITANA October 2009 Eric Westfall – Kuali Rice Project Manager.
KUALI IDENTITY MANAGEMENT Provides services for Identity and Access Management in Kuali Integrated Reference Implementations User Interfaces An “integration.
Building Applications with the KNS. The History of the KNS KFS spent a large amount of development time up front, using the best talent from each of the.
Middleware for FIs Apeego House 4B, Tardeo Rd. Mumbai Tel: Fax:
Kuali Enterprise Workflow Kuali Days – November 2008 Scott Gibson, University of Maryland Bryan Hutchinson, Cornell University James Smith, University.
M ODELING B USINESS P ROCESSES IN K UALI E NTERPRISE W ORKFLOW Eric Westfall – Indiana University Claus Niesen – Iowa State University.
1 Kuali Nervous System (KNS) Part 2 Presented by: Jerry Neal – KFS Development Manager Geoff McGregor – KC Lead Developer Brian McGough – KRice Project.
Kuali Enterprise Workflow Ryan Kirkendall (Indiana University) Brian McGough (Indiana University)
1 Kuali Nervous System (KNS) Part 1 Presented by: Jerry Neal – KFS Development Manager Geoff McGregor – KC Lead Developer Brian McGough – KRice Project.
M ODELING B USINESS P ROCESSES IN K UALI E NTERPRISE W ORKFLOW Eric Westfall – Indiana University Claus Niesen – Iowa State University.
5 - 1 Copyright © 2006, The McGraw-Hill Companies, Inc. All rights reserved.
Kuali Rice Evolving the Technology Framework for Kuali Applications Brian McGough (Indiana University) Aaron Godert (Cornell University) Warner Onstine.
Kuali Rice A basic overview…. Kuali Rice Mission First and foremost to provide a consistent development framework and common middleware layer for Kuali.
Kuali Rice at Indiana University From the System Owner Perspective July 29-30, 2008 Eric Westfall.
Notification System. Functional Goals Provide a single list for all university related communications –Workflow items –Non-workflow items Examples of.
© 2006, The Trustees of Cornell University © 2006, The Trustees of Indiana University Kuali Nervous System Aaron Godert, Kuali Development Manager Brian.
Kuali Rice: General Overview Brian McGough Kuali Rice Project Manager Kuali Lead Architect Director, Enterprise Software, IU May 13, 2008.
Kuali Nervous System Nate Johnson, Indiana University Jonathan Keller, University of California, Davis.
KEW Definitions Document Type The Document Type defines the routing definition and other properties for a set of documents. Each document is an instance.
KIM: Kuali Abstraction Layer for Identities, Groups, Roles, and Permissions.
© FPT SOFTWARE – TRAINING MATERIAL – Internal use 04e-BM/NS/HDCV/FSOFT v2/3 JSP Application Models.
Kuali Enterprise Workflow Damon Dorsey, Indiana University Kymber Horn, University of Arizona.
Open source administration software for education next generation student system I Did Not Know You Could Do That With An SIS: How To Make Kuali Student.
Eric Westfall KUALI ENTERPRISE WORKFLOW OVERVIEW.
Kuali Rice Evolving the Infrastructure for Kuali Applications Brian McGough (Indiana University) Aaron Godert (Cornell University)
What’s new with Grouper 26-April-2010, Spring Member Meeting Chris Hyzer, Grouper developer.
Kuali Rice: Cross Project Middleware October 24, 2007 Aaron Godert - Cornell University.
Interstage BPM v11.2 1Copyright © 2010 FUJITSU LIMITED INTERSTAGE BPM ARCHITECTURE BPMS.
Building KFS using KNS Presented by James SmithJustin Beltran University of ArizonaUniversity of California, Irvine.
Kuali Enterprise Notification Tell Me What I Want And Need To Know Aaron Godert (Sr. Software Architect, Cornell University) John Fereira (Programmer/Analyst,
Kuali Enterprise Notification Tell Me What I Want And Need To Know Aaron Godert (Sr. Software Architect, Cornell University) John Fereira (Programmer/Analyst,
Presentation transcript:

Kuali Rice and Enterprise Workflow May 22, 2008 David Elyea

Outline 1.Kuali Rice Overview 2.Kuali Enterprise Workflow 1.What is KEW? 2.Building Blocks of Workflow 3.Developing a Workflow Document 4.eDoc Lite 5.Institutional Customization 3.Deployment and Integration 4.Example: IU’s Kuali Rice Implementation 5.Moving Forward 6.Questions & More Examples

Kuali Rice Overview

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

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

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

Technologies Used Struts Spring JTA (JOTM) OJB Quartz XFire (old version of CXF) Groovy XML

Version Introduction Latest Stable Release: –Discussion focused on this version –Used by KFS TestDrive example –Used by several institutions currently implementing Rice Current IU Implementation: Current Development: Next Development Version: 0.9.4

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

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

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

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.

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

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

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

Kuali Enterprise Notification, cont. Eliminate sifting through Communication broker which provides any combination of action list, text messages, , 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)

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

Kuali Enterprise Workflow

What is KEW? Kuali Enterprise Workflow is a module of Kuali Rice which provides a content-based routing engine. –Documents created from process definitions (Document Types) and submitted to the workflow engine for routing –Routing decisions made based on the content of the Document It has traditionally been used for business transactions in the form of electronic documents that require approval from multiple parties. For example: –Transfer of Funds –Requisition –Hire/Terminate Employee –Timesheet –Drop Course Composed of a set of services, APIs, and GUIs

KEW Core features Action List (User’s Work List) Document Searching Document Audit Trail (Route Log) Flexible process definition (Document Type) –Splits, Joins, Parallel branches, Sub processes, Dynamic process generation Basic User and Group support –Can be overridden and customized to plug into Institutional user and group services –Will be replaced by KIM in the future Rules Engine Notification

KEW Core features Notes and attachments Wide array of pluggable components to customize routing by process, including: –Where to route document –Indexing of document data for searching – Notification Customization –Customization of Action List –Customization of Routing Rules eDoc Lite –Framework for creating simple documents quickly –Will see more of eDoc Lite later

KEW Core features Plug-in Architecture –Packaging and deployment of routing components to the Rice Standalone Server at runtime –Institutional Customization Transactional Processing –JTA can be used for multi-datasource transactions Can run in J2EE appservers Can run in Servlet Containers –In non-J2EE environment, can use JOTM or other JTA implementation to provide JTA transactions

The Building Blocks of Workflow

Document Type Specification for a document that can be created in KEW Contains identifying information as well as policies and other attributes Defines the Route Path executed for a document of that type (Process Definition) Hierarchical - children can inherit certain attributes from their parents Defined in XML

Route Node Represents a “step” in the routing process of a document type. Defines the behavior of the document when it reaches that node Examples: –Simple: do some arbitrary work –Requests: generate action requests using a Route Module or the Rules engine –Split: split the route path into one or more parallel branches –Join: join one or more branches back together –Sub Process: execute another route path inline –Dynamic: generate a dynamic route path

Rule Attribute Defines how a Routing Rule evaluates document data to determine whether or not the rule data matches the document data Also defines what data is collected on a rule An attribute typically corresponds to one piece of data on a document (i.e dollar amount, department, organization, account, etc.) Can be written in Java or defined using XML (with matching done by XPath) Can have multiple GUI fields defined in a single attribute

Role Attribute A special type of Rule Attribute which allows for routing to a “Role” Used when data on users or workgroups that must be routed to is stored in an external system Examples: Fiscal Officer, Dean, Supervisor, Professor, etc. Already Existing Role Attributes in KEW –Initiator Role: used to retrieve the user defined as the initiator on the document –Routed By User Role: used to retrieve the user who physically routed the document (may not be the initiator)

Rule Template A composition of Rule Attributes Adding a ‘Role’ attribute to a template allows for the use of the Role on any rules created against the template When rule attributes are used for matching on rules, each attribute is associated with the other attributes on the template using an implicit ‘and’ logic qualifier Can be used to define various other aspects to be used by the rule creation GUI such as rule data defaults (effective dates, ignore previous, available request types, etc)

Routing Rules Configured via a GUI (or imported from XML) Created against a Rule Template and a Document Type The Rule Template and it’s list of Rule Attributes define what fields will be collected in the Rule GUI Rules define the users, workgroups and/or roles who should receive action requests Available Action Request Types that Rules can route –Complete –Approve –Acknowledge –FYI

Routing Rules During routing, Rule Evaluation Sets are “selected” at each node. Default is to select by Document Type and Rule Template defined on the Route Node Rules match (or ‘fire’) based on the evaluation of data on the document and data contained on the individual rule Examples –If dollar amount is greater than $10,000 then send an Approval request to Joe. –If department is “HR” request an Acknowledgment from the HR.Acknowledgers workgroup.

Post Processors Associated with a Document Type Often used to “Finalize” the business transaction represented by the workflow process Sends events to clients at various points in the document routing process –KEW status changes –Node transitions –Actions taken by users

Searchable Attributes Responsible for extracting and indexing document data for searching Allows for custom fields to be added to Document Search for documents of a particular type Configured as an attribute of a Document Type Can be written in Java or defined in XML by using Xpath to facilitate matching

Plug-ins A plug-in is a packaged set of code that can be deployed into the standalone server method of deploying Rice Usually contain classes only used in routing such as custom rule or searchable attributes but can contain client application specific services Usually used only by clients being implemented by the ‘Thin Client’ method

Workflow Document Example

KFS Routing Example We’ll discuss an example of a document routing in the Kuali Financial System Using Disbursement Voucher document –Used to disburse funds (i.e., pay someone) –Since its real money, there are a lot of approvals and verifications needed But first, let’s look at the steps required to build and configure a document that uses KEW

Steps Build the document –KFS uses Rice and the KNS to build their documents –Beyond the scope of this discussion –Can learn more about this at the KNS session Create Document Type and Process definition in KEW –Identifies the route path of the document Define Rule Attributes and Rule Templates –Defines what data will be used for routing and how rules can analyze that data to make routing decisions Create Routing Rules

Building the Document

Defining the Disbursement Voucher Routing Process for Disbursement Voucher is defined as follows Ultimately defined in XML and imported

Rule Attributes and Rule Templates Rule Attributes and Templates are defined for each of the “Nodes” in the defined Process Account Review - a special Role attribute which decides who the Fiscal Officer is based on accounts attached to document Org Review - an attribute which climbs the Org hierarchy when evaluating rules Employee Indicator, Tax Control Code, Payment Method, etc. are defined in XML and use XPath to analyze document content and evaluate rules

Using XPath for Rule Evaluation The KNS handles serializing documents to XML and making XML available to KEW XPath expressions can be configured on attributes in KEW to evaluate rules based on this XML Example: Campus Code //document/campusCode = wf:ruledata('campusCode')

Creating Rules For all Nodes except Account Review, we create rules to define who the document should route to

Creating Rules Screenshot of DV Rules

Account Review Configuration There is a special type of rule which points to the Fiscal Officer Role for Account Review Resolution of responsible parties is handled by Java code which looks at the account numbers on the document

Route Log of a Disbursement Voucher Route Log

KFS Routing Example - Summary Summary –Can be simple or complex –Process definition is defined –Rule Attributes and Templates are Created –Rules are Configured –For more complex routing logic, routing components may need to be implemented –For simpler routing logic, out-of-the-box components can be used (i.e. XPath eval.)

eDoc Lite

A simple, form-based system that runs entirely within Workflow, and can be created with no java, just XML. Typically used for simple documents with simple route paths Can be integrated with larger applications usually with a database layer post processor component

eDoc Lite - Details Simple form creation and presentation –XML definition of form fields –Use your own custom XSLT for presentation Simple validation rules –Regular Expression –Custom Validators –Required/Not-Required –JavaScript Validation Security –Achieved through XSLT integration with KEW APIs

Building Blocks of an eDoc Lite Every eDoc Lite consists of 4 pieces: –Field Definitions – defines what fields the EDL has, what type, validations, etc. –Stylesheet – an XSLT stylesheet that renders the EDL for the user –Document Type – defines the workflow process for the EDL –EDL Association – associates each of the 3 pieces above to form an eDoc Lite

Handling EDL Data Since EDL uses KEW for it’s routing. You can implement Post Processors to write your EDL data to a database. There is one already available which can be used out of the box to write to: –EN_EDL_DMP_T –EN_EDL_FIELD_DMP_T This data can then be replicated or extracted to other environments to be used by reporting or user processes

eDoc Lite Architecture

eDocLite – EDL Form

eDocLite – Summary Makes creating a workflow-enabled application based on a simple form easy No Java development required No application to deploy

Institutional Customization

Customizing Kuali Rice at your Institution There are many ways to customize your Standalone Rice installation, including but not limited to: –Integration with institution’s identity services –Integration with institution’s authentication mechanisms (i.e. CAS) –Development and deployment of shared routing components

KEW Institutional Plug-in Uses already existing Plug-in architecture in KEW to allow Institution wide customizations Can be used to override services using a custom Resource Loader implementation Only one institutional plug-in can be defined

Deployment and Integration

Rice Deployment Options –Bundled – Kuali Rice software is “bundled” into your application –Standalone – a standalone server is deployed Standalone Server Client Integration Methods –Embedded KEW – workflow engine is embedded into your application –KEW Java Thin Client –Web Services – for KEW and, eventually, KIM –eDoc Lite

Bundled Mode All Kuali Rice modules are embedded into the client application, including the Web Application 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

Bundled Mode Diagram

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

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

KEW Java Thin Client Diagram

Embedded KEW Embedded KEW allows you to configure a workflow engine embedded in your application but still use a standalone rice server Allows for the following advantages: –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

Embedded KEW Diagram

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

Bringing it all Together Leveraging the KSB and the previous examples, it’s possible to utilize multiple strategies for Kuali Rice/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

The Whole Picture

In Practice: Indiana University’s Kuali Rice Implementation

Indiana University’s Kuali Rice Implementation KEW Thin Clients –HR (PeopleSoft) –ERA –EPIC –TK –SIS (PeopleSoft) KEW Embedded Clients –IUF –Travel (coming soon) –KFS (coming soon)

Indiana University’s Kuali Rice Implementation eDoc Lite clients –Office of Affirmative Action –Grad and Undergrad Course Remonstrance –Safeword Card Requests –OVPR Internal Funding –OVRPA Conflict of Interests –Purchasing Conflict of Interests –Student Information Systems - Special Credit –IU Health Center –UITS Unit Change Request –…and more on the way!

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 servers (requires SSL) –Various shared routing components deployed in a plug-in

PeopleSoft Integration - SIS Uses Thin Client Integration with a Plug-in Integration Points –Direct database table manipulation –PeopleSoft Enrollment engine is called using PeopleSoft Component Interface Largest used document types are ‘Add Course’ and ‘Drop Course’

PeopleSoft Integration – HR Uses Thin Client Integration with a Plug-in Integration Points –Java client integrating with KEW uses a custom database (no direct application connection) –Users view screens in HR java client and when PeopleSoft data must be updated users are redirected to PeopleSoft screens which have buttons to pull in data from custom database PeopleSoft Component Interface was not used as the SIS group used it due to CI being buggy back when HR first integrated with KEW at IU

PeopleSoft Integration – HR Application in Development Will be a fully Rice Enabled Application (including use of the KNS module of Rice) Will run Embedded KEW connecting with IU’s Standalone Rice Server and using KSB exposed Services from IU Institutional Plug-in Redesign Features/Enhancements –Will use KNS to read PeopleSoft database tables directly –Custom KNS Lookup implementations to leverage PeopleSoft effective dating in some objects –All documents will be Transactional Documents to allow for custom GUI control (no Maintenance) –Developers are attempting to design custom automation of the currently manual user screen redirection

Statistics 24 x 7 x 365 (minus maintenance) HTTP Requests per Month - 45,084,367 Users – 156,675 Document Types – 96 Workgroups – 1,610 Rules – 9,097 During The Last Year: Documents Routed1,164,870 Requests Generated6,012,216 Actions Taken2,913,709 Route Nodes Processed5,405,701

Moving Forward

Upcoming Work Version of Kuali Rice is currently under development Changes planned for KEW –Refactoring to forward all notifications to KEN –Remove legacy package names (edu.iu.*) Add support to the KNS for defining workflow processes in the Data Dictionary Laying groundwork for tasks (module refactoring)

Upcoming Work, cont. Version of Kuali Rice will concentrate of reducing internal duplication and consolidating services KEW will be retrofitted to use KIM Numerous changes will be made to have KEW leverage the KNS –Remove duplicate Lookup framework –Rewrite Document Search as a Lookup –Rewrite Rule document to use KNS –Remove duplicate Notes/Attachments system –and more…

More Information Rice web site: KEW web site: Rice Message List: